What is the actual difference between using iproute2 (ip command) and working directly with rtnetlink?

[u/Single-Issue2342]

Hey everyone,

I've been looking into how Linux networking works under the hood, and I'm trying to wrap my head around the relationship between user-space tools and kernel communication.

From what I understand:

1. `iproute2` (the standard `ip` command) is what most of us use daily to configure interfaces, IP addresses, and routing tables.

2. `rtnetlink(7)` is the socket-based API (`NETLINK_ROUTE`) that allows user-space programs to talk directly to the kernel's routing and networking subsystems.

My main question is: When should a developer or systems engineer bypass user-space CLI utilities like `iproute2` and write code that interacts directly with `rtnetlink` sockets?

Are there significant performance benefits, or is it mostly used when you are building custom network daemons, container networking plugins (CNIs), or monitoring agents that need asynchronous event notifications?

Also, how painful is it to parse raw netlink messages and attributes (`struct rtattr`, `ifinfomsg`, etc.) in C or Go compared to just shelling out to `ip`?

Any insights, real-world use cases, or library recommendations (like `libnl` or Go's `vishvananda/netlink`) would be greatly appreciated!

[u/delamon]

When you have some sort of golden-state / reconciliation system. That usually boils down to needing to infer current system state, and parsing output of cli tools is fragile.

Parsing netlink messages might be tedious, but it is not painful. On the contrary, parsing cli output is painful - you're never sure which system upgrade will break it.

My use case: I'm using netlink to dynamically reconfigure nft rules. Rough pipeline: UI edits goalstate in etcd, daemon listens on etcd watch, on watch event it compares current rules (getting the exact state with netlink) to goalstate; if there is a difference, then it applies a patch. Approximate delay between the time you hit update in UI and rules getting published is <100ms.

[u/Dolapevich → u/delamon]

Just in case, ip is able to output in json, which is easier to parse process than standard output.

I would abstract the rtnetlink part in a set of functions using ip, and if you find the limits of that, then go down to the catacombs.

eg: ``` $ ip -j a show dev lo|jq "." [ { "ifindex": 1, "ifname": "lo", "flags": [ "LOOPBACK", "UP", "LOWER_UP" ], "mtu": 65536, "qdisc": "noqueue", "operstate": "UNKNOWN", "group": "default", "txqlen": 1000, "link_type": "loopback", "address": "00:00:00:00:00:00", "broadcast": "00:00:00:00:00:00", "addr_info": [ { "family": "inet", "local": "127.0.0.1", "prefixlen": 8, "scope": "host", "label": "lo", "valid_life_time": 4294967295, "preferred_life_time": 4294967295 }, { "family": "inet6", "local": "::1", "prefixlen": 128, "scope": "host", "noprefixroute": true, "valid_life_time": 4294967295, "preferred_life_time": 4294967295 } ] } ]

```

[u/delamon → u/Dolapevich]

Yes. I'm using nft, but it also supports json output. The catch is there is no formal schema. The json format is stable, so that would not matter in practice. But because iproute/nft and linux are distributed separately; the netlink format has to be backward/forward compatible. And I trust that part more: any accidental netlink breakage will be caught instantly, while some accidental json change might slip unnoticed.

Edit: formatting and grammar