Bridge, host, overlay, macvlan — architecture diagrams and decision guides for every network driver.
Docker networking enables containers to communicate with each other, the Docker host, and external networks. Docker uses the Container Network Model (CNM) to standardize networking across different environments.
Each container runs in its own network namespace, providing isolation of network stack, IP addresses, and routing tables.
Docker uses veth pairs to connect containers to networks. One end is inside the container, the other connects to the host.
Act as virtual switches that forward traffic between containers and the host network.
Containers expose specific ports to the host using port mapping (-p flag), enabling external access.
Containers on the same network can discover each other using container names via built-in DNS.
Docker uses NAT to route traffic between containers and external networks through the host.
| Driver | Scope | Use Case | Default |
|---|---|---|---|
| bridge | Single host | Local container-to-container communication | ✓ Yes |
| host | Single host | No network isolation, direct host network access | ✗ No |
| overlay | Multi-host | Docker Swarm, distributed applications | ✗ No |
| macvlan | Single host | Legacy apps, direct physical network integration | ✗ No |
| ipvlan | Single host | Advanced IP control, high-density environments | ✗ No |
| none | Single host | Complete network isolation, manual configuration | ✗ No |
# List all networks
docker network ls
# Inspect a network
docker network inspect bridge
# Create a custom network
docker network create my-network
# Connect container to network
docker network connect my-network container-name
# Disconnect container from network
docker network disconnect my-network container-name
# Remove a network
docker network rm my-network
The bridge network is Docker's default networking mode. It creates a private internal network on the host, allowing containers on the same bridge to communicate while providing isolation from the host and external networks.
Docker creates a virtual bridge (docker0) on the host, acting as a software switch.
Each container gets a veth pair - one end inside container (eth0), other end attached to docker0.
Containers receive private IPs from the bridge subnet (default: 172.17.0.0/16).
Containers communicate directly via the bridge using IPs or container names.
Docker uses iptables NAT rules to route external traffic through the host.
Use -p flag to map container ports to host ports for external access.
Container A → Container B:
# Use default bridge
docker run -d --name nginx nginx
# Create custom bridge network
docker network create --driver bridge my-bridge
# Run container on custom bridge
docker run -d --name app --network my-bridge nginx
# Publish ports to host
docker run -d -p 8080:80 --name web nginx
# Inspect bridge network
docker network inspect bridge
The host network mode removes network isolation between the container and the Docker host. Containers share the host's network stack directly, using the same IP addresses and ports.
Container doesn't get its own network namespace - uses host's directly.
Container sees all host network interfaces (eth0, lo, etc.) as if running on host.
-p flag has no effect. Container listens on host ports directly.
Container uses the host's IP address for all network operations.
Eliminates network virtualization overhead - best performance.
Multiple containers can't bind to the same port - need to coordinate.
Applications requiring maximum network throughput with minimal latency.
Tools that need to monitor all network traffic on the host.
Services that need to integrate tightly with host networking (VPNs, proxies).
Quick testing where isolation isn't needed and performance matters.
# Run container with host network
docker run -d --network host --name nginx nginx
# Container listens on host's port 80 directly
# No -p flag needed or allowed
# Check container network mode
docker inspect nginx | grep NetworkMode
# Example: Network monitoring tool
docker run -d --network host --name monitor nicolaka/netshoot
Overlay networks enable multi-host networking for Docker Swarm and distributed applications. They create a virtual network spanning multiple Docker hosts, allowing seamless container communication across hosts.
Uses VXLAN (Virtual Extensible LAN) to encapsulate container traffic over the physical network.
Creates a single logical network across multiple Docker hosts in a swarm.
Docker handles routing packets between hosts transparently.
Built-in DNS allows containers to discover services across the entire cluster.
Optional IPsec encryption for secure communication between hosts.
Ingress network provides load balancing for published service ports.
| Port | Protocol | Purpose |
|---|---|---|
| 2377 | TCP | Cluster management communications |
| 7946 | TCP & UDP | Container network discovery |
| 4789 | UDP | Overlay network traffic (VXLAN) |
# Initialize Docker Swarm
docker swarm init
# Create overlay network
docker network create --driver overlay my-overlay
# Create service on overlay network
docker service create --name web --network my-overlay --replicas 3 nginx
# Create overlay with encryption
docker network create --driver overlay --opt encrypted my-secure-overlay
# List overlay networks
docker network ls --filter driver=overlay
# Inspect overlay network
docker network inspect my-overlay
Essential for multi-node Docker Swarm deployments.
Services distributed across multiple hosts need to communicate.
Distribute containers across hosts for fault tolerance.
Applications requiring encrypted communication between hosts.
Macvlan networks assign unique MAC addresses to containers, making them appear as physical devices on the network. This allows containers to be directly connected to the physical network without NAT or port mapping.
Each container receives its own MAC address, separate from the host.
Containers appear as physical devices on the network to external systems.
No NAT or port mapping - containers have direct IPs on physical network.
Can assign containers to specific VLANs (802.1Q tagging).
Bypasses Docker's virtual bridge entirely for maximum performance.
Macvlan networks must be bound to a physical host interface.
Containers on same host can communicate. Traffic to external network goes through parent interface.
VLAN tagging support - assign containers to specific VLANs on trunked interface.
# Create macvlan network
docker network create -d macvlan \
--subnet=192.168.1.0/24 \
--gateway=192.168.1.1 \
-o parent=eth0 my-macvlan
# Run container on macvlan
docker run -d --network my-macvlan --ip=192.168.1.100 --name web nginx
# Create macvlan with VLAN (802.1q)
docker network create -d macvlan \
--subnet=192.168.10.0/24 \
-o parent=eth0.10 vlan10
# Inspect macvlan network
docker network inspect my-macvlan
IPvlan is similar to Macvlan but uses the parent interface's MAC address instead of assigning unique MACs. This is more efficient for high-density environments where MAC address table limits are a concern.
Choose the right network type based on your deployment requirements, performance needs, and infrastructure constraints.
| Feature | Bridge | Host | Overlay | Macvlan |
|---|---|---|---|---|
| Scope | Single host | Single host | Multi-host | Single host |
| Network Isolation | ✓ Yes | ✗ No | ✓ Yes | ✓ Yes |
| Performance | Good | Excellent | Good (overhead) | Excellent |
| Service Discovery | ✓ DNS | ✗ Manual | ✓ DNS | ✗ Manual |
| Port Mapping Required | ✓ Yes | ✗ No | Managed | ✗ No |
| NAT Used | ✓ Yes | ✗ No | ✓ Yes | ✗ No |
| Default Network | ✓ Yes | ✗ No | ✗ No | ✗ No |
| Setup Complexity | Simple | Very Simple | Complex | Moderate |
| Security | Good | Low | Excellent | Good |
| Cloud Compatible | ✓ Yes | ✓ Yes | ✓ Yes | Limited |
Network Performance Ranking (Best to Lowest):
Question 1: Do you need multi-host communication?
YES → Use OVERLAY
NO → Continue to Question 2
Question 2: Do you need maximum performance?
YES → Use HOST (if isolation not needed) or MACVLAN
NO → Continue to Question 3
Question 3: Do you need physical network integration?
YES → Use MACVLAN
NO → Use BRIDGE (default choice)