Network Namespaces

Ports belong to a network stack, not to a machine. In Linux the network stack — its interfaces, IP addresses, routing table, conntrack and firewall rules, socket table and net.* sysctls — is one instance of a network namespace, and the kernel can hold many. A process belongs to exactly one; every socket it creates is created in that namespace and is invisible to sockets in others. Two namespaces each have their own port 80, their own lo with 127.0.0.1, their own default route. bind(:80) in namespace A and bind(:80) in namespace B do not conflict because they are entries in two different tables.

This is the same mechanism that gives a container its own PID 1, its own mount table and its own hostname — see Process Isolation: One Kernel, Many PID 1s for the namespace family — applied to the network. A container is not a VM with a virtual NIC and its own kernel; it is a process group that the shared kernel shows a private view of the network. That is why a container has no network devices at all until someone creates some for it, and why docker run --network none is a real, working configuration: a namespace with only lo.

A new namespace has a loopback interface and nothing else, so it cannot talk to anything. To connect it, the kernel offers a veth pair: two virtual Ethernet interfaces created together, where a frame sent into one comes out of the other, like the two ends of a patch cable. Put one end in the container’s namespace (it becomes its eth0) and leave the other in the host namespace (veth3a1b…). Give the container end an address, add a default route through it, and the container has a link to the host.

The host end is usually plugged into a bridge — a software switch, docker0 — so that many containers’ veth ends share one L2 segment and can reach each other by address, exactly like ports on a physical switch (Ethernet: Delivery on One Local Network). Frames that need to leave the host go bridge → host routing table → physical NIC, with NAT on the way (Container Networking). From inside, the container sees a normal eth0, a normal gateway, ARP, everything; the "network" behind it is entirely in the host kernel.

Everything Docker or a CNI plugin does at this layer is a handful of ip commands. Building a namespace by hand once removes most of the mystery: you can see the veth pair appear in both namespaces, watch the second bind(:80) succeed, and observe that ss inside the namespace shows only its own sockets.

Note that ip netns shows only namespaces it created, because it names them with a bind mount under /run/netns. Docker creates namespaces without names; to inspect a container’s use nsenter -t <pid> -n ss -ltn with the container’s PID, or symlink /proc/<pid>/ns/net into /run/netns so the ip netns tooling can find it.

Isolated per namespace: interfaces and their addresses, the routing tables and policy rules, conntrack and the nftables/iptables rule sets, the socket and port tables, the ARP/neighbour cache, and network sysctls such as net.ipv4.ip_forward and the socket buffer limits. A container that sets net.core.somaxconn sets it for itself. A container that runs iptables -F flushes only its own rules.

Not isolated: the kernel itself, the physical NIC and its driver queues, the total number of conntrack entries the kernel will allocate, and CPU time spent in the network stack. A container that saturates the NIC starves the others; a namespace with a huge conntrack table competes for the same memory. Namespaces partition names and tables, not hardware — the same limit that Containers Are Processes With the Kernel’s View Narrowed describes for the OS as a whole.