iproute2 is the standard Linux userspace suite for inspecting and configuring the kernel networking stack. The suite covers links, addresses, routes, neighbours, tunnels, traffic control, sockets, hardware offload, and several specialized networking subsystems. Most commands exchange Netlink messages with the kernel; they do not implement the data plane that forwards packets.
The project publishes one release for each Linux kernel release. Matching versions expose the same generation of kernel interfaces, although a newer iproute2 can operate against an older kernel when it does not request unsupported features.
A History of Linux Userspace Network Management #
Linux network management developed in layers. Low-level utilities modify live kernel state, while configuration frameworks and daemons decide what state should persist and when to apply it.
| Period | Software | Role and Historical Significance |
|---|---|---|
| Early 1990s | BSD-derived commands and net-tools | Separate commands such as ifconfig, route, arp, and netstat became the conventional Linux interface for links, IPv4 addresses, routes, neighbour entries, and statistics. Their interfaces depend heavily on networking ioctls and /proc, so they cannot represent many later kernel features. |
| 1990s onward | Distribution network scripts and ifupdown | Files such as Debian’s /etc/network/interfaces and distribution-specific network scripts added persistent configuration around low-level commands. ifup and ifdown describe interface lifecycle, but they are orchestration tools rather than kernel APIs. |
| Late 1990s onward | iproute2 | Alexey Kuznetsov created iproute2 alongside the kernel’s advanced routing, traffic-control, and RTnetlink work. ip consolidated the object model exposed by ifconfig, route, arp, and iptunnel; ss and tc covered socket inspection and traffic control. Netlink’s extensible, message-based interface allowed the suite to track new kernel capabilities. |
| 2004 onward | NetworkManager | NetworkManager introduced a long-running connection manager for dynamic wired, Wi-Fi, mobile, and VPN connections. Connection profiles express desired state, while nmcli, nmtui, and graphical clients control the daemon. |
| 2014 onward | systemd-networkd | systemd 210 added a declarative network manager oriented toward boot-time and continuously managed links. .link, .netdev, and .network files define naming, virtual devices, addresses, routes, and related policy; networkctl provides runtime inspection and control. |
| 2016 onward | Netplan and other configuration front ends | Netplan added a YAML configuration layer that renders configuration for NetworkManager or systemd-networkd. Front ends of this class standardize policy without replacing the selected network-management daemon or the kernel interfaces beneath it. |
The generations overlap because they solve different problems. ip addr add
changes the running kernel immediately, whereas NetworkManager,
systemd-networkd, or ifupdown owns persistent policy and may later replace
that change. Administrators should avoid modifying a daemon-managed interface
with ad hoc ip commands except for diagnosis or deliberate temporary state.
Packet filtering also follows a separate lineage: iptables and nft configure
Netfilter rather than the routing and link objects managed by iproute2.
The ip Object Model
#
ip uses the form ip [options] object command. The principal objects map to
kernel networking concepts:
| Object | Purpose |
|---|---|
link | inspect or configure network devices and link-layer properties |
address | manage IPv4 and IPv6 addresses |
route | manage unicast, multicast, and special routes |
rule | manage routing-policy database rules |
neighbour | manage ARP and IPv6 neighbour-discovery entries |
netns | create and operate in named network namespaces |
tunnel, l2tp, macsec | configure tunnel and secure-link types |
xfrm | manage IPsec state and policies |
nexthop | manage reusable next-hop objects and groups |
mptcp | manage Multipath TCP endpoints and limits |
monitor | stream RTnetlink state changes |
The object list continues to grow because ip acts as a collection of
front ends behind one executable. ip help lists top-level objects, and
ip object help describes the commands supported by an installed release.
Executables Installed by iproute2 7.1.0 #
The upstream release archive contains source code, not prebuilt binaries. The
table lists every command name installed by the upstream make install rules in
iproute2 7.1.0,
the current release at the time of writing. Distribution packages may split,
omit, relocate, or patch the commands.
| Command | Purpose | Build or Installation Note |
|---|---|---|
ip | inspect and configure links, addresses, neighbours, routes, rules, namespaces, tunnels, and related network objects | Core command |
rtmon | record RTnetlink link, address, route, and neighbour events for later inspection | Core command; ip monitor provides overlapping interactive functionality |
routel | print the routing table in a column-oriented format | Installed Python script |
tc | configure traffic-control queueing disciplines, classes, filters, and actions | Core command |
bridge | manage bridge links, forwarding databases, VLANs, multicast databases, and bridge port state | Core command |
ss | inspect sockets, protocol state, ownership, queues, memory, and diagnostic data | Successor to the socket-reporting functions of netstat |
nstat | report kernel SNMP and protocol counters, including changes since the preceding invocation | Core statistics command |
ifstat | report per-interface packet and byte counters | Core statistics command |
rtacct | report traffic counters grouped by routing realms from the kernel’s route-accounting data | Core statistics command |
lnstat | periodically report selected counters exported through /proc/net/stat | General statistics command |
rtstat | report routing-cache statistics through lnstat’s compatibility mode | Symbolic link to lnstat |
ctstat | report connection-tracking statistics through lnstat’s compatibility mode | Symbolic link to lnstat |
arpd | maintain a userspace ARP cache and answer kernel neighbour requests from a persistent database | Built only when Berkeley DB compatibility headers and libraries are available |
genl | query and invoke Generic Netlink families | Core command; primarily useful for protocol development and diagnostics |
tipc | configure and inspect Transparent Inter-Process Communication bearers, links, nodes, sockets, and namespaces | Built when libmnl is available |
devlink | configure and diagnose device-level networking resources, ports, firmware parameters, health reporters, traps, and hardware rates | Built when libmnl is available |
rdma | inspect and configure RDMA devices, links, resources, system settings, and statistics | Built when libmnl is available |
dcb | inspect and configure Data Center Bridging buffers, priorities, Priority Flow Control, ETS, and application mappings | Built when libmnl is available |
vdpa | manage vDPA management devices and virtual data-path accelerator devices | Built when libmnl is available |
netshaper | inspect and configure hardware transmit-shaping objects exposed through Netlink | Built when libmnl is available |
dpll | inspect, configure, and monitor Digital Phase-Locked Loop devices and pins used for network clock synchronization | Built when libmnl is available |
Programs named maketable, normal, pareto, and paretonormal also appear
in the source tree, but the build uses them only to generate tc distribution
tables. The install target copies their generated data rather than those host
tools, so they are not release commands.
Choosing the Correct Layer #
- Use iproute2 for immediate inspection, diagnostics, experiments, and low-level configuration that a higher-level manager does not expose.
- Use NetworkManager,
systemd-networkd,ifupdown, or a distribution configuration layer when state must survive reboot and react consistently to device lifecycle events. - Use
nftfor packet filtering and network address translation because those operations belong to Netfilter. - Match iproute2 documentation to the installed version because userspace can only encode features known at build time, and the running kernel can only accept features that it implements.
Comments
Read or comment on GitHub (sign-in required to comment)