arping and ARP inspection - forcing layer-2 discovery

ARP tools test layer-2 reachability directly, bypassing IP. They are the right diagnostic when a host is on the same subnet but ping fails: the problem is somewhere between “interface is up” and “ARP succeeds”.

arping

arping sends ARP requests for a specific IP and shows the replies:

arping -I eth0 10.0.0.5                # one ARP request
arping -I eth0 -c 3 10.0.0.5           # 3 requests
arping -I eth0 -w 5 10.0.0.5           # 5 second deadline
arping -D -I eth0 10.0.0.5             # duplicate address detection

Output:

ARPING 10.0.0.5 from 10.0.0.10 eth0
Unicast reply from 10.0.0.5 [aa:bb:cc:dd:ee:ff]  0.523ms
Unicast reply from 10.0.0.5 [aa:bb:cc:dd:ee:ff]  0.612ms
Sent 2 probes (2 broadcast(s))
Received 2 response(s)

If arping succeeds but ping fails, the problem is specifically the IP layer (or above). The link is fine; the issue is routing, firewall, or IP config.

If arping fails (no reply), the host is not on the link, or it is configured not to reply to ARP, or there is a switch issue blocking the request.

Gratuitous ARP

A gratuitous ARP is an ARP reply that was not requested - it announces a new IP-to-MAC mapping. Use it to force an update on other hosts:

arping -A -I eth0 10.0.0.5             # ARP reply with this IP and our MAC
arping -U -I eth0 10.0.0.5             # unsolicited ARP

arping -A and arping -U both send gratuitous ARPs. Use when a VIP has moved to a new host and the network has stale ARP entries. Keepalived does this automatically; manual use is for testing or recovery.

arp-scan

arp-scan walks a subnet, sending ARP requests to every IP and showing what responds:

sudo arp-scan -I eth0 --localnet       # scan the local subnet
sudo arp-scan -I eth0 10.0.0.0/24      # explicit subnet
sudo arp-scan -I eth0 10.0.0.0/24 -g   # generate MAC vendor info

Output:

Interface: eth0, type: EN10MB, MAC: aa:bb:cc:00:00:01, IPv4: 10.0.0.10
Starting arp-scan 1.9.7 with 256 hosts (https://github.com/royhills/arp-scan/)
10.0.0.1    aa:bb:cc:00:00:01   Cisco Systems, Inc
10.0.0.5    aa:bb:cc:00:00:05   Dell Inc.
10.0.0.10   aa:bb:cc:00:00:10   (host itself, excluded)
10.0.0.20   aa:bb:cc:00:00:20   Apple, Inc.

4 packets received via interface eth0, 0 from non-local subnets
256 hosts scanned in 1.234 seconds (207.5 hosts/sec)

Use arp-scan to:

• Find which IPs are actually in use on the subnet (before assigning a static IP).
• Verify a new host joined the network.
• Detect MAC-spoofing or rogue devices.

Read the neighbour cache

ip neigh is the modern equivalent of arp -a:

ip neigh show
ip neigh show dev eth0
ip -4 neigh show
ip -6 neigh show

The state matters:

• REACHABLE: confirmed recently; OK to send.
• STALE: not confirmed recently; usable but the next use triggers a re-confirmation.
• DELAY: confirmation probe has been scheduled.
• PROBE: actively probing to confirm.
• FAILED: probe failed; entry is unusable.
• INCOMPLETE: resolution is in progress.

A host with a FAILED entry cannot send to that IP at layer 2 even though the route exists. The neighbour is unreachable.

Force ARP resolution

ip neigh flush all                  # flush all entries
ip neigh flush dev eth0             # flush one interface
ip neigh del 10.0.0.5 dev eth0      # delete one entry

Flushing forces the host to re-resolve everything. Useful when the cache is suspected stale (e.g. after a switch maintenance).

Deleting a single entry is the safer version of the same move: it re-resolves one neighbour without dropping the gateway binding that the rest of your session depends on.

When to use ARP tools

Use ARP tools when:

• A host on the same subnet is unreachable.
• A new VIP has just moved to a different host (force the network to update).
• You need to discover what is on a subnet.
• You suspect switch issues (port security, MAC limiting).

Do not use ARP tools for:

• Hosts on different subnets (use ping, traceroute).
• Cross-VLAN reachability (use the gateway as proxy).
• Performance problems (use iperf3, sar).

Knowledge check