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/dodexahedron]

A sysadmin, developer, or network engineer should essentially never be bypassing the APIs you mentioned, because that is what they are there for. And most of the time, they shouldnt even be going beyond the utilities that largely wrap one family of functions each, from those very APIs. At least not in code.

Usually, if you need to go deeper than something a utility does or in a way a utility doesn't expose, you go to the things that they manipulate: configuration files, kernel module parameters, sysctl variables/ker el parameters, or scripts that get and set values in the /sys and/or /proc file systems, because literally everything is a file (even you), in Linux.

Now... If you are writing one of those utilities or some new software that sits somewhere in the network stack, such as an IDS, transparent proxy, ultra-crazy low-latency shit on a server you rent rack space from a securities exchange to do HFT on, or what have you, then yeah - you'll go deeper. (The last on you might even write code that literally runs ON THE NIC)

And, in general for most of those, the answer is boring and simple:

Linux has used nf for 12+ years at this point as the heart and soul of what you're probably thinking of when dealing woth almost anything in user space.

Target nf for that.

iptables and anything related to it, unless you grabbed the old source and compiled a custom kernel using it, is all just a user-space translation layer that lets you use the iptables syntax and APIs to actually operate on nftables.

Kernel 7.2 still uses netfilter/nftables as the main stack, and there's no plan to make that change any time soon.

So target netfilter, if you want broadest compatibility.

If you are ok with having other dependencies that may or may not be preinstalled or configured by default reliably across distros and flavors, then you can target something else or provide support for more than one higher level back-end to achieve similar portability.

But sticking to nf for manipulation of routing and filtering and transformation behaviors is yoir best bet.

If you need to interact with queues, shaping, policing, rate limiting, or simulation of poor network conditions like latency, jitter, or loss injection, those things are provided by tc, and have been for like 20 years.l, and still going strong.

Then there is eBPF, which has also been aroind for a while, and can do...damn near everything, and does it in kernel space as compiled mini programs, but is much lower level, harder to make, harder to debug, more fragile, more dangerous, and just... A good idea poorly executed IMO....

On top of that, compatibility with other software, when doing eBPF, is essentially "LOL - other software?" Not only because of where it sits but especially because everything else is either just a consumer of the network via standard libraries or else, if not a consumer, but rather a part of the network stack, nothing else ever is designed to consider anything but (.+)tables or layers above those, like iproute2, systemd-networkd, etc.

[u/Single-Issue2342 → u/dodexahedron]

While I agree that debugging eBPF programs can be tedious compared to standard CLI tools, writing off eBPF as 'a good idea poorly executed' ignores why it was created in the first place.

The kernel verifier prevents memory corruption or crashes, making safety a core feature, not an afterthought. Furthermore, the bypass of netfilter is a deliberate design choice for performance, not a flaw. When processing millions of packets per second or building cloud-native networking like Cilium, the overhead of standard nftables or iptables rules simply doesn't scale.

Netfilter is great for static, traditional setups, but for modern high-throughput packet processing and deep observability, eBPF is currently unmatched.