How Docker Bridges Containers: Inside Veth Pairs and Network Namespaces

Docker relies on Linux virtualization features to provide container networking. Each container runs in its own network namespace, which includes its own network interface, loopback device, routing table, and iptables rules.

A Glimpse Inside

After running docker run -d --name xxx, you can enter the container and inspect its network configuration.

# docker ps can view all containers
# Enter container
docker exec -it 228ae947b20e /bin/bash

Running ifconfig inside the container shows an eth0 interface (a Veth pair) and the loopback device.

eth0      Link encap:Ethernet  HWaddr 22:A4:C8:79:DD:1A
          inet addr:192.168.65.28  Bcast:0.0.0.0  Mask:255.255.255.255
          UP BROADCAST RUNNING MULTICAST  MTU:1440  Metric:1
          RX packets:2231528 errors:0 dropped:0 overruns:0 frame:0
          TX packets:3340914 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:249385222 (237.8 MiB)  TX bytes:590701793 (563.3 MiB)
lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0

The eth0 interface is the container side of a Veth pair. Checking the routing table with route reveals that eth0 is the default gateway and that all traffic to the 169.254.1.0/16 subnet is also routed via eth0 .

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref Use Iface
default         169.254.1.1     0.0.0.0         UG    0      0   0   eth0
169.254.1.0     0.0.0.0         255.255.0.0     UH    0      0   0   eth0

On the host, the other ends of the Veth pairs appear as virtual Ethernet devices attached to the docker0 bridge.

# ifconfig (host)
... 
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
    inet 172.16.241.192  netmask 255.255.240.0  broadcast 172.16.255.255
...
docker0: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500
    inet 172.17.0.1  netmask 255.255.0.0  broadcast 172.17.255.255
vethd08be47: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
    ether 16:37:8d:fe:36:eb  txqueuelen 0 (Ethernet)

Running brctl show confirms that each Veth end is plugged into docker0 :

# brctl show
bridge name    bridge id        STP enabled    interfaces
docker0        8000.0242afb1a841    no    vethd08be47

When two containers are started, two Veth pairs are attached to the bridge, allowing the containers to ping each other directly.

# brctl show (after two containers)
bridge name    bridge id        STP enabled    interfaces
docker0        8000.0242afb1a841    no    veth26cf2cc veth8762ad2

Example of container‑to‑container ping:

# ping 172.17.0.3
PING 172.17.0.3 (172.17.0.3): 56 data bytes
64 bytes from 172.17.0.3: icmp_seq=0 ttl=64 time=0.142 ms
...

Communication works because the destination IP matches the second routing rule (gateway 0.0.0.0), which means the packet is sent directly via eth0 . The container issues an ARP broadcast to resolve the MAC address of the target IP. The docker0 bridge acts as a layer‑2 switch, forwarding the ARP request to all attached Veth interfaces. The target container replies with its MAC address, allowing the original container to send the packet through its Veth pair, across the host bridge, and into the destination container’s network namespace.

This bridge mode is the default Docker networking model. Other modes such as host , container , and none exist, and for multi‑host communication overlay networks (e.g., Flannel, Calico) are required because the default docker0 bridge on each host is isolated.

Cross‑Host Communication

In a single‑host setup, containers can communicate via the bridge. Across multiple hosts, the default bridges are not connected, so containers cannot reach each other. Creating a shared virtual bridge (an overlay network) that spans all hosts solves this problem, providing a unified network for containers regardless of their physical location.

Source: https://www.cnblogs.com/sally-zhou/p/13463016.html Author: Mr_Zack