The Joy of Network Namespaces

Writing a routing daemon can be an interesting affair, especially when debugging it. Any bug can leave behind nastiness in your routes and routing rules, making it really hard to clean up. One technique to avoid such mess is to use an external server, but local debugging is too tempting. If you have 300 integration tests (i.e., things you put into routing tables of Linux), using an external server to run tests can take a few minutes, at least. On my machine it takes less than 6 seconds. So, local development is essential for the quality of work and life.

While local debugging is essential, it can also be frustrating to clean up routing table messes due to transient bugs or typos. But here’s where network namespaces come to the rescue.

My routing daemon uses network namespaces, so I initially thought that I couldn’t use network namespaces to debug it. But it turns out, I can! I just need to save the root namespace in a variable in the setup_module, create a new namespace, and switch into it. From there, I can create more namespaces, no problem, and link devices between “my current namespace” (which is no longer the root namespace) and other namespaces, imitating whatever network configuration I’m procuring for my unholy hacks.

The real bliss of network namespaces is the ease of cleanup. I’ve got 6 ancillary namespaces, 8 bridges with 20 cross-namespace veths, five dummies, 300+ routes, 200+ rules, and crazy routing options, and now I need to clean up this mess? No problem! All I have to do is switch to the original namespace, remove those 7 namespaces, and the system is as new.

The moment I realized that I could get into a namespace and continue to configure namespaces was a moment of pure delight. I am so happy that I can use network namespaces for debugging my routing daemon, and I can’t wait to see what other wonders network namespaces have in store for me.