When a Device Without an IP Address Wants to Play the IP Game

After I published the Source IP Address in Multicast Packets blog post, Erik Auerswald sent me several examples of network devices sending IP packets with source IP address set to 0.0.0.0:

There’s also the infamous case of switches configured with EVPN proxy ARP functionality but without a usable IP address. Those switches send ARP requests with source IP address 0.0.0.0 when trying to validate cached ARP entries, confusing Windows hosts acquiring their IP address via DHCP – ARP requests sent from IP address 0.0.0.0 are used early in DHCP address acquisition process to allow DHCP clients to detect duplicate IPv4 addresses.

The root cause common to many of these SNAFUs: a network device allows you to configure IP functionality on interfaces without usable IP addresses. I wouldn’t be surprised if those devices use whatever value is in the “interface IP address” field without checking it’s not zero. Or as Erik concluded in his email:

What I see as problematic is that all of the above often just works, so vendors have no motivation to find a clean solution. Sometimes something breaks in unexpected ways, and one starts to wonder how anything could have worked before.

Even worse, sometimes vendors publish a knowledge base article telling you how to configure other vendor’s gear to tolerate their stupidity. Static ARP entries for Microsoft NLB immediately come to mind as does this VMware mastepiece.

Revision History

2023-06-20
Fixed a blooper: Cisco APs send VRRP packets (not IGMP packets) with source IP address set to 0.0.0.0

3 comments:

  1. There is a similar case I know of where 802.1X enabled Cisco Catalyst switches do that for IP Device Tracking. Some colleagues were complaining due to not receiving an address via DHCP ("Duplicate IP Address 0.0.0.0" error). Workarounds were to have SVI in each user VLAN for probe sourcing or to increase probe timers.

    https://www.cisco.com/c/en/us/support/docs/ios-nx-os-software/8021x/116529-problemsolution-product-00.html

  2. Faced the same with Catalyst switch, the issue surfaced abruptly. Got fixed with manupulation of probe timers

  3. We recently saw a breakdown of Microsoft NLB due to a vSwitch update to version 7 which changed the default multicast behavior. This taught me how stupid some software people are regarding networks.

Add comment
Sidebar