The essentials
Quick reference
One focused task per row. Jump to the related section for complete, working examples.
| Use | Syntax | Examples |
|---|---|---|
| Show concise addresses | ip -brief address show | View examples |
| Export routes as JSON | ip -json route show table all | View examples |
| Resolve an IPv4 path | ip route get 203.0.113.10 from 192.0.2.20 | View examples |
| Resolve an IPv6 path | ip -6 route get 2001:db8:2::10 from 2001:db8:1::20 | View examples |
| Show the main table | ip route show table main | View examples |
| Replace a route idempotently | sudo ip route replace 198.51.100.0/24 via 192.0.2.1 dev \
eth0 metric 100 | View examples |
| Delete an exact route | sudo ip route del 198.51.100.0/24 via 192.0.2.1 dev eth0 \
metric 100 | View examples |
| Show policy rules | ip -details rule show | View examples |
| Add a source policy | sudo ip rule add priority 1000 from 192.0.2.0/24 table \
100 | View examples |
| Add a policy-table default | sudo ip route replace default via 192.0.2.1 dev eth0 \
table 100 | View examples |
| Monitor network changes | ip monitor link address route rule | View examples |
| Show neighbor state | ip -details neighbor show dev eth0 | View examples |
| Flush failed neighbors | sudo ip neighbor flush dev eth0 nud failed | View examples |
| Show queue disciplines | tc -s qdisc show dev eth0 | View examples |
| Install fq_codel root qdisc | sudo tc qdisc replace dev eth0 root fq_codel | View examples |
| Add lab delay and loss | sudo tc qdisc replace dev veth-test root netem delay \
50ms loss 0.1% | View examples |
| Remove a root qdisc | sudo tc qdisc del dev veth-test root | View examples |
| Show iproute2 version | ip -Version | View examples |
Use iproute2 to inspect the kernel's live networking state and to test deliberate changes. Route, rule, link, and qdisc modifications take effect immediately, can terminate the very SSH session used to make them, and usually disappear at reboot unless expressed through the distribution's network manager. Capture current state, arrange console or out-of-band access, stage an automatic rollback, and confirm both forward and return paths before a production change.
Step by step
Detailed examples
Capture machine-readable state before changing the network
Record links, addresses, routes in every table, policy rules, neighbors, and qdiscs. JSON output is safer for automation than parsing aligned text, but fields vary with iproute2 and kernel versions. Include the distribution network manager's configuration because ip only shows live kernel state. Redact public topology or tunnel metadata before sharing evidence.
ip -json link show
ip -json address show
ip -json route show table all
ip -json rule show
ip -json neighbor show
tc -json -s qdisc show Ask the kernel which path a flow would use
ip route get performs a lookup rather than listing routes or sending traffic. Supply source, mark, input interface, protocol, or ports when policy depends on them. The result is local to the current network namespace and reflects rules plus routing tables. It does not prove the gateway, return route, firewall, NAT, DNS, or remote service is working.
ip route get 203.0.113.10
ip route get 203.0.113.10 from 192.0.2.20
ip route get 203.0.113.10 from 192.0.2.20 mark 0x1
ip -6 route get 2001:db8:2::10 from 2001:db8:1::20 Prefer exact, reversible route changes
replace is useful for converging a route, but a typographical error still changes the live forwarding plane. Specify prefix, gateway, interface, metric, table, and protocol deliberately. A gateway usually must be reachable on-link unless onlink is explicitly justified. Before a remote change, schedule an automatic rollback through an independent mechanism and retain console access; cancel it only after end-to-end verification.
ip route show table main
ip route get 198.51.100.10 from 192.0.2.20
# Stage a tested out-of-band rollback before applying the next command.
sudo ip route replace 198.51.100.0/24 via 192.0.2.1 dev eth0 metric 100
ip route get 198.51.100.10 from 192.0.2.20 Use explicit rule priorities and complete routing tables
The routing policy database evaluates lower numeric priorities first. Always assign a unique explicit priority and inspect existing distribution, VPN, VRF, and container rules. A custom table normally needs routes for connected networks as well as a default; otherwise gateway resolution or return paths can fail. Test representative sources and marks, then persist both rules and routes using the active network manager.
ip -details rule show
ip route show table 100
ip route get 203.0.113.10 from 192.0.2.20
# Planned state:
# ip rule add priority 1000 from 192.0.2.0/24 table 100
# ip route replace 192.0.2.0/24 dev eth0 scope link table 100
# ip route replace default via 192.0.2.1 dev eth0 table 100 Correlate kernel events with the configuration owner
ip monitor streams changes but does not identify which process initiated them. Pair timestamps with NetworkManager, systemd-networkd, netlink-aware agents, VPN clients, container runtimes, and orchestration logs. Manual ip changes may be overwritten immediately by those managers or disappear on restart. Fix the declarative owner after proving the desired kernel state.
ip -timestamp monitor link address route rule
systemctl status NetworkManager.service systemd-networkd.service --no-pager
journalctl --since today -u NetworkManager.service -u systemd-networkd.service --no-pager Interpret neighbor states before flushing entries
Neighbor entries represent ARP or IPv6 Neighbor Discovery and transition through states such as REACHABLE, STALE, DELAY, PROBE, FAILED, and permanent. A FAILED entry is often a symptom of VLAN, switch, address, gateway, or firewall trouble. Flush only a narrow interface and state after investigation; broad flushes cause bursts of resolution traffic and can briefly disrupt many flows.
ip -statistics -details neighbor show dev eth0
ip route get 192.0.2.1
ip -statistics link show dev eth0
# If the underlying issue is fixed, remove only failed cache entries:
# sudo ip neighbor flush dev eth0 nud failed Apply qdiscs only with interface-specific capacity and rollback
Traffic control acts on egress, while ingress shaping normally needs redirection to an IFB or other design. Replacing the root qdisc can disrupt latency and throughput, remove child classes, and conflict with a network manager. Offloads can distort measurements. Use netem only in isolated labs, record the existing tree, confirm kernel modules, bound experiments, and test deletion or restoration before applying impairment.
tc -s -details qdisc show dev veth-test
ethtool -k veth-test
# Lab-only impairment plan:
# sudo tc qdisc replace dev veth-test root netem delay 50ms loss 0.1%
# sudo tc qdisc del dev veth-test root Persist through the active network manager, not ad hoc boot scripts
ip and tc modify only the current namespace's live state. Persist settings with NetworkManager, systemd-networkd, netplan, ifupdown, or distribution tooling already owning the interface; supported route-rule and qdisc features vary by version. Avoid configuring the same link in two managers. Validate a reboot or manager restart in a maintenance window with local access and an exported baseline.
ip -Version
tc -Version
networkctl status --all
nmcli -t -f DEVICE,TYPE,STATE,CONNECTION device status
systemctl is-enabled NetworkManager.service systemd-networkd.service Sources and further reading
References
Authoritative documentation used to verify and expand this cheat sheet.
- iproute2 Projectip(8) Manual Pageman7.org
- iproute2 Projectip-route(8) Manual Pageman7.org
- iproute2 Projectip-rule(8) Manual Pageman7.org
- iproute2 Projectip-neighbour(8) Manual Pageman7.org
- iproute2 Projecttc(8) Manual Pageman7.org
- iproute2 Projecttc-netem(8) Manual Pageman7.org
- Linux man-pages projectNetwork Namespace Manual Pageman7.org
Help us improve
Found a typo or missing example?
Tell us what would make this cheat sheet clearer, more complete, or more useful.



