IP neighbor under Linux: finding a network neighbor without using arp

A machine on the network responds intermittently, a gateway remains associated with the wrong MAC address, or an entry displays FAILEDBefore restarting the interface, check the neighborhood table maintained by the kernel.

The order ip snow advantageously replaces the old controls arp -a And arp -nIt covers IPv4 neighbors learned with ARP and IPv6 neighbors discovered with NDP. Most importantly, it allows you to read their state, delete a single entry, and verify its reconstruction without clearing the entire cache.

Tux inspects the neighbors of a local network with active, old, and inaccessible links. — Ip neigh displays the kernel’s known IPv4 and IPv6 neighbors and their resolution status.

Find the interface used to contact the neighbor

Don’t choose eth0 Out of habit. Display the interfaces, then ask the kernel which route it would use to reach the requested address:

ip -brief link

ip route get 192.168.1.50

ip route get indicates in particular the interface after dev and the local address after srcIf the destination involves a gateway, the level 2 neighbor will be that gateway, not necessarily the final address. The guide on IP routing under Linux explains this difference.

Also check the link status before blaming the cache:


ip addr show dev enp1s0

An interface DOWN or without a carrier, it will not find any neighbors. The article on helps to distinguish UP, LOWER_UP and a truly usable address.

List IPv4 and IPv6 neighbors with ip neigh

First display the complete table, then limit the display to the relevant interface:

IP Neigh show
ip neigh show dev enp1s0

To separate the two types of addresses:

IP -4 Neigh show dev enp1s0
IP -6 Neigh show dev enp1s0

192.168.1.50 dev enp1s0 lladdr 52:54:00:12:34:56 STALE

The address after lladdr is the MAC address known to this neighbor. The final state describes whether the resolution was successful or failed. To target a single address without scanning the entire table:

ip neigh show to 192.168.1.50 dev enp1s0
ip neigh get 192.168.1.50 dev enp1s0

The table is not a complete inventory of the network. It primarily contains the devices with which the kernel has recently communicated or that it is trying to reach. A silent machine can therefore be absent without being powered off.

Understanding REACHABLE, STALE, INCOMPLETE and FAILED

REACHABLE : the neighbor was recently confirmed;
STALE The entrance is known, but its accessibility has not been confirmed recently. This is not a mistake;
DELAY Or PROBE : the kernel actively checks if the neighbor is still responding;
INCOMPLETE : resolution is in progress and no usable MAC address has yet been received;
FAILED : the attempts to resolve it have failed;
PERMANENT : the entry was added statically and should not expire like a dynamic entry.

You can filter for a specific state:

ip neigh show dev enp1s0 nud reachable
ip neigh show dev enp1s0 nud stale
ip neigh show dev enp1s0 nud failed

An entry STALE can become again REACHABLE as soon as traffic confirms the neighbor. Conversely, a line FAILED Repeated error code points more towards a bad interface, a missing host, an incorrect VLAN, a Wi-Fi problem, a duplicate address, or a failing physical link.

Generate simple traffic to the address, then immediately reread the entry:

ping -c 3 192.168.1.50
ip neigh show to 192.168.1.50 dev enp1s0

To track changes during the test:

watch -n 1 'ip neigh show dev enp1s0'

If the entrance remains INCOMPLETE FAILEDObserve the ARP and NDP exchanges on the correct interface:

sudo tcpdump -ni enp1s0 'arp or icmp6'

An ARP request that goes unanswered indicates the problem lies before the IP address: the device is offline, the wrong switch port, the wrong VLAN, the cable, Wi-Fi, or the address doesn’t exist. If no request is sent, reroute and reconnect the interface. See the guide on… shows how to limit capture without recording all traffic.

On Ethernet, you can also control speed, duplex, and carrier with ethtoolDeleting a neighboring entry will not fix a link that is negotiating poorly or dropping out.

Delete a single entry and then verify its reconstruction.

If the MAC address is clearly old or incorrect, delete only the targeted entry. On a remote server, maintain a second SSH session and a backup console, especially if you are interacting with the neighboring server acting as a gateway.

sudo ip neigh del 192.168.1.50 dev enp1s0
ping -c 3 192.168.1.50
ip neigh show to 192.168.1.50 dev enp1s0

For a link-local IPv6 address, the interface is essential:

sudo ip -6 neigh del fe80::5054:ff:fe12:3456 dev enp1s0
ping -6 -c 3 fe80::5054:ff:fe12:3456%enp1s0
IP -6 Neigh show dev enp1s0

The kernel must recreate the entry upon the next exchange. Compare the MAC address and the state. If the wrong address returns, look for a duplicate IP address, a static configuration, a cloned virtual machine, or a device responding instead of the expected neighbor. Repeat. will not correct this cause.

Clear the cache only when the perimeter is under control.

Start by displaying what you are going to remove. To clean up only the entries that have already failed on an interface:

ip neigh show dev enp1s0 nud failed
sudo ip neigh flush dev enp1s0 nud failed

The following command is much broader:

sudo ip neigh flush dev enp1s0

It forces the rediscovery of several neighbors and can cause a temporary interruption of active connections. Do not run it automatically on the interface hosting your SSH session. Targeted removal is easier to control and provides better diagnostics.

There documents operations show, get, del And as well as all NUD states. Keep this order: route, interface, table, state, test traffic, targeted deletion. Full dumping comes last.