NAME<\/a> ip-monitor, rtmon \u2212 state monitoring<\/p>\n ip monitor<\/b> [ all<\/b> | OBJECT-LIST<\/i> ] [ file<\/b> FILENAME<\/i> ] [ label<\/b> ] [ all-nsid<\/b> ] [ dev<\/b> DEVICE<\/i> ]<\/p>\n \u2212t<\/b>, \u2212timestamp<\/b><\/p>\n Prints timestamp before the event message on the separated line in format: \u2212ts<\/b>, \u2212tshort<\/b><\/p>\n Prints short timestamp before the event message on the same line in format: The ip<\/b> utility can monitor the state of devices, addresses and routes continuously. This option has a slightly different format. Namely, the monitor<\/b> command is the first in the command line and then the object list follows:<\/p>\n ip monitor<\/b> [ all<\/b> | OBJECT-LIST<\/i> ] [ file<\/b> FILENAME<\/i> ] [ label<\/b> ] [ all-nsid<\/b> ] [ dev<\/b> DEVICE<\/i> ]<\/p>\n OBJECT-LIST<\/i> is the list of object types that we want to monitor. It may contain link<\/b>, address<\/b>, route<\/b>, mroute<\/b>, prefix<\/b>, neigh<\/b>, netconf<\/b>, rule<\/b>, nsid<\/b> and nexthop<\/b>. If no file<\/b> argument is given, ip<\/b> opens RTNETLINK, listens on it and dumps state changes in the format described in previous sections.<\/p>\n If the label<\/b> option is set, a prefix is displayed before each message to show the family of the message. For example:<\/p>\n [NEIGH]10.16.0.112 dev eth0 lladdr 00:04:23:df:2f:d0 REACHABLE [LINK]3: eth1: If the all-nsid<\/b> option is set, the program listens to all network namespaces that have a nsid assigned into the network namespace were the program is running. A prefix is displayed to show the network namespace where the message originates. Example:<\/p>\n [nsid 0]10.16.0.112 dev eth0 lladdr 00:04:23:df:2f:d0 REACHABLE<\/p>\n If the file<\/b> option is given, the program does not listen on RTNETLINK, but opens the given file, and dumps its contents. The file should contain RTNETLINK messages saved in binary format. Such a file can be generated with the rtmon<\/b> utility. This utility has a command line syntax similar to ip monitor<\/b>. Ideally, rtmon<\/b> should be started before the first network configuration command is issued. F.e. if you insert:<\/p>\n rtmon file \/var\/log\/rtmon.log<\/p>\n in a startup script, you will be able to view the full history later.<\/p>\n Nevertheless, it is possible to start rtmon<\/b> at any time. It prepends the history with the state snapshot dumped at the moment of starting.<\/p>\n If the dev<\/b> option is given, the program prints only events related to this device.<\/p>\n
SYNOPSIS<\/a>
OPTIONS<\/a>
DESCRIPTION<\/a>
SEE ALSO<\/a>
AUTHOR<\/a> <\/p>\n
\nNAME <\/a> <\/h2>\n
SYNOPSIS <\/a> <\/h2>\n
OPTIONS <\/a> <\/h2>\n
Timestamp:
[DESCRIPTION <\/a> <\/h2>\n
link\/ether 52:54:00:12:34:57 brd ff:ff:ff:ff:ff:ff<\/p>\nSEE ALSO <\/a> <\/h2>\n