I have recently noticed this behavior of ARP in Windows 11 and Server 2025 – it seems novel compared to Windows 10, and it’s a pain.
Scenario: assume I have a machine with two network interfaces. Let’s say a notebook with LAN and wifi. Or a machine that has direct access to more than one LAN segment. Only one network has a default gateway.
Suppose I’m trying to ping something on a network that I’m directly connected to. The PHY link is up and running, handshaked to a switch. The IP interface is configured, there’s only one local interface with that subnet, the IP address is either configured fixed or established by DHCP. Just up and running for all practical purposes.
Suppose that the node I’m trying to ping, within the local subnet, does not exist. Down, or IP address misconfigured, or something. Just does not respond to ARP. Now comes the catch.
Expected behavior: my windows should keep trying ARP for the IP address that I told ping to try. Failing ARP, it should report
Reply from <my local IP for that subnet>: Destination host unreachable
Should keep trying this forever / until I stop the ping, on the interface that has the relevant subnet locally configured.
Instead, Windows 11 does this:
-
try ARP for the locally connected IP Address
-
after reporting “Destination host unreachable” just once = probably just a few ARP requests failed,
-
it starts sending my ping requests to the default gateway, on a different interface! In spite of having a “directly connected” route to that IP ! on an interface that is up and running!
-
such that, if I rectify the benign error in my ways, such as plug in an Ethernet patch cord to the legit locally connected node, or power it up, or correct its IP address configuration, …
-
my workstation where I’m pinging from, will not notice that the node is in fact now alive, and the ping will keep failing! With a message “Destination net unreachable” coming from the legit default gateway, still getting my ping requests, that should never be sent to that gateway in the first place!?
I’ve seen this happen in one other scenario, only slightly different:
-
I have a notebook with an Ethernet and a WiFi. The Ethernet has a fixed IP address from the local LAN, and a default gateway. The Wifi port is left to ask for DHCP, but will get an IP address from that same subnet, just a different one, allocated from a DHCP pool.
-
I’m attached to WiFi, the Ethernet port is not connected (PHY link down).
-
I try to ping something on the local subnet, now attached via Wifi. The desired target IP is again unresponsive for some reason.
-
the ping tool again tries the local ARP request only until the first “host unreachable”, then apparently attempts ARP via the physical Ethernet, that is PHY link down, and picks one of its configured IP addresses (local subnets) that it apparently ikes most, and reports an “unreachable” from the respective locally configured IP address…
-
note that Windows, since the dawn of time, traditionally ignores local network ports that are “link down”, even if there are some IP addresses configured. For the routing process, a port that’s down does not exist. (In contrast to Linux, which happily tries to forward traffic to an interface that is down.) The observed behavior in Windows 11 / 2025 in this example would seem to violate that rule…
-
interestingly, I’ve just tried to re-test this latter scenario, and I’m unable to reproduce the misbehavior. It has happened to me today in the morning, and the difference was, that after arrival, after waking up the Windows in my laptop from sleep, I have not plugged in the metallic Ethernet, I went straight for the WiFi. Whereas now that I’m trying to reproduce this, I have just unplugged my metallic Ethernet, to force the machine to try WiFi. The interface failover itself might be a function of some 3rd-party software, or maybe nowadays it’s a Windows feature, not sure. The box reports seeing my WiFi ESSID’s in the ether, but doesn’t bother to try and associate – as long as metallic LAN is connected.
I wonder if the disputed ARP misbehavior is a feature of the IP stack, or of the ping tool. Either way, this behavior is pretty counter-productive, if I should use a euphemism. A network troubleshooting tool that does not notice, when a locally attached node comes online, and keeps reporting an “unreachable” error, following a negative entry in its ARP cache or what.
Googling has brought up EnableDeadGWDetect, which appears to be “on” by default. I’ve tried disabling it, and it does not rectify my symptoms. Yes I did reboot after the registry mod.
The quickest remedy is to stop ping, and issue an
netsh interface ip delete arpcache
Any clues are welcome.
