Inspect Linux Networking Safely with ip

You will finish with a small, repeatable workflow for inspecting Linux interfaces, addresses and routes with ip, then checking which route the kernel would use for a destination. The examples use iproute2 6.1.0, installed here as package version 6.1.0-1ubuntu6.4.

Allow about fifteen minutes. You need a shell and the iproute2 package. The inspection commands are normally unprivileged. Changing interface state, addresses, routes or namespaces normally requires root or the relevant network administration capability, and can interrupt connectivity.

1. Confirm the installed command

Start with a read-only version check. This also prevents a copied example from silently being interpreted by a different implementation:

$ command -v ip
/usr/sbin/ip
$ ip -V
ip utility, iproute2-6.1.0, libbpf 1.3.0

Your path and library version may differ. The command's general shape is ip [ OPTIONS ] OBJECT COMMAND. Objects include link for network devices, address or addr for IP addresses, route for routing entries, neigh for the neighbour cache and monitor for live kernel notifications.

Checkpoint: ask the installed binary for the syntax of a particular object before using a less familiar operation:

$ ip link help
$ ip route help

The object names can be abbreviated, but full names are easier to read in scripts and incident notes. Some commands have defaults. For example, ip addr means ip address show, and ip route lists routes.

2. List interfaces and addresses

Use the brief form when you need a compact inventory. It is supported for ip link show and ip addr show:

$ ip -br link show
lo               UNKNOWN        00:00:00:00:00:00 <LOOPBACK,UP,LOWER_UP>
enp0s31f6         UP             90:1b:0e:da:cc:ef <BROADCAST,MULTICAST,UP,LOWER_UP>
$ ip -br addr show
lo               UNKNOWN        127.0.0.1/8 ::1/128
enp0s31f6         UP             192.0.2.10/24

Interface names and addresses are host-specific. Do not copy the sample address into a configuration. The first output describes devices and link state; the second adds protocol addresses. An interface can be administratively up while its physical carrier is unavailable, so read the flags and state together rather than treating UP as proof that traffic works.

For full detail on one device, replace IFACE with an exact name from the listing:

$ ip link show dev IFACE
$ ip addr show dev IFACE

Checkpoint: confirm the interface name, address family and prefix length before troubleshooting a route. A long list of Docker, bridge or virtual Ethernet devices is normal on a host running containers; it does not by itself identify the path to the public network.

3. Inspect routes and ask the kernel

List the routing table without changing it:

$ ip route show
default via 192.0.2.1 dev IFACE
192.0.2.0/24 dev IFACE proto kernel scope link src 192.0.2.10

Routes are selected by the destination prefix and policy, not simply by the first line displayed. To see the decision for one destination, use route get:

$ ip route get 1.1.1.1
1.1.1.1 via 192.0.2.1 dev IFACE src 192.0.2.10

The result can include a gateway, device, source address, user ID or cache details. Those fields explain what the kernel would use for that query; they do not send a packet. Try an address on a directly connected network as well as an external address, and compare the selected device with the interface inventory.

IPv6 needs an IPv6 destination and is easiest to make explicit:

$ ip -6 route show
$ ip -6 route get 2001:db8::1

An error or an unexpected device is a diagnostic result. Check addresses, policy rules and the relevant network manager before adding a route. Do not assume that adding a default route is a harmless fix.

4. Make output suitable for scripts

Human-readable output is convenient at a terminal, but its layout can change as details are enabled. JSON is a better boundary for a script that already has a JSON parser:

$ ip -j link show dev IFACE
$ ip -j addr show dev IFACE
$ ip -j route show

Add -p when inspecting JSON manually:

$ ip -j -p route show

Use -o when a record-per-line stream is more useful than nested JSON. Use -br for a human inventory, not as a stable machine interface. Avoid -r in automation unless DNS name resolution is deliberate, because names can add latency and make output dependent on resolver state.

To follow changes while another process reconfigures networking, open a second terminal and run:

$ ip monitor link address route

This waits for netlink events and continues until you stop it with Ctrl-C. It observes changes; it does not prevent them or record a permanent audit log. If you need timestamps, add -t, or use -ts for shorter timestamps.

5. Treat changes as a maintenance action

Commands such as ip link set, ip address add and ip route add change live kernel state. They can drop an SSH session, conflict with NetworkManager or systemd-networkd, and disappear on reboot unless a persistent configuration owns them. Take a read-only snapshot first:

$ ip -details link show dev IFACE
$ ip addr show dev IFACE
$ ip route show
$ ip rule show

Only after checking the owning network service and arranging a recovery path should you run a change. For example, the syntax for adding a temporary address is:

# ip address add 192.0.2.20/24 dev IFACE
# ip address show dev IFACE
# ip address del 192.0.2.20/24 dev IFACE

Replace both placeholders with values approved for that network. The final command is the undo operation for the exact address and prefix. Do not use it to remove an address you did not add. If you bring an interface down with ip link set dev IFACE down, restore it with ip link set dev IFACE up only when you recorded that it was previously up and the service expects it to be up.

Do not use ip address flush, ip route flush or ip link delete as exploratory commands. They can remove many entries or destroy a virtual device. If a change breaks access, use the console or out-of-band channel, restore the recorded state, and then reconcile the persistent network configuration so the service does not immediately undo your repair.