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. and cannot exchange any IP packets without a third box having routing software installed.

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
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

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.

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          <local IP address>
That address allows for packets destined for ALL networks of ALL sizes to be remoted via local card.
Become a Certified Penetration Testing Engineer

This CPTE Certified Penetration Testing Engineer course covers everything you need to know about becoming a Certified Penetration Testing Engineer. Career Path: Professional roles include Ethical Hackers, Security Consultants, System Administrators, and Chief Security Officers.

To view your routing table you can use ROUTE PRINT from Command Prompt.
andyalderSaggar maker's framemakerCommented:
It is the presence of the default gateway. You always ARP for the DG even if it is on another subnet.

You can take your experiment one step further. One dual homed machine and two single homed:




Client 1 can ping client 2 quite happily even though we have set the hosts DGs up as the 'wrong' nic in the router.

I found the RFC once that says that you have to set the DG as one of the interfaces of the router, it does not say it should be the interface you are connected to. Wish I could find it again as if win2k is the router it replies to the ARP on the interface bound to that subnet rather than the interface it recieved the broadcast on which is really a bug.

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
> 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:
rather than ping.

Try it on your scenarios above.
andyalderSaggar maker's framemakerCommented:
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.
arminlAuthor Commented:
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\CurrentControlSet\Services\DHCPServer\Subnets\a.b.c.d\SwitchedNetworkFlag=1 (REG_DWORD)"

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 ...?

arminlAuthor Commented:
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.


andyalderSaggar maker's framemakerCommented:
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 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.
arminlAuthor Commented:
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
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Windows Networking

From novice to tech pro — start learning today.