Q: Every now and then, I get a pop-up on my work computer that reads, “There is an IP address conflict with another system on the network.” This happens at times when I need my network the most, but, in order to recover, a reboot is required. So far I have been unable to find out what is causing it.
A: An IP address conflict is a network problem that is caused by having two network devices (computers, printers, routers, firewalls, etc.) with the same IP address on the same broadcast domain, local area network (LAN) or virtual local area network (VLAN) at the same time.
The IP protocol, version 4, requires every network device to have a unique identifier — an IP address — in order to function properly. When two network devices have the same identifier, the traffic that needs to get to them will be inconsistent. It might be that all the traffic will end up in only one of them, or that one packet will go to one and another will go to the other. This is unacceptable and can cause major disruption in the transferred information, and therefore network devices that implement the IP protocol are programmed to detect and avoid those conflicting conditions.
The detection mechanism is usually based on a probe address resolution protocol (ARP), where the host sends a broadcast ARP probe packet upon the interface configuration — either manual or dynamic addressing network (DHCP). At this point, a host with a conflicting address will reply to the probe packet and will cause the newly configured host to stop using its newly assigned IP address. When this happens in a DHCP, address renewal or a reboot will cause the conflicting device to request a new address and to eliminate the conflicting conditions. According to your description, this is probably the case. RFC 5227 is covering this mechanism in depth for the deep-diving readers.
An IP address conflict is almost always a configuration mistake. While software bugs are the exception to that, I have yet to see one that causes this. It can be a mistake made by the network administrator in a DHCP-based network or by another user if the addresses are allocated manually in your network. In a DHCP environment, it can be caused by having two DHCP servers on the same network, or by having long address lease time and hosts that do not have a battery-based clock, which keeps track of time while they are turned off, like a VMware guest OS in suspended mode. Another common DHCP scenario is when an excluded range is not allocated for devices that have a static IP in a DHCP-controlled subnet. In a static or manual addressing network, a user might assign an address that is not available and create a conflict by doing that.
The way to detect and fix these conflicts depends on the network size. In a small office environment — up to 10 network devices — you can check the settings on all of them and find the conflicting device. In larger networks, it can take days to cover all network devices, and a better approach is to use the media access control (MAC) address to track down the conflicting device.
The first step is to find the two conflicting MAC addresses. You can usually find this info in the event log of a Windows-based device — sometimes the error message itself will contain the conflicting device’s MAC address. Once the address is identified, you can use the network switches to track down a network device by running a query against the layer two forwarding table and finding out what port is connected to the conflicting address. In a Cisco-switching-based network, the command “show MAC-address-table” will display the entire layer two forwarding database, and by using the question mark, you can learn how to leverage additional parameters to show only the information you want, because in a large network, the results can be multiple pages long.
Avner Izhar, CCIE, CCVP, CCSI, is a consulting system engineer at World Wide Technology Inc., a leading systems integrator providing technology and supply chain solutions. He can be reached at editor (at) certmag (dot) com.