Arp Behavior Change - Backward Compatiblity Bug
In windows 7 we have noticed a fundamental behavior change in arp we need to be backward compatible. In you create a static route for an ip address either local or off the local subnet to a non-available address to the network such as 1.1.1.1 the system will arp for the 1.1.1.1 address and fail prior to W7. This is the proper behavior and we use this to create DHCP backholes for agent controls. In W7 the same thing occurs, but an additional step happens. The system will now arp on the local subnet even though we told it not to and to use the stated route. Is there a registry entry we can change to be compatible with Vista and prior behavior. Also were is the doc for the W7/2K8R2 tcpip registry settings. I notice some new ones DontAddDefaultGatewayDeafult, EnableWsd, QaulifyingDestinationThreshold that might be relevant but how would we know? Thanks, Brad.
September 18th, 2009 10:47pm

I have just run into this very same problem. Except in my case, windows is ignoring a directly connected route instead of a static route. Windows 7 Laptop Ethernet Connection 192.168.0.1 255.255.255.0 Mobile Broadband Connection 10.24.33.2 255.255.255.255 Only default gateway is via the mobile broadband connection. Windows XP Desktop Ethernet Connection 192.168.0.2 255.255.255.0 Both PC's are connected to an ethernet switch. These are the only devices connected to the ethernet switch. When the Windows XP Desktop is turned off the windows 7 laptop can still ping 192.168.0.2 (It's completely ignoring the connected route out the ethernet interface and pinging some box over the internet (I'm guessing 192.168.0.2 used by my internet provider on something, the response times are in excess of 50ms). I did state that both machines are connected to an ethernet switch so when the windows XP machine is turned off, the ethernet interface is still "Up" on my Windows 7 Laptop. I've used packet capture software wireshark to verify. When the XP machine is turned off the first time i ping 192.168.0.2 windows sends out an ARP request on the ethernet interface as expected and the ping shows "destination host unreachable" then windows immediately sends the packet to my default gateway instead via my mobile broadband connection completely ignoring the routing table. Furthermore if i run a ping with the -t parameter (continiuos) while i'm getting replies from 192.168.0.2 i review the arp table. 192.168.0.2 is not listed, verifying that windows is sending it out over the internet. If i then delete the arp entry with arp -d 192.168.0.2(Even though its not listed in the first place), Windows will then send out an arp request on the ethernet interface as expected and ping will again report "destination host unreachable" once before repeating the cycle and ignoring the routing table again. I've already tried disabling Dead-Gateway-Detection and I know for certain that this bug was introduced with Windows 7. How did you work around this new flawed new IP stack?
Free Windows Admin Tool Kit Click here and download it now
May 4th, 2011 1:10am

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics