Re: Problem related with Subnetting
From: Walter Roberson (roberson_at_ibd.nrc-cnrc.gc.ca)
Date: 5 Dec 2004 19:40:37 GMT
[Followups to this taken back away from comp.os.linux.networking as it
is not a Linux specific matter.]
In article <firstname.lastname@example.org>,
Bill Marcum <email@example.com> wrote:
:On 5 Dec 2004 05:41:37 -0800, Rajat
: <firstname.lastname@example.org> wrote:
:> One more thing I want to ask is, if that corporate subnet internally
:> have 3 different LAN. Say 10.0.0.X, 20.0.0.X and 30.0.0.X, with subnet
:> mask as 255.255.255.0. Can a host in 10.0.0.X talk with a host in
:> 20.0.0.X directly??
:> If yes then how and what information will be needed??
:You will need a gateway between the subnets. That can be a router or a
:Linux PC with two network cards. Each host should be configured to use
:the gateway to reach the other subnet.
Bill is correct about the typical implimentation [except you'd usually
want *three* network cards instead of two for handling three subnets].
There is, though, an obscure possibility that avoids needing a
router or gateway machine.
The way that machines locate each other is that they send out broadcast
ARP packets asking for information on the destination IP. In most
cases, those ARP broadcasts are sent to the subnet broadcast address of
the subnet that the originating host is on. If the destination host is
on the same subnet, then it will receive the broadcast and will respond
directly back to the originator with the destination's MAC address.
If the destination host is not on the same subnet, then a router [and
the Linux box Bill mentions would be acting as a router] that has a
presence on both IP address ranges will hear the broadcast [because it
is in the originating address range] and will respond back with the
router's MAC address. The originating machine will then send the
packets to the router's MAC [but using the destination IP], and the
router will receive the packet, look at the the destination IP, and
forward the packet out the appropriate interface.
I've simplified that a little: the router doesn't actually have to
have a presence on the destination IP range for the router to answer:
the router just has to have information about which device might have a
better idea of how to reach the destination IP: in networking lingo, it
has to have a 'route' that gets closer to the destination. That's
trivial in the case where it does have a presence in the other IP
address range, but it can get fairly complex when there might be
multiple corss-connections between networks and information about
temporary communications breakdowns has to make it to widely
distributed sites so that sites don't try to use a non-functional
gateway. Easy on a typical small to medium LAN case, not easy for large
businesses [say IBM] or for major ISPs that glue together the Internet
as we know it.
Now, going back to the smaller LAN situation where a router is likely
to have direct interfaces on each of the internal address ranges, there
is another possibility rather than using a router. Notice that I said
that "in most cases" the ARP broadcasts are sent to the subnet
broadcast address of the subnet that the originating host is on. That's
not a hard requirement in the ARP specification. Instead, the
originating host could send to the broadcast address which means "All
local hosts"; switches will forward such messages to all ports that are
in the same VLAN. In this situation, if there is a local path by which
the source could reach the destination directly "as if they were on the
same subnet", then the destination will -directly- receive the "all
local hosts" broadcast *even though it isn't in the same IP address
range*. The destination will see the MAC of the originator of the
packet, which is all the information that the destination really needs
in order to get the reply back to the originator directly without going
through a router.
Thus, if the source is configured to send ARPs to the "all local hosts"
broadcast address, and the destination is configured to be able to
learn MAC addresses that aren't in the same IP address range as the
destination, then the source and destination will be able to
communicate without going through a router.
Bill [and others] would likely point out that such configurations are
not at all common, and that this only works when the the source and
destination IP address ranges "share the same wire". It is certainly
quite uncommon to see configurations these days that rely on this
behaviour: using a router of some sort is much "cleaner" and far more
likely to work when you have a mix of different operating systems on
the same network.
It turns out, though, that there is one very common operating system
that impliments the behaviour I describe: the Windows NT family
(Windows NT, Windows 2000, Windows XP). Windows NT class computers
*are* able to communicate with devices in other IP address ranges
without going through a router.
I'm not just saying this "in theory" either: in one of our remote
offices, a junior admin too inexperienced to know that "You *must* have
a router!" put a Windows 2000 box in a different IP address range on
the LAN, and the box was able to communicate with everything it needed
to be able to reach. Then I had to "debug it" to figure out how it
Once I had worked out the mechanism, I recalled that in Cisco's IOS
router operating system, the default broadcast address is the "all
local hosts" address rather than the appropriate subnet broadcast IP.
I had remembered happening upon that several years ago, but at the time
it was just a wacko obscure default setting that seemed likely to be a
"bug" except it was documented. It wasn't until I worked out the
Windows situation that I mention above that I started to realize that
the IOS setting wasn't a bug at all [but I'm still not sure why it's
the default ;-) ]
-- Beware of bugs in the above code; I have only proved it correct, not tried it. -- Donald Knuth