iproute2 is the toolset behind ip, tc and bridge, released with the kernel

This is a mirror, and patches go somewhere else

The repository description says it plainly: this is a publish only mirror, and any changes should follow the procedure described in README.devel. The real source lives on kernel.org, where the documentation points at a stable repository and a separate development repository, iproute2-next, which is where work in progress happens before it is folded into a release. That arrangement is worth understanding before you clone anything, because a fork of this GitHub repository is a fork of a mirror, and pull requests opened here are not where the maintainers read them. The two people named at the end of the README, Stephen Hemminger and David Ahern, are the ones the project points you to. The tree itself is the standard Linux layout with a `MAINTAINERS` file, a `CREDITS` file, a `SECURITY.md` and a `COPYING` file carrying the GPL-2.0 terms, plus a `.mailmap` file and a `.clang-format` file, which are the small touches a project accumulates when it has a large group of contributors.

The compatibility rule between tools and kernels is two sided

A new release of iproute2 is done with each kernel version, and the documentation explains that the range of compatibility is wide but not absolute. Newer versions of iproute2 still work with older kernels, with some limitations, and the failure mode is worth remembering because it is quiet. If you use an iproute2 command with a feature that the running kernel does not have, the kernel may report an error, or it may silently ignore the new attribute. The other direction is stricter: an older iproute2 running on a newer kernel simply cannot use or see the new features. The range extends back as far as the oldest supported long term support kernel version, which is the practical lower bound for a distribution. The consequence for an operator is that a container or a minimal image with an old iproute2 and a new kernel will not tell you that the tool is out of date, it will just not offer the feature, which is why pinning the toolset version in an image build is worth the trouble.

Building needs a database library, a make and the bundled headers

The build instructions in the README are three numbered steps, and the first one is the one people miss. arpd needs the Berkeley DB development libraries, and on Debian the package has a name like libdbX.X-dev, with the DBM_INCLUDE variable pointing at the directory that holds db_185.h, the include file arpd uses to reach the old format Berkeley database routines. That header is often in the db-devel package, so the dependency is not always the same package name. The second step is simply:

make

The makefile creates a config.mk file for you, which is the point of step two, since that file holds the definitions of libraries that may or may not be available on the system. The third step concerns headers: the package ships matching sanitized kernel headers under include/uapi, because the build environment may not have up to date versions of them, and the Makefile is where you point it at different kernel include files if you have specific requirements. So the build is not the hard part of iproute2, the optional dependencies and the header situation are.

The subdirectory list is the feature list, and MNL gates half of it

The Makefile names the directories that are built, and that list is the quickest way to see what the toolset contains. The base set is `lib ip tc bridge misc netem genl man`, so the IP address tools, the traffic control tools, the bridge tools, the miscellaneous commands, the network emulator, the generic netlink utilities and the manual pages. Then there is a conditional block: when the build has MNL, the list extends to tipc, devlink, rdma, dcb, vdpa, netshaper and dpll. Those are the specialised subsystems, the device link layer, the remote direct memory access stack, data centre bridging, the vDPA framework, a traffic shaper and a timing protocol. MNL is a netlink library that these tools need, and whether your build gets them depends on whether the library was found on the system, which the generated config file decides. If you are packaging iproute2 and those commands are missing from your package, the reason is a missing MNL rather than a build flag you missed.

config.mk is generated, so the build detects rather than configures

The generated configuration file is what makes a plain `make` work on most systems. It holds the definitions of the libraries that may or may not be present, and the README names four of them, ATM, ELF, MNL and SELINUX, which is a good sample of what the toolset can use when the system offers it. The Makefile also fixes the behaviour through preprocessor definitions. One of them, RESOLVE_HOSTNAMES, is enabled by default, so the tools can take host names where an address is expected, and the library directory is compiled in as LIBDIR, with the shared library support switchable through NO_SHARED_LIBS. The compiler itself is gcc by default, with HOSTCC overridable for cross builds, the C code is compiled with _GNU_SOURCE defined and large file support enabled, and the warning set is strict, with -Wall, -Wstrict-prototypes, -Wmissing-prototypes, -Wmissing-declarations, -Wold-style-definition and -Wformat=2. The verbosity of the build can be turned up with a V variable on the command line.

The install layout is spelled out to the man page directory

Every path the package installs into is a variable at the top of the Makefile, which is what makes the toolset repackagable. PREFIX defaults to /usr and SBINDIR to /sbin, so the administrative commands land in the sbin directory while the rest go under the prefix. There is a directory for network namespaces, /var/run/netns for the running instances and /etc/netns for the configuration that applies to them, which is the pair the namespace tooling works with. There is a separate configuration directory, /etc/iproute2, and a user configuration directory under the data directory, and the documentation directories, with a separate directory for the manual pages and another for the general documentation. The kernel headers are installed under include/iproute2, the bash completion files land in the shell completion directory under the data directory, and arpd has its own state directory, /var/lib/arpd, which is the one you need to create if you run the address resolution daemon.

Tests, schemas and examples sit next to the tools

The top level of the tree contains directories that are not commands, and they explain how the project is tested and specified. The `testsuite/` directory holds the test suite, the `schema/` directory holds the netlink schema definitions that the generic netlink tooling in `genl/` works from, and `examples/` holds example material, including a directory for BPF examples. The `include/` directory carries the public headers, `lib/` holds the shared code with the static libraries the Makefile links, including the netlink utility library, and `man/` holds the manual pages that the `man` subdirectory installs. The `scripts/` and `bash-completion/` directories hold the helper scripts and the shell completion definitions, and there is a `configure` file in the tree alongside the generated configuration path. The GPL-2.0 licence and the last push to the mirror on 2026-10-02 complete the picture of a project whose releases track kernel releases rather than a schedule of its own.

Editorial conclusion

iproute2 suits distribution maintainers who need to build the toolset against a specific kernel, since the compatibility rules and the optional library detection are documented rather than guessed, and it suits anyone who wants to read the reference implementation of netlink usage before writing their own network tooling. It is a poor fit as a place to send a patch, because the repository is a mirror and changes are made through the process described in README.devel, and it is a poor fit if you need the newest features, because those land in the separate iproute2-next development repository. Before you build it, check three things: whether the Berkeley DB development headers are present, since arpd will not build without them, which optional subsystems your build will get, since the tipc, devlink, rdma, dcb, vdpa, netshaper and dpll tools are only compiled when MNL is available, and the kernel version you target, with the last push to the mirror on 2026-10-02 and the project under GPL-2.0.

Frequently asked questions

Official sources

1. iproute2/iproute2 on GitHub
2. Issues
3. License: GPL-2.0
4. Project website
5. README