SECURITY WARNING: Never run commands you don't understand. Always review code before execution. Use at your own risk.
Network New Added 8 September 2026

Linux: duplicate IPv4 address detected on the network

Two hosts answer ARP for the same address, so switches flap the MAC between ports and traffic reaches whichever machine replied last. It is typical of a static address inside a DHCP range, a failed failover where both nodes kept a virtual IP, or a cloned VM.

Quick fix

Read the commands before running them. Anything that restarts a service, deletes data or changes permissions should be tried on a non-production system first.

Quick fix
# Who else claims it?
arping -D -I eth0 -c 3 192.0.2.10
ip neigh show 192.0.2.10
sudo tcpdump -ni eth0 arp and host 192.0.2.10

# Compare the MAC that answers with the one you expect
ip -br link show eth0

# Common causes
# - static IP inside the DHCP pool: shrink the pool or reserve the lease
# - both keepalived nodes MASTER: check VRRP traffic is not blocked
sudo journalctl -u keepalived | grep -i 'state\|vrrp'

How to diagnose Network errors

Network errors are precise if you read them literally. Connection refused means a machine answered and actively rejected: nothing is listening on that port. Timeout means nothing answered at all, which points at a firewall silently dropping packets or a wrong address. Connection reset means the peer accepted then abruptly closed, often a proxy, a protocol mismatch, or an application crash. Distinguishing those three saves most of the debugging time.

If the quick fix above does not resolve it, work through these steps. They apply to this whole class of error, not just to this one message, which is usually what saves the time.

  1. Test layer by layer: ping for reachability, nc -zv host port for the port, then the application protocol. Do not skip to the application layer.
  2. Confirm what is listening locally with ss -tulpn. "Connection refused" on localhost almost always means the service bound to 127.0.0.1 when it needed 0.0.0.0, or vice versa.
  3. Capture packets when the error is ambiguous: sudo tcpdump -ni any port 443 and host x.x.x.x. A RST is visible; a silent drop is visible as unanswered SYNs.
  4. For intermittent failures under load, check ephemeral port exhaustion and conntrack table limits (ss -s, conntrack -S) before blaming the network.
  5. Suspect MTU when small requests succeed and large ones hang. Test with ping -M do -s 1472 and reduce until packets pass.

Tools worth reaching for

  • ss -tulpn
  • nc -zv
  • tcpdump
  • mtr
  • curl --connect-timeout
  • iptables -L -n -v

Authoritative references

Primary documentation for this error, worth reading before applying any fix in production.

rfc-editor.org

Related Network errors

See all 35 Network errors →

Browse other categories

Something missing or wrong?

This entry is maintained by hand. If the fix is out of date, incomplete, or you have a better one, email a correction and it will be reviewed.