NetBSD-Users archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: default gateway on different subnet

I haven't really been following this thread very closely, so maybe what I'm saying has already been said clearly enough. However this message, and the quoted bits it seems to be replying to, show

On 14-Nov-2008, at 11:12 PM, James Chacon wrote:

There is nothing conceptually wrong with saying "I'm connected to a cloud which has these N networks directly accessible and my local IP is on one of them"

Well, so long as your single local host IP address is only on _one_ of those N networks....

A given IP address can only be connected to _one_ network, especially for the purposes of routing, and to some extent that includes ARP too.

and some way to then specify what those N networks are. In this case then there would be no routing since the machine would be able to directly see the other hosts. Folks who believe there is some hard and fast rule which requires interfaces to have IP's configured for each of these networks I challenge to show me any specification which requires this vs simply allowing additional netmasks to be added to a given interface.

An additional netmask is not really sufficient information with which to specify another IP network, at least not for the whole picture to work.

Even if the network number portion matches bit for bit up to the longest netmask doesn't mean you can get away with just one host address when it comes to trying to do routing. Networks are specified by a network number and a netmask. Just because you can do a bit-for- bit matching of two different masked network numbers and see that they match a given host IP doesn't mean you can easily create a mechanism which allows for use of a host IP and a bunch of netmasks to specify a cloud of interconnected networks, at least not on top of a system which currently is designed to specify independent networks (whether they're connected to the same interface or not).

In any case you don't really have a proper cloud of networks in the way you've described the addresses being used. You have one network and some hosts have artificially restricted their view of that network by specifying a narrower netmask than they could. I'm not sure how this affects ARP, but at least from their IP routing table's perspective they cannot talk to all the hosts on that network. They need to expand their netmask if they want to see the whole network.

i.e. it's all an implementation detail for the most part and there's a lot of allowed flexibility here.

You might get a wee bit further with this line of thinking if you were to change the question slightly and suggest that the gateway address is _not_ on a different subnet but rather is on the subnet with the larger netmask. Then essentially you don't have two networks any more, just one. The smaller subnet is simply a logical creation invented elsewhere in the network, and it is irrelevant to the host in question. So long as the ethernet and ARP will allow the host in question to see every host on the whole local area network (that it needs to see), then you're done.

I.e. just pick the largest netmask, the one that allows you to "see" the IP address of the default gateway as if it is on the same network as the host, and be done with it!

So, if I'm seeing this right then all I can say is that this artificial subnetting of a larger IP network which is all actually on the same LAN into smaller subnets is just plain unnecessary and should even be described with many other nasty words that I won't use right now.

This all presumes the other hosts on this cloud of multiple networks are all configured in some reasonable way to be able to get packets back to you as well of course.

A proper cloud of networks all connected to the same interface will require separate host addresses for each network; at which point specifying different gateways (for specific networks) on each of those networks is already supported. You still only get one default route, of course, but that's sensible too.

                                        Greg A. Woods; Planix, Inc.

Attachment: PGP.sig
Description: This is a digitally signed message part

Home | Main Index | Thread Index | Old Index