Monitoring network changes with ip monitor is useful when a link flaps, a route appears or disappears, or a neighbor entry changes too quickly to catch with repeated ip link, ip route, or ip neigh commands. A successful monitor session stays open and prints each matching kernel event as it happens so the change can be correlated with the test, reboot, failover, or cabling action that triggered it.
The ip monitor command can watch multiple object types at once, and the current ip-monitor(8) syntax also supports `label`, `dev DEVICE`, and timestamp options such as `-ts` for easier reading during troubleshooting. In practice, labeled and timestamped output is the quickest way to distinguish whether the change was a link transition, a route update, or a neighbor-cache event.
A quiet monitor window does not automatically mean the command failed. It usually means the kernel has not emitted a matching link, route, or neigh event for the interface or object list being watched while the problem is reproduced.
$ ip -ts monitor link route neigh label
[2026-03-25T01:35:29.478057] [LINK]13: lab0@peer1: <BROADCAST,MULTICAST> mtu 1500 qdisc noqueue state DOWN group default
link/ether 56:b4:75:16:33:86 brd ff:ff:ff:ff:ff:ff
$ ip -ts monitor link route neigh label dev eth0
The `dev` filter is useful on multi-homed hosts where unrelated routing or neighbor chatter would otherwise hide the event you care about.
Do not restart the monitor between tests; leave it attached so the event order stays visible.
[2026-03-25T01:35:31.488547] [ROUTE]198.51.100.0/24 dev lab0 scope link [2026-03-25T01:35:35.560540] [NEIGH]192.0.2.20 dev lab0 FAILED
`[LINK]` points to interface state changes, `[ROUTE]` shows routing-table updates, and `[NEIGH]` shows ARP or IPv6 neighbor-cache changes.
If the terminal stays quiet during the test, widen the object list or remove the `dev` filter before assuming the network problem is elsewhere.