Network Namespaces: veth Pairs, ip netns, and What Each Namespace Owns

A network namespace is a separate copy of the kernel's networking stack. A process inside one sees its own world:

• its own interfaces. A brand-new namespace has exactly one, a loopback lo, and even that starts DOWN;
• its own addresses and routing tables;
• its own firewall: nftables and iptables rulesets are per namespace;
• its own `/proc/net` and, through ip netns exec, its own `/sys/class/net`;
• its own port space. Two processes in two namespaces can both listen on TCP 8080 without either getting Address already in use.

Everything else is shared. It is the same kernel, the same filesystem, the same users and, unless other namespace types are also in play, the same process list. That split is the whole trick behind containers. Docker, Podman and every Kubernetes pod put their processes in a fresh network namespace and wire it to the host with the same virtual cable you will build in this lesson.

Every process belongs to exactly one network namespace, and a child inherits its parent's. That one rule explains most namespace surprises: a service is in whatever namespace the shell that started it was in. You can see a process's namespace as a handle under /proc/PID/ns/.

A namespace lives for as long as something refers to it: a process inside it, an open file descriptor on it, or a bind mount of its handle onto a file. ip netns add NAME creates a namespace and bind-mounts its handle onto /run/netns/NAME. That file is the name. ip netns list simply lists that directory, and every other ip netns subcommand finds the namespace through it.

This matters because the other way to make a namespace, unshare --net, creates an anonymous one. It exists only while the process inside it runs, and ip netns list never shows it. You can name one after the fact by bind-mounting its handle yourself (touch /run/netns/x && unshare --net=/run/netns/x true), which is exactly what ip netns add does for you.

To connect islands you need a cable. A veth (virtual Ethernet) device always comes as a pair: a frame sent into one end comes out of the other, like the two ends of a patch cable. Create the pair, move one end into each namespace, then give each end an address and bring it up. Every step is an ip subcommand.

The pair is created in whatever namespace you're in (the host), and ip link set END netns NS moves an end across. An interface can only be in one namespace at a time, so once moved it disappears from the host's ip link.

There are four ways to act inside a namespace, and they suit different jobs:

• ip -n NS … runs ip itself inside NS. It's quick for links, addresses and routes.
• ip netns exec NS CMD runs any command inside NS. It also gives the command a matching /sys and applies /etc/netns/NS/ (next step).
• nsenter --net=/run/netns/NS CMD is the util-linux equivalent. It also works with an anonymous namespace via a PID: nsenter --net --target PID.
• ss -N NS … lists sockets inside NS without switching into it.

A process started with ip netns exec stays in that namespace, and so do all its children. That's how you run a service "inside" one.

A namespace has its own network but shares the filesystem, so a command inside it reads the host's /etc/resolv.conf. That's often wrong. The host may point at 127.0.0.53 (systemd-resolved's stub), and inside a namespace 127.0.0.53 is the namespace's own loopback, where nothing is listening. DNS fails even though routing is fine.

ip netns exec has a built-in fix. For every file in /etc/netns/NAME/, it bind-mounts that file over its /etc counterpart, visible only to the command it runs. Drop a resolv.conf (or a hosts file) there and that namespace gets its own.

ip netns del NAME does less than it sounds like. It removes the name: it unmounts /run/netns/NAME and deletes the file. The namespace itself is destroyed only when its last reference goes. If a process is still running inside, the namespace lives on with its interfaces, addresses and listening sockets, but no longer appears in ip netns list. It's a network stack you can't see, holding ports you can't find from the host.

So check before you delete: ip netns pids NAME lists the processes inside. Stop them, then delete. When a namespace really is destroyed, the veth ends inside it go too, and deleting either end of a veth pair deletes both.

Now build one from memory in your lab terminal, using different names and a different subnet so nothing collides with the demo. Use the one-command veth form this time. After each command, predict what ip -n NS -br addr will show, then check. When you're done, the lab net-namespace-veth gives you your own names, subnet and service port, and grades the live result.