I'm trying to understand the practical relationship between iproute2 and the kernel's rtnetlink API. The ip command is convenient for configuring interfaces, addresses, routes, and other networking state, while rtnetlink sockets let programs communicate with those kernel subsystems directly through NETLINK_ROUTE.
When does it make sense for a developer or systems engineer to skip invoking the ip command and use rtnetlink from C, Go, or another language? Is the main benefit performance, or is direct netlink access primarily useful for network daemons, container networking plugins, reconciliation systems, and programs that need asynchronous link or address notifications?
I'd also like to know how difficult raw netlink programming is in practice. How does dealing with messages and attributes such as ifinfomsg and rtattr compare with spawning ip and parsing its output? Are libraries such as libnl, libmnl, or Go's vishvananda/netlink a good middle ground?
4 Answers
The biggest reason is reliable state management, not raw speed. If a daemon has a desired network configuration, it needs to inspect the exact kernel state, compare it with that desired state, and apply only the necessary changes. Parsing human-oriented command output is fragile and repeatedly starting processes adds overhead. Netlink gives you structured messages and lets you keep a socket open for updates. For example, a controller can watch for interface, address, or route changes and reconcile them quickly. The ip command’s JSON output is a reasonable compromise for simple scripts, but it still isn’t as direct or comprehensive as using the API.
There usually isn’t a dramatic performance benefit for an occasional administrative command. Shelling out to ip is perfectly reasonable for setup scripts, troubleshooting, and small tools. The difference matters more for a persistent service that performs frequent operations, must react immediately to kernel events, or needs atomic-looking reconciliation without depending on command formatting. Also, choose the API family that matches the subsystem: routing and link configuration use rtnetlink, nftables uses its own netlink interface, and traffic control is handled through the tc-related netlink APIs. Netlink is not a universal replacement for every Linux networking interface.
Raw netlink is powerful but not especially pleasant at first. You have to understand message types, nested attributes, alignment, flags, byte order, and the fact that a single logical object may be represented by several attributes. Notifications can also arrive asynchronously and may not appear in the order your application expects, so code needs to handle retries, missing objects, and state changes between a dump and a notification. Libraries make a major difference: Go’s vishvananda/netlink is a practical choice for common interface, route, link, and address operations, while libmnl or libnl can reduce the C-level parsing work. For unusual features, reading iproute2’s implementation and kernel documentation may still be necessary.
A useful approach is to start with a high-level library and only drop to raw netlink for operations the library does not expose. That avoids duplicating all of the attribute parsing while still giving you access to specialized kernel features.
Direct netlink is common when you need asynchronous notifications or are building something that manages networking as part of its core job: container networking, VPN and tunnel managers, network controllers, monitoring agents, and firewall or nftables tooling. A long-running program can subscribe to link and address events instead of polling or launching ip repeatedly. It can also issue several related operations through one persistent socket and receive structured acknowledgements and errors.
That compromise is often worth trying first. JSON output is much safer than scraping the default display, and moving to netlink later is easier if the command-wrapper code is hidden behind a small interface.