ARP, and the day two devices claimed one address

Address Resolution Protocol is simple enough to explain in a sentence: a host shouts “who has this IP?” and the owner answers with its MAC address. Its simplicity is also its weakness, because nothing verifies the answer.

The duplicate address signature

When two devices claim the same address, the symptom is distinctive. Connectivity works intermittently and the pattern flips: it works for a while, then fails, then works again, and different hosts see different behaviour at the same moment. That is the ARP cache of each host pointing at whichever device answered last.

arp -n | sort -k3          # repeat it; one IP whose MAC changes is the sign
ip neigh show | grep -i stale
tcpdump -ni eth0 arp       # watch who answers

Most switches and routers will log it. On a Cisco device look for %IP-4-DUPADDR. Linux itself logs nothing for a plain IPv4 duplicate (probe with arping -D or watch with arpwatch); a bridge port that sees a frame carrying its own MAC, as with a cloned machine, logs received packet on eth0 with own address as source address.

Where duplicates come from

A static address inside a DHCP range is the classic. A cloned virtual machine that kept its configuration. A device moved between sites without being reconfigured. A failover pair where both members went active. A misconfigured virtual address.

Gratuitous ARP and why it matters

A device announcing its own address unprompted is doing a gratuitous ARP. It is how failover works: the new active node announces that it now owns the shared address, and everyone updates their cache. Legitimate and necessary. It is also how ARP spoofing works, which is why the same mechanism is both a feature and an attack.

Practical defence

Keep DHCP ranges and static assignments strictly separated, and document the split where the next person will find it. On managed switches, dynamic ARP inspection validates ARP against the DHCP snooping table and drops the rest. On small networks, simply knowing the signature is most of the battle: intermittent, symmetrical, affecting a whole subnet, and worse under load.