arminl
asked on
IP routing mystery -- bug or feature?
Common IP wisom says that two nodes on the same physical network having different IP network adresses (e.g. 10.0.0.1/255.0.0.0 and 192.168.1.1/255.255.255.0)
Try this: set up two boxes like above, connect them via a crossover cable, and enter the own adress in each boxes standard gateway setting. Now see them successfully ping each other. Wow.
I have checked this using Windows 2000, NT4, Windows 95 and the LAN Manager for DOS IP client, all behave the same way. Have no non-MS clients here.
Is this normal (RFC compliant) IP behavior working on non-Microsoft IP stacks as well? Is this just coincidence or by design?
Armin Linder
Try this: set up two boxes like above, connect them via a crossover cable, and enter the own adress in each boxes standard gateway setting. Now see them successfully ping each other. Wow.
I have checked this using Windows 2000, NT4, Windows 95 and the LAN Manager for DOS IP client, all behave the same way. Have no non-MS clients here.
Is this normal (RFC compliant) IP behavior working on non-Microsoft IP stacks as well? Is this just coincidence or by design?
Armin Linder
On ethernet each packet goes to every machine on the cable and with a crossover cable it's obviously got only one place to go and will make it to the other machines network card where the ip layer must recognise its ip address
your assumption is not correct. unless there is a default route for the given destination network, the system will assume that the destination is on the local network.
so the source computer just spits the packet out onto the ethernet as a broadcast, and the destination hears it.
this is doubly so if there is no default router specified.
so i would suggest that you are seeing expected behaviour.
cheers.
so the source computer just spits the packet out onto the ethernet as a broadcast, and the destination hears it.
this is doubly so if there is no default router specified.
so i would suggest that you are seeing expected behaviour.
cheers.
As soon as TCP/IP is installed there is an entry in the routing table for the default route (route used when all others have been checked for gateway):
NETWORK MASK GATEWAY
0.0.0.0 0.0.0.0 <local IP address>
That address allows for packets destined for ALL networks of ALL sizes to be remoted via local card.
NETWORK MASK GATEWAY
0.0.0.0 0.0.0.0 <local IP address>
That address allows for packets destined for ALL networks of ALL sizes to be remoted via local card.
To view your routing table you can use ROUTE PRINT from Command Prompt.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
> Is this normal
- Yes
> just coincidence or by design?
- design
Both boxes are on same wire. So each hear's other's transmission regardless.
Each sends ping packet out, assuming it will be routed.
Each receives return packet, assuming it was routed
So, beware assumptions (do not neglect the report of round trip time. It can clue you when some relocated employee takes their PC with them and simply plugs it in at new location without telling anybody)
Actually, playing with routing options, you could consider running:
traceRt
rather than ping.
Try it on your scenarios above.
- Yes
> just coincidence or by design?
- design
Both boxes are on same wire. So each hear's other's transmission regardless.
Each sends ping packet out, assuming it will be routed.
Each receives return packet, assuming it was routed
So, beware assumptions (do not neglect the report of round trip time. It can clue you when some relocated employee takes their PC with them and simply plugs it in at new location without telling anybody)
Actually, playing with routing options, you could consider running:
traceRt
rather than ping.
Try it on your scenarios above.
But SunBow, the initial transmission (ARP) would not happen if the DG was not present. You never broadcast an ARP for an address on another subnet you send your packet to the DG for forwarding. How do you find the MAC address of the DG? you ARP for it. That's the only reason it works. If you had static routes entered rather than a DG then neither experiment works.
ASKER
Just by chance (believe it or not) I have today found the "official" Microsoft documentation within the readme file for service-pack 4. In chapter 3.5 they write
...
"Microsoft DHCP Server can be configured to set a client's default gateway equal to its IP address. This causes the client to use the Address Resolution Protocol (ARP) for all IP addresses on the local subnet and is useful for routerless networks. To enable this feature for all clients in a scope, add the following value to the registry:
HKEY_LOCAL_MACHINE\SYSTEM\
It is not only a feature, but can even be distributed in a DHCP environment. Wether this is RFC compliant or not and wether other IP stacks behave the same way still needs to be seen. Anyone having a Linux or something alike at hand ...?
...Armin
...
"Microsoft DHCP Server can be configured to set a client's default gateway equal to its IP address. This causes the client to use the Address Resolution Protocol (ARP) for all IP addresses on the local subnet and is useful for routerless networks. To enable this feature for all clients in a scope, add the following value to the registry:
HKEY_LOCAL_MACHINE\SYSTEM\
It is not only a feature, but can even be distributed in a DHCP environment. Wether this is RFC compliant or not and wether other IP stacks behave the same way still needs to be seen. Anyone having a Linux or something alike at hand ...?
...Armin
ASKER
Somehow I need to finish up this issue, cannot leave it pending forever. Grading is quite difficult, since almost every reply contains some infos I do not agree with. From top to bottom:
tobyk: too trivial. You can also use any other kind of networking gear (hub, switch, bridge) in between the machines and bring in as many additional machines as you like, the test will still succeed though the packet now have choices where to go (assuming that a passive packet has any choice at all :-)
meverest: don't agree. The packet is not a broadcast (check it using the network monitor). In fact the funny thing is that the packet leaves the local IP stack at all.
nenadic: and so ...? Sure, that's how a default gateway always works. the funny thing here is that the Gateway destination adress is not a remote adress like normally used, but the own adress. So I assumed some confusion within the IP stack:
IP checks wether destination is in the same IP subnet --> no
Looks up a gateway adress to forward the packet to --> finds it's own adress.
Since the packet has already reached it's destination --> do what? Run into an indefinite loop? Discount the TTL and then drop the packet?
sunbow: "assuming it will get routed". IP packets never "get" routed the way I understand your comment in a manner that there are routers actively listening for packets that need routing. "assuming it was routed": in my understanding a client doesn't care where from it gets a packet, as long as the destination hardware adress is his own the client will accept the packet and then see, wether the destination IP is his own. If yes, the packet is delivered to higher protocols like TCP, ICMP or UDP, if no, and IP forwarding is enabled, the client sqeezes the packet through his own routing engine and eventuelly resends the packet to someone else for further delivery. Otherwise the packet is dropped.
Andyalder: correct. Are you sure that a static route would not work? I haven't tried this yet, so you could save me some time because the original test bed is not available at the moment, and why setting up another one and try if someone else already has the knowledge. EE is a huge time safer in some cases.
My own theory:
--------------
Obviously IP, after passing the packet to its routing engine and finding its own adress as the gateway adress (I almost bet it doesn't care wether the route was a static route or the default gateway) just spits out an ARP broadcast (which succeeds, of course, if the destination host is on the same LAN segment). The ARP reply makes it back to the questioner, because the ARP query packet does also contain the hardware and IP adress of the questioner, so the answering host has no difficulties to generate a reply packet. Then IP at the sender side sends the packet to the hardware adress like usual. This is very much the way andyalder described in his scenario, it's just the DG detail that needs to be verified, I don't see a technical reason why this should not work using a static route.
So the essence of my question is, wether or not this kind of implementation is usual IP stack implementation practice, or a Microsoft specific implementation. If the latter was the case using it would fail with anything but Microsoft IP stacks, and I'd never seriously consider telling anyone to make use of it.
Unfortunately I don't have any non-MS boxes here. I'll credit a fair amount of the points to someone who takes a bit of time to reproduce this setup with a MS box and a non-MS box, and tell us wether it works with non-Microsoft stacks as well or not, or, alternatively, finds the RFC where such a behaviour of the IP stack is mentioned so I can assume that others may have implemented it as well.
...Armin
tobyk: too trivial. You can also use any other kind of networking gear (hub, switch, bridge) in between the machines and bring in as many additional machines as you like, the test will still succeed though the packet now have choices where to go (assuming that a passive packet has any choice at all :-)
meverest: don't agree. The packet is not a broadcast (check it using the network monitor). In fact the funny thing is that the packet leaves the local IP stack at all.
nenadic: and so ...? Sure, that's how a default gateway always works. the funny thing here is that the Gateway destination adress is not a remote adress like normally used, but the own adress. So I assumed some confusion within the IP stack:
IP checks wether destination is in the same IP subnet --> no
Looks up a gateway adress to forward the packet to --> finds it's own adress.
Since the packet has already reached it's destination --> do what? Run into an indefinite loop? Discount the TTL and then drop the packet?
sunbow: "assuming it will get routed". IP packets never "get" routed the way I understand your comment in a manner that there are routers actively listening for packets that need routing. "assuming it was routed": in my understanding a client doesn't care where from it gets a packet, as long as the destination hardware adress is his own the client will accept the packet and then see, wether the destination IP is his own. If yes, the packet is delivered to higher protocols like TCP, ICMP or UDP, if no, and IP forwarding is enabled, the client sqeezes the packet through his own routing engine and eventuelly resends the packet to someone else for further delivery. Otherwise the packet is dropped.
Andyalder: correct. Are you sure that a static route would not work? I haven't tried this yet, so you could save me some time because the original test bed is not available at the moment, and why setting up another one and try if someone else already has the knowledge. EE is a huge time safer in some cases.
My own theory:
--------------
Obviously IP, after passing the packet to its routing engine and finding its own adress as the gateway adress (I almost bet it doesn't care wether the route was a static route or the default gateway) just spits out an ARP broadcast (which succeeds, of course, if the destination host is on the same LAN segment). The ARP reply makes it back to the questioner, because the ARP query packet does also contain the hardware and IP adress of the questioner, so the answering host has no difficulties to generate a reply packet. Then IP at the sender side sends the packet to the hardware adress like usual. This is very much the way andyalder described in his scenario, it's just the DG detail that needs to be verified, I don't see a technical reason why this should not work using a static route.
So the essence of my question is, wether or not this kind of implementation is usual IP stack implementation practice, or a Microsoft specific implementation. If the latter was the case using it would fail with anything but Microsoft IP stacks, and I'd never seriously consider telling anyone to make use of it.
Unfortunately I don't have any non-MS boxes here. I'll credit a fair amount of the points to someone who takes a bit of time to reproduce this setup with a MS box and a non-MS box, and tell us wether it works with non-Microsoft stacks as well or not, or, alternatively, finds the RFC where such a behaviour of the IP stack is mentioned so I can assume that others may have implemented it as well.
...Armin
Most of it stems from ftp://ftp.isi.edu/in-notes/rfc950.txt but although this is still the internet standard bits of it are ignored. e.g. can't enter a subnet mask of 255.255.255.88 on any machine I've ever seen. I observed that the DG on wrong subnet still works quirk on SCO 3.2v4.2 about 4 years ago.
When I set a static route rather than DG it does not work for me, please confirm this someone.
When I set a static route rather than DG it does not work for me, please confirm this someone.
ASKER
Want to close this question. After re-reading your comments I credit the points to andyalder, feel he helped me most.
To settle the additional questions not solved yet:
By trial and error (NT4, SP6)
* entering a dedicated route to a remote subnet pointing to my own IP does work, as long as there is no additional default gateway specified. If there is a default gateway specified, it seems to take precedence.
* Lacking any other OS installations than Microsofts I used two print boxes (D-Link DP-101 and HP JetDirect EX) and set them up having their own adress as default gateway. Both boxes took the setting, and worked like intended (could print from clients in other subnets without a router, if they were located on the same LAN)
So it seems that this way of implementing the DG is common practice, not just a Microsoft thing.
Armin Linder
To settle the additional questions not solved yet:
By trial and error (NT4, SP6)
* entering a dedicated route to a remote subnet pointing to my own IP does work, as long as there is no additional default gateway specified. If there is a default gateway specified, it seems to take precedence.
* Lacking any other OS installations than Microsofts I used two print boxes (D-Link DP-101 and HP JetDirect EX) and set them up having their own adress as default gateway. Both boxes took the setting, and worked like intended (could print from clients in other subnets without a router, if they were located on the same LAN)
So it seems that this way of implementing the DG is common practice, not just a Microsoft thing.
Armin Linder