Displaying the current ARP table is useful when one IPv4 peer or next hop stops responding even though the interface and route still look normal. The kernel neighbor cache shows whether a usable layer-2 mapping exists for that address before time is spent changing routes or static entries.

On current Linux systems, ip neigh reads the kernel neighbor table, and the IPv4 portion of that table is the ARP cache. Each entry records the destination IP, the learned link-layer address, the interface it belongs to, and the current neighbor-unreachability state such as REACHABLE, STALE, or FAILED.

An empty lookup does not automatically mean the peer is broken. Neighbor entries age out, some only appear after traffic is sent, and `ip neigh show` can mix IPv6 neighbor data into the same output. For an ARP-specific check, `ip -4 neigh show` keeps the result focused on IPv4 entries.

Steps to display ARP entries with ip neigh:

  1. Show the current IPv4 ARP entries from the kernel neighbor table.
    $ ip -4 neigh show
    172.17.0.1 dev eth0 lladdr 4a:0d:35:ac:7b:58 REACHABLE

    Use `ip neigh show` instead when both IPv4 ARP and IPv6 neighbor entries should appear in the same listing.

  2. Limit the ARP view to one interface when only one path is being investigated.
    $ ip -4 neigh show dev eth0
    172.17.0.1 lladdr 4a:0d:35:ac:7b:58 REACHABLE

    When a specific device is selected, the output may omit the `dev` field because the interface is already fixed by the filter.

  3. Query one peer directly when only one next hop or host is relevant.
    $ ip neigh show to 172.17.0.1 dev eth0
    172.17.0.1 lladdr 4a:0d:35:ac:7b:58 REACHABLE

    The `to` filter also accepts a prefix, which is useful when checking a narrow subnet instead of the entire cache.

  4. Filter the table by neighbor state when troubleshooting resolution problems.
    $ ip neigh show nud reachable
    172.17.0.1 dev eth0 lladdr 4a:0d:35:ac:7b:58 REACHABLE

    Without `nud`, `ip neigh show` lists all entries except `none` and `noarp`, so state filters are the fastest way to separate active mappings from stale or failed ones.

  5. Read the state before deleting or replacing any entry.

    REACHABLE means the mapping was confirmed recently, STALE means the cached mapping is still usable but due for revalidation, and FAILED means the kernel could not resolve the peer.