In part 1 of this series, I demonstrated the use of unshare() and setns() to create new network namespaces and enter existing ones. I didn’t call attention to it in that post, but you may have noticed that the new network namespace only has a down loopback device, which makes it quite uninteresting without further configuration. Now I could start executing some iproute2 commands, but I’m also using Zig to tinker with the Netlink protocol (see Using Comptime for Netlink).

Go read part 1 for an introduction to network namespaces and the unshare() and setns() syscalls. I ended that post with a complaint about using the unshare and nsenter programs - they are great programs, just not tailored to my preferred workflow. The problem is persistence. I don’t want to worry about tracking the PID of the shell that executes unshare -Urn or having to keep that one shell running so the PID of the namespace is consistent (the namespace continues to exist as long as any process is attached to it).

Linux’s network namespaces are the coolest thing since Windows Vista. Ok that’s hardly a fair comparison, but I am talking about a feature that was introduced to Linux 2.6.24 which shipped in January of 2008, roughly one year after Vista was released. One of these things is still very relevant today. The kernel has a man page1 with a concise description of the feature. I like this sentence from man ip-netns2:

As I continue to get my feet wet with Zig, I find myself greatly admiring the paradigm of no hidden allocations1. Any function that needs to allocate heap memory must receive a mem.Allocator2. This is more explicit than the ability to call malloc() at any depth of the call stack in C and lets (and forces) the calling code decide what allocator to use. So on the other hand, the programmer generally knows that any function without an Allocator argument only uses stack memory, though of course nothing stops a Zig function from initializing a new Allocator.

I’m sure you can find dozens of other blog posts explaining how to use comptime in Zig1. This one won’t be any more useful; it’s just mine. Protocol The Netlink2 protocol is a control plane for Linux networking. If you haven’t used it directly, know that tools like systemd and iproute2 use Netlink to create network devices, assign IP addresses to them, and define routes in the routing table. The basic structure of a Netlink message is