Understanding Docker Network Drivers
Docker provides several built-in network drivers, each engineered to address specific connectivity, performance, and isolation requirements. Selecting the appropriate driver depends on the desired balance between security constraints and communication patterns.
- None Driver: Strips away all external networking interfaces. The container retains only the local loopback device. Best suited for offline computation, data processing pipelines, or security-sensitive workloads where external connectivity is strictly prohibited.
- Host Driver: Eliminates network isolation by attaching the container directly to the host’s network stack. This bypasses NAT and virtual routing, delivering maximum throughput. The trade-off is potential port contention, as bindings interact directly with host interfaces.
- Bridge Driver: The default configuration. Docker instantiates a software bridge on the host and connects containers via virtual ethernet pairs (veth). Containers receive private subnet addresses and communicate through NAT, making it ideal for standard multi-tier applications.
- Container Driver: Allows a newly launched container to inherit the network namespace of an existing container. Both containers share the same IP address, routing table, and port space, enabling tightly coupled sidecar patterns without host-level exposure.
- Custom/Plugin Drivers: Supports advanced topologies through user-defined networks or third-party CNI plugins (e.g., overlay, macvlan, ipvlan). Essential for multi-host clustering, cross-datacenter communication, or integrating with software-defined networking solutions.
Practical Network Configuration
Network inspection and container provisioning are managed through the Docker CLI. The following workflow demonstrates deploying containers across different network modes with modern command structures.
# Enumerate available network drivers
docker network list
# Inspect default bridge subnet and gateway configuration
docker network inspect bridge --format '{{.IPAM.Config}}'
# Deploy containers with distinct network isolation levels
docker run -d --name isolated-worker --network none alpine sleep infinity
docker run -d --name host-bound-app --network host alpine sleep infinity
docker run -d --name bridged-service --network bridge alpine sleep infinity
docker run -d --name network-sharing-peer --network container:bridged-service alpine sleep infinity
# Verify active container states
docker ps -a --filter "status=running"
Driver-Specific Verification & Mechanics
None Mode Isolation
Containers launched with the none driver lack routable interfaces. Verification confirms the absence of external IPs and routing tables.
docker exec -it isolated-worker ip addr show lo
# Output confirms only loopback is active
Host Mode Performance
Host networking bypasses Docker’s virtualization layer. The container mirrors the host’s interface configuration and routing policies exactly.
docker exec -it host-bound-app ip addr show eth0
# Interfaces match the host system precisely
Bridge Mode & Virtual Ethernet Pairs
The bridge driver relies on Linux virtual ethernet (veth) pairs. One endpoint resides inside the container’s network namespace, while the opposite endpoint attaches to the host bridge (docker0 or a custom network). This architecture enables NAT routing and DHCP-assigned addressing.
docker exec -it bridged-service ip addr show eth0
# Container receives a private subnet IP (e.g., 172.17.x.x)
# Inspect veth pair mapping on the host
docker inspect bridged-service --format '{{.NetworkSettings.SandboxKey}}'
ls -la /var/run/docker/netns/
Container Mode Namespace Sharing
When a container joins another’s network namespace, it inherits the exact same networking stack. Port bindings, DNS resolution, and IP configurations are shared, not duplicated.
docker exec -it network-sharing-peer ip addr show
# Output matches bridged-service exactly
# Both containers operate within the same net namespace inode
Linux Namespaces: The Foundation of Container Isolation
Docker networking and process isolation are built upon Linux kernel namespaces. Each runing container maps to a unique set of namespace identifiers, visible with in the /proc/[pid]/ns/ directory. These inodes dictate resource boundaries and isolation scopes.
- cgroup: Controls resource limits (CPU, memory, I/O throttling). View with:
readlink /proc/1/ns/cgroup - ipc: Isolates shared memory segments, semaphores, and message queues. View with:
readlink /proc/1/ns/ipc - mnt: Manages filesystem mount points and view boundaries. View with:
readlink /proc/1/ns/mnt - net: The core of Docker networking. Isolates network interfaces, routing tables, ARP caches, and IP stacks. View with:
readlink /proc/1/ns/net - pid: Separates process ID numbering, preventing cross-container process visibility and signaling. View with:
readlink /proc/1/ns/pid - user: Maps container UIDs/GIDs to different host ranges for privilege separation. View with:
readlink /proc/1/ns/user - uts: Isolates hostname and domain name fields. View with:
readlink /proc/1/ns/uts - time: (Kernel 5.6+) Decouples container clocks from the host system time. View with:
readlink /proc/1/ns/time
By leveraging these namespace inodes, the kernel enforces strict boundaries. Docker orchestrates these isolation mechanisms automatically, translating high-level network drivers into low-level namespace configurations and veth routing rules.