Watch Linux Network Changes with ip monitor

You will use ip monitor to watch live network state changes, narrow the stream to a device or object type, and record events for later inspection. The examples use iproute2 6.1.0, installed as part of the iproute2 package on this machine. Allow about 15 minutes for a first investigation. You need a shell and a network change to observe; recording events may require elevated privileges on your host.

1. Confirm the installed command

Start by checking which binary is being used and which syntax it advertises. This is an ordinary, read-only command:

$ command -v ip
/usr/sbin/ip
$ ip -V
ip utility, iproute2-6.1.0, libbpf 1.3.0
$ ip monitor help
Usage: ip monitor [ all | OBJECTS ] [ FILE ] [ label ] [ all-nsid ]
                  [ dev DEVICE ]
OBJECTS :=  address | link | mroute | neigh | netconf |
            nexthop | nsid | prefix | route | rule | stats
FILE := file FILENAME

The version is relevant when you are comparing output from another host. The command does not take an initial snapshot in live mode. It waits for netlink messages, so an apparently blank terminal is normally a running monitor, not a failed command.

2. Watch only the events you need

Choose an object type after monitor. For a broad view of interface changes, run this as an ordinary user:

$ ip monitor link

It remains attached until you stop it with Ctrl-C. To avoid waiting indefinitely while checking the syntax, use a timeout:

$ timeout 10s ip monitor link

Useful object names include link for interfaces, address for addresses, route for routes, neigh for neighbour state, rule for policy rules, and netconf for network configuration. The manual also lists multicast routes, prefixes, statistics, namespace identifiers and nexthops. Use all when you genuinely need every supported object type, because a busy host can make that stream difficult to read.

Limit a live stream to one device with dev:

$ ip monitor address route dev eth0

Replace eth0 with the actual interface name. This command does not change the interface. If you are unsure of the name, inspect it separately with ip link show.

3. Add timestamps and labels before investigating

Timing often matters more than the event text. The long options are -timestamp and -tshort, with short forms -t and -ts. The short timestamp is compact and stays on the event line:

$ timeout 10s ip -ts monitor address route dev eth0

The output begins with a value similar to [2026-09-24T14:45:12.345]. Exact events and times depend on the host. The longer form places a human-readable timestamp on a separate line:

$ timeout 10s ip -t monitor link

Use label when several object families share one stream. The monitor then adds a prefix such as [LINK] or [NEIGH] to each message:

$ ip -ts monitor all label

Option placement can be confusing. The timestamp switches belong to ip, before monitor. The object filters and monitor options follow it. Keep the command in this shape when adapting it:

$ ip -ts monitor OBJECTS label dev DEVICE

4. Produce a harmless event and verify the stream

A monitor is easiest to validate when you know what event should appear. On a test machine, toggling an interface administratively changes live state, but it can interrupt traffic. Do not do that on a production, remote or shared interface. If you have console access and an interface that may safely be interrupted, the following requires elevated privileges:

# ip link set dev TEST_DEVICE down
# ip link set dev TEST_DEVICE up

Replace TEST_DEVICE with a deliberately chosen test interface. The monitor should show link messages, although the exact flags and state depend on the driver. Restore the interface with the second command if the first command was the only change you made. If the interface carries a route to your current shell, do not use this test remotely.

A safer first check is simply to observe a change that your normal network manager is already making. Start the monitor, reconnect a test network, or wait for a DHCP renewal if that is part of your environment. Do not manufacture a route or address just to create output; those changes can affect connectivity and policy.

5. Record binary netlink history with rtmon

Live monitoring only sees messages after the listener starts. The companion rtmon command records RTNETLINK messages in a binary file that ip monitor can read later. Start it before a maintenance action when you need a record of the sequence:

# rtmon file /var/log/rtmon.log

This process stays attached until you stop it with Ctrl-C. Choose a path that the process can write. Writing under /var/log normally requires root, and the recorded file can reveal interface, address and routing details, so protect its permissions. A safer non-persistent test path is:

$ rtmon file /tmp/rtmon-test.log

On a system that denies netlink monitoring to ordinary users, the command reports an error such as Cannot bind netlink socket: Operation not permitted. That is a permission boundary, not a reason to loosen network security policy. Run the recorder with the minimum required privilege, and only in a controlled maintenance window.

Stop the recorder, then replay the binary log:

$ ip monitor file /tmp/rtmon-test.log

In file mode, ip reads the supplied file instead of opening RTNETLINK. The file must contain binary RTNETLINK messages, not a text capture made by redirecting the output of a live monitor. There is no need to pass all when replaying a file.

6. Include network namespaces when the host uses them

all-nsid asks the monitor to listen for namespaces that have an assigned namespace identifier in the namespace where the monitor runs:

$ ip -ts monitor all-nsid label

Events are prefixed with the originating namespace, for example [nsid 0]. An empty or incomplete view can be correct if a namespace has no assigned identifier. This option does not discover every namespace by itself, and it does not move the monitor into another namespace. Investigate namespace setup separately before treating missing events as a routing failure.

7. Keep captures readable and safe

Redirect text output only when you want a human-readable transcript:

$ timeout 60s ip -ts monitor address route label > /tmp/ip-monitor.txt
$ less /tmp/ip-monitor.txt

The redirection file is created or truncated by the shell before ip starts. Use a new filename when the old capture matters. Do not confuse this text file with an rtmon binary log. For sensitive investigations, set an appropriate restrictive umask before creating the capture and remove it through your normal retention process after you have completed the investigation.

If no output appears, check the object filter, device name, namespace, permissions and whether a real event occurred after the monitor started. If output is too busy, remove all, select one object family, and add dev DEVICE. If a replay fails, confirm that the file came from rtmon and was not replaced by a text redirect.