Why Container Networking Is Simpler Than You Think: A Hands‑On Guide

Understanding Container Networking

Containers feel magical, but they are just isolated Linux processes. A container’s network stack can be built without an image, using only Linux primitives such as network namespaces, virtual Ethernet (veth) devices, and virtual bridges.

Network Namespace Isolation

A network namespace provides a separate network stack with its own interfaces, routes, and firewall rules. Creating one with sudo ip netns add netns0 and listing it with ip netns shows the new namespace.

To inspect the stack we use a simple script

#!/usr/bin/env bash
echo "> Network devices"
ip link
echo -e "
> Route table"
ip route
echo -e "
> Iptables rules"
iptables --list-rules

which prints devices, routing tables and iptables rules before any configuration.

Connecting a Namespace with veth

We create a pair of virtual Ethernet devices that act as a tunnel between the root namespace and the container namespace:

sudo ip link add veth0 type veth peer name ceth0

Move ceth0 into the namespace and bring the interfaces up:

sudo ip link set ceth0 netns netns0
sudo ip link set veth0 up
sudo nsenter --net=/var/run/netns/netns0 ip link set lo up
sudo nsenter --net=/var/run/netns/netns0 ip link set ceth0 up

Assign IP addresses on the same /16 subnet:

sudo nsenter --net=/var/run/netns/netns0 ip addr add 172.18.0.10/16 dev ceth0
sudo ip addr add 172.18.0.11/16 dev veth0

Now the two ends can ping each other, confirming that the namespace sees an independent network stack.

Scaling to Multiple Containers – The Bridge

When several containers share the same host, using only veth pairs creates routing conflicts. A Linux bridge works like a virtual switch, forwarding L2 frames between attached interfaces. After cleaning previous configuration, we create a bridge and attach both veth devices:

sudo ip link add br0 type bridge
sudo ip link set br0 up
sudo ip link set veth0 master br0
sudo ip link set veth1 master br0

Assign an IP to the bridge so the host can act as the default gateway for the containers: sudo ip addr add 172.18.0.1/16 dev br0 Containers now obtain connectivity to each other and to the host.

External Connectivity – Routing and NAT

To reach the outside world, enable IP forwarding on the host:

sudo bash -c 'echo 1 > /proc/sys/net/ipv4/ip_forward'

Then add a masquerade rule so container‑originated packets appear to come from the host’s external address:

sudo iptables -t nat -A POSTROUTING -s 172.18.0.0/16 ! -o br0 -j MASQUERADE

After adding a default route inside each namespace ( ip route add default via 172.18.0.1) containers can ping public IPs such as 8.8.8.8.

Docker Network Drivers

Docker implements similar concepts with built‑in drivers. --network host disables namespace isolation, --network none leaves only a loopback interface, and the default bridge driver creates a bridge (docker0) and configures NAT automatically. The generated iptables rules illustrate how Docker isolates and publishes ports.

Rootless Containers

Rootless tools like Podman cannot create veth pairs without privileges. They rely on slirp4netns to provide user‑space networking, which lacks raw socket capabilities (e.g., ping) but still offers Internet access.

Conclusion

Container networking on a single host boils down to Linux network namespaces, veth pairs, bridges, routing, and NAT. Understanding these primitives demystifies Docker’s network drivers and helps when working with rootless containers or custom networking setups.