IP address 0.0.0.0 conflict error message

If you have ever come across a error message "Duplicate IP Address 0.0.0.0" in the event logs by clients running Microsoft Windows Vista and later versions & not sure of what the problem is? Don't worry it is not a legitimate IP address conflict.

With Microsoft Windows Vista and later versions, Microsoft has introduced a new mechanism as mentioned below in order to detect duplicate addresses on the network when the DHCP process occurs.

Before beginning to use an IP address whether manual configured, DHCP or some other means, a host must test to see if the address is already in use, by broadcasting ARP Probe packets. This also applies when a network interface transitions from an inactive to an active state, when a computer awakes from sleep, when a link-state change signals that an Ethernet cable has been connected, when an 802.11 wireless interface associates with a new base station, or when any other change in connectivity occurs where a host becomes actively connected to a logical link.

When the host probes to see if an address is already in use by broadcasting an ARP Request for the desired address. The client MUST fill in the sender hardware address (MAC address) field of the ARP Request with the hardware address of the interface through which it is sending the packet. The 'sender IP address' field MUST be set to all zeroes; this is to avoid polluting ARP caches in other hosts on the same link in the case where the address turns out to be already in use by another host. The 'target hardware address' field is ignored and SHOULD be set to all zeroes. The 'target IP address' field MUST be set to the address being probed. 

An ARP Request constructed this way, with an all-zero 'sender IP address', is referred to as an 'ARP Probe'. When ready to begin probing, the host should then wait for a random time interval selected uniformly in the range zero to PROBE_WAIT seconds, and should then send PROBE_NUM probe packets, each of these probe packets spaced randomly and uniformly, PROBE_MIN to PROBE_MAX seconds apart. This initial random delay helps ensure that a large number of hosts powered on at the same time do not all send their initial probe packets simultaneously.

Unfortunately this change in Windows behavior has conflicted with CISCO's IP device tracking behavior.

Cisco IOS uses the Address Resolution Protocol (ARP) Probe sourced from an address of 0.0.0.0 in order to maintain the IP device-tracking cache when IP device tracking feature is enabled on a Cisco IOS switch. The purpose of IP device tracking is for the switch to obtain and maintain a list of devices that are connected to the switch via an IP address. The probe does not populate the tracking entry. It is used in order to activate and maintain the entry in the table after it is learned. This IP address is then used when an Access Control List (ACL) is applied to the interface in order to substitute the source address in the ACL with the client IP address. This function is critical whenever access lists are used with 802.1x, or any other Flex-Auth function on Cisco switches.

If the switch sends out an ARP Probe sourced from an address of 0.0.0.0 for the client while the Windows PC is in its duplicate-address detection phase where it sets the 'sender IP address' field to 0.0.0.0,  Windows detects the probe as a duplicate IP address and presents the user with a message that a duplicate IP address was found on the network for 0.0.0.0. The PC does not obtain an address, and the user must either manually release/renew the address, disconnect and reconnect to the network, or reboot the PC in order to gain network access.

There are multiple methods in order to workarounds this issue.

a) The primary method used in order to workaround the issue is to delay the probe from the switch, so that Windows has time to finish duplicate IP detection. Enter this command in order to delay the probe:

    ip device tracking probe delay 10

The RFC specifies a ten-second window for duplicate address detection, so if you delay the device-tracking probe on the switch, it resolves the issue in nearly all cases. In addition to probe-delay, the delay also resets when the switch detects a probe from the PC. For example, if the probe timer has counted down to five seconds and detects an ARP Probe from the PC, the timer resets back to ten seconds. In rare circumstances, the PC sends an ARP Probe milliseconds before the switch sends its probe, which still triggers a duplicate address message to the end user. This command was introduced in Version 15.0(1)SE on 2900, 3500, and 3700 Series switch platforms, Version 15.0(2)SG on the 4500 Series switch platform, and Version 12.2(33)SXI7 on the 6500 Series switch platform.

b) If the previous method does not fully resolve the issue, you can configure the switch in order to send a non-RFC compliant ARP Probe in order to source the probe from the Switch Virtual Interface (SVI) in the VLAN where the PC resides. Enter this command in order to do this:

    ip device tracking probe use-svi

This configuration does not trigger the duplicate address detection error message in Windows. In order to use this method, an SVI must exist on every switch in every VLAN where Windows clients who run DHCP reside. This method is difficult to scale, so Cisco recommends that you use IP device-tracking probe delay as the primary method. SVI is not currently available on the 6500 Series switch platform. This command was implemented in Version 12.2(55)SE on 2900, 3500, and 3700 Series switch platforms, and in Version 15.1(1)SG on the 4500 Series switch platform.

c) Another method used in order to resolve this issue involves a troubleshoot of the client in order to determine why duplicate address detection occurs so late after the link comes online. The switch has no way to determine when this process occurs, so you must estimate how long to set the probe delay in order to prevent the conflict. In order to effectively troubleshoot why duplicate address detection occurs so late, further information on the behavior of the IP device-tracking probe is useful:

The ARP probe is sent under two circumstances:

    A link associated with a current entry in the IPDT database moves from a DOWN to an UP state.
    A link already in the UP state that is associated with an entry in the IPDT database has an expired probe interval.

Enter this command in order to set the IP device-tracking probe interval:

ip device tracking probe interval <seconds>



The default interval is thirty seconds. In order to view this information, enter this command:

show ip device tracking all

IP Device Tracking = Enabled
IP Device Tracking Probe Count = 3
IP Device Tracking Probe Interval = 30
IP Device Tracking Probe Delay Interval = 0
------------------------------------------------------------
IP Address  MAC Address   Vlan  Interface            STATE
------------------------------------------------------------
30.30.30.30   28D2.4418.66BF  30  GigabitEthernet3/30  INACTIVE

Total number interfaces enabled: 1
Enabled interfaces:
   Gi3/30

Leave your comment below