Linux Network Namespaces Explained

Why network namespaces matter

A Linux network namespace gives a process its own view of network resources. Interfaces, routes, firewall rules, protocol settings, and many socket-related controls can differ between namespaces. A process inside one namespace therefore sees a deliberately limited network environment instead of the host's complete one.

This primitive is one reason containers can have separate network identities without running a separate kernel. The namespace itself does not create a container, provide a network connection, or impose a security boundary for every resource. It is a kernel isolation feature that other tools combine with filesystem, process, user, and control-group settings.

The most useful mental model is a small network stack context attached to a process. If a process is created in a namespace, or moved there, its network operations use that context. The namespace can contain a loopback device, virtual interfaces, routes, and addresses that are independent of the host namespace.

A namespace starts disconnected

Create a named namespace and inspect it with the ip utility. These commands require administrator privileges on a Linux system with iproute2 installed.

ip netns add lab
ip netns list
ip -n lab link show

The new namespace has a loopback device, but it is usually down. It has no route to the host and no external connectivity. This is a useful default: isolation does not imply that connectivity should be granted automatically.

Bring its loopback interface up, then run a command inside it:

ip -n lab link set lo up
ip netns exec lab ip address

The second command runs the ip utility in the namespace. The same pattern works for many tools, including shells, packet captures, and small test servers. A named namespace is a convenient handle managed through ip netns; the kernel namespace remains alive while processes or other references still hold it.

Connect it with a virtual Ethernet pair

A veth pair behaves like a virtual cable with one endpoint on each side. Move one endpoint into the namespace and keep the other in the host. Assign addresses from a private test subnet and bring both interfaces up.

ip link add veth-host type veth peer name veth-lab
ip link set veth-lab netns lab
ip address add 10.200.0.1/24 dev veth-host
ip link set veth-host up
ip -n lab address add 10.200.0.2/24 dev veth-lab
ip -n lab link set veth-lab up
ip -n lab link set lo up

The namespace can now reach the host endpoint on the directly connected subnet:

ip netns exec lab ping -c 2 10.200.0.1

The host endpoint can also reach the namespace address. This is a two-node link, not internet access. Adding a default route without forwarding and an upstream route will not make packets magically leave the host. Routing, address translation, firewall policy, and DNS are separate decisions.

Inspect the boundary instead of guessing

Run ip commands both inside and outside the namespace. Compare addresses and routes. A command that works on the host may fail from the namespace because the relevant interface or route is not present there. That difference is often the point of the experiment.

For a more complete connection, an operator might enable forwarding on the host, add a route or NAT rule, and configure a resolver. Each step broadens what the isolated workload can reach. A lab should add only the connectivity required by its test and remove temporary rules afterward. Production policies need explicit source, destination, and port restrictions rather than an unrestricted forwarding rule.

Network namespaces also help test software that binds a fixed port, handles multiple interfaces, or expects a dedicated route table. Separate namespace contexts can reuse the same private address range because those addresses exist in different routing domains. They still need a deliberate bridge if they are expected to communicate.

How namespaces fit into containers

Container engines commonly arrange a veth pair between a container network namespace and a host bridge. The host then applies routing and firewall rules so traffic can reach other containers or external networks. The exact configuration depends on the engine and its network mode.

Network namespaces are only one part of the isolation model. A process may share the host network namespace while using other namespaces, or it may have a dedicated network namespace with broad privileges. User namespaces affect which kernel capabilities are available; cgroups constrain resource use; seccomp and Linux security modules can restrict system calls and access. Review the whole runtime configuration before treating a container as a security boundary.

It is also useful to distinguish a namespace from a network policy. A namespace separates network state. Policy determines which packets are allowed across connections between namespaces and the host. Bridges and routes establish paths; firewall rules constrain those paths. Clear boundaries make both easier to reason about.

Cleanup and repeatability

Remove the named namespace when the experiment is complete. The host-side veth device is removed when its peer disappears.

ip netns del lab
ip link show veth-host

The final inspection should report that veth-host no longer exists. If it remains, check whether another process still holds the namespace open or whether the test was interrupted before cleanup. Repeating setup from a clean state helps distinguish a real networking issue from leftovers.

The key lesson is that a network namespace is a kernel-provided view, not a full network architecture. Pair it with a veth link to make connectivity explicit, inspect routes at each boundary, and add forwarding only when the experiment requires it. That modest approach scales from a shell-level test to understanding how container networking is assembled.