Inspect and Tune Linux Neighbour Tables with ip ntable

You will finish with a repeatable way to inspect the kernel's ARP and IPv6 neighbour-table settings, narrow the output to one interface, and change a queue length with a recorded rollback. The examples use iproute2 6.1.0, from package version 6.1.0-1ubuntu6.4 on the system used for this guide.

Allow about fifteen minutes. You need a shell, the ip command from iproute2, and an interface whose neighbour behaviour you understand. Reading tables is normally unprivileged. Changing a table parameter needs elevated privilege and can affect address resolution, so test during a maintenance window and keep the old value before changing anything.

1. Confirm the installed command

Check which executable and package version will interpret the command. This is read-only:

$ command -v ip
/usr/sbin/ip
$ ip -V
ip utility, iproute2-6.1.0, libbpf 1.3.0
$ dpkg-query -W -f='${Package} ${Version}\n' iproute2
iproute2 6.1.0-1ubuntu6.4

Checkpoint: if ip -V reports a different release, read its local help before copying option details. The command described here is ip ntable, not ip neigh. The former controls table parameters; the latter inspects individual neighbour entries.

2. Take a read-only baseline

List all tables and their current statistics:

$ ip ntable show
inet arp_cache
    thresh1 128 thresh2 512 thresh3 1024 gc_int 30000
    refcnt 1 reachable 35166 base_reachable 30000 retrans 1000
    gc_stale 60000 delay_probe 5000 queue 101
    app_probes 0 ucast_probes 3 mcast_probes 3
    anycast_delay 1000 proxy_delay 800 proxy_queue 64 locktime 1000
inet6 ndisc_cache
    ...

Your output will contain one or more entries for each protocol and interface, and the numbers will change. The local example shows the built-in arp_cache for IPv4 and ndisc_cache for IPv6. A line without dev is the table-wide entry; a line with dev is attached to that device. A dev * entry is a wildcard attachment, not a device literally named with an asterisk.

Most timer values are printed in milliseconds. queue, proxy_queue and the probe fields are counts. reachable is the current reachable value displayed by the kernel, while base_reachable is the configured base value accepted by change. Do not treat every printed field as a setting that can be copied back unchanged.

3. Focus on one interface or table

Large hosts can have hundreds of container interfaces. Filter by a real interface name:

$ ip ntable show dev enp0s31f6
inet arp_cache
    dev enp0s31f6
    refcnt 2 reachable 32949 base_reachable 30000 retrans 1000
    gc_stale 60000 delay_probe 5000 queue 101
    app_probes 0 ucast_probes 3 mcast_probes 3
    anycast_delay 1000 proxy_delay 800 proxy_queue 64 locktime 1000
inet6 ndisc_cache
    dev enp0s31f6
    ...

Use name when you want every attachment of one table:

$ ip ntable show name arp_cache

The filters can be combined. If a filter returns nothing, check the spelling with ip -br link; do not assume that a table is missing merely because the chosen interface has no entry. Save the relevant baseline before changing it:

$ ip ntable show dev enp0s31f6 name arp_cache | tee /tmp/arp-cache-before.txt

Checkpoint: the saved output should identify the protocol, table name, device and old value of the field you intend to change.

4. Choose a narrow change

The manpage's example changes the number of packets queued while an address is being resolved. For one device, the command shape is:

$ sudo ip ntable change name arp_cache dev enp0s31f6 queue 8

This is the first state-changing command in the guide. queue 8 is a deliberately explicit example, not a recommendation for your network. A queue that is too small can drop packets during resolution; a larger queue consumes more memory and does not fix a broken neighbour or routing configuration. Do not apply it to a production interface until you have established why the existing value is unsuitable.

The command order is flexible within the syntax, but keeping name, dev and the parameter together makes reviews easier. Other parameters include base_reachable, retrans, gc_stale, delay_probe, the probe counts, proxy settings and locktime. Use the units shown by the help text: timer parameters are in milliseconds, while queue and probe parameters are counts.

5. Verify the new value

Re-read exactly the table you changed:

$ ip ntable show dev enp0s31f6 name arp_cache
inet arp_cache
    dev enp0s31f6
    ... queue 8

Do not use a changing reachable number as proof that the queue change worked. Check the named field and confirm the command's exit status:

$ printf 'ip ntable status: %s\n' "$?"
ip ntable status: 0

If the output still shows the old value, check that you changed the same protocol, table name and device that you recorded. If the command reports insufficient permission, retry with sudo; do not respond to an unrelated syntax error by changing kernel or network settings.

6. Restore the previous value

There is no general reset command in ip ntable. Restore the exact old value from your baseline, using the same table and device:

$ sudo ip ntable change name arp_cache dev enp0s31f6 queue OLD_QUEUE
$ ip ntable show dev enp0s31f6 name arp_cache

Replace OLD_QUEUE with the number from /tmp/arp-cache-before.txt, not with a guessed default. If you changed a timer or probe count instead, restore that parameter by name. The setting is kernel state, so do not assume it will survive a reboot; persistence belongs in the network configuration system used by your distribution and should be managed separately.

Common traps

• Confusing tables with entries: ip ntable describes neighbour-table policy and statistics. It does not add or delete a particular ARP or NDP neighbour.
• Copying host-specific output: interface names, reference counts and timer readings differ between hosts. Copy the command structure, not the observed values.
• Changing every attachment: omitting dev can target the table-wide setting rather than one interface. State the device explicitly when the change is meant to be local.
• Expecting persistence: a successful change alters the running kernel. It is not, by itself, a configuration file edit or a permanent network policy.