LFCE 132 🐧 Docker Networking — Concepts
Docker networking is a pluggable subsystem. Every container attaches to a network, and the driver that network uses determines how the container communicates with the host, with other containers, and with the outside world. The default driver is bridge, which creates a private virtual network on the host and uses NAT for outbound traffic. But bridge is not the only option. host removes network isolation entirely, overlay spans multiple Docker hosts, and macvlan/ipvlan make containers appear as physical devices on the local network. Choosing the right driver is a decision about isolation, reachability, and operational complexity.
This chapter covers the five built-in network drivers and the concepts that determine when each one applies: the default bridge versus user-defined bridges, the embedded DNS resolver that makes container-name resolution work, the overlay network’s VXLAN encapsulation for multi-host communication, and the macvlan/ipvlan distinction for containers that need to look like physical hosts.
Key point: The default bridge network does not resolve container names. A user-defined bridge does. This single difference is why the default bridge is not recommended for anything beyond a quick test.
Why Docker networking has these drivers
The isolation problem. A container needs its own network namespace so that it does not compete with the host for ports or see the host’s network interfaces. The bridge driver creates this namespace and connects it to a virtual bridge on the host. The container gets its own IP address on a private subnet, and outbound traffic is NAT’d through the host. The isolation is the point; the NAT is the cost .
The reachability problem. A bridge network is local to one Docker host. If containers on different hosts need to communicate, the bridge cannot help. The overlay driver solves this by creating a virtual network that spans multiple Docker daemons, using VXLAN to encapsulate container traffic in UDP packets that travel between hosts . The overlay network is the foundation of Docker Swarm services, but it can also be used with standalone containers across hosts.
The legacy-application problem. Some applications expect to be directly connected to the physical network. They broadcast, they use protocols that do not traverse NAT, or they need to be reachable by their own MAC address. macvlan assigns a MAC address to the container and connects it directly to the host’s physical interface, making the container appear as a separate physical device on the LAN . ipvlan is similar but shares the host’s MAC address, which is useful when the network restricts the number of MAC addresses per port .
a. The bridge driver and user-defined networks
The bridge driver is the default. When Docker starts, it creates a default bridge network called bridge, and every container without a --network flag attaches to it. Containers on the default bridge can reach each other by IP address, but not by name. They cannot resolve each other through DNS .
A user-defined bridge network is created with docker network create. It behaves like the default bridge in terms of isolation—containers on the same user-defined bridge can reach each other—but it adds two things the default bridge lacks. First, it provides automatic DNS resolution: containers on the same user-defined network can reach each other by container name or network alias . Second, it is scoped: only containers explicitly attached to that network can communicate, whereas the default bridge is shared by every container that does not specify a network .
# Create a user-defined bridge
docker network create my-net
# Run a container on it
docker run --network my-net --name web nginx
# Another container on the same network can resolve "web"
docker run --network my-net --rm curlimages/curl curl http://webThe embedded DNS server is what makes name resolution work. It maintains a mapping between container names and their IP addresses on each user-defined network. The --name flag sets the name, and --network-alias adds additional names . On the default bridge, there is no such resolver, which is why containers on it can only reach each other by IP.
b. The host driver
The host driver removes the network namespace entirely. The container shares the host’s network stack, which means it can bind to the host’s ports directly and see the host’s interfaces. There is no NAT, no port mapping, and no isolation .
This is useful for applications that need the best possible network performance, or that need to bind to a port that is already mapped by the host. The cost is that two containers cannot bind to the same port on the host, because they are both using the host’s network stack. The host driver is also a security consideration: the container has full access to the host’s network interfaces.
c. The overlay driver
The overlay driver connects multiple Docker daemons together. It creates a virtual network that spans hosts, and containers attached to the overlay can communicate as if they were on the same local network. The driver uses VXLAN to encapsulate Ethernet frames in UDP datagrams, tagging each frame with a VXLAN Network ID that identifies the overlay network .
Overlay networks are the foundation of Docker Swarm services. When a service is deployed across a Swarm cluster, the service’s containers are attached to an overlay network, and the ingress routing mesh uses that network to route external traffic to the correct container. The overlay driver can also be used with standalone containers across hosts, but the Swarm integration is the primary use case .
Encrypted overlay networks are available as an option. They use IPsec to protect the VXLAN traffic between nodes, which is important when the overlay traffic crosses an untrusted network. The encryption is off by default and must be explicitly enabled .
d. macvlan and ipvlan
macvlan assigns a MAC address to the container and connects it directly to a physical interface on the host. The container appears on the LAN as a separate physical device. It can be assigned an IP address from the LAN’s DHCP server, and other devices on the LAN can reach it without going through the Docker host’s NAT .
ipvlan is similar, but the container shares the host’s MAC address. The distinction matters on networks that restrict the number of MAC addresses per switch port, or that have issues with multiple MACs on a single interface. ipvlan solves the MAC address limitation, but some network equipment may not handle multiple IPs on the same MAC correctly .
Both drivers are appropriate for legacy applications that expect to be directly connected to the physical network, or for containers that need to be reachable by their own IP address without port mapping .
Complete Example Session
# ============================================
# PART 1: THE DEFAULT BRIDGE
# ============================================
docker run -d --name web1 nginx
docker run -d --name web2 nginx
# Both are on the default bridge.
# web1 cannot reach web2 by name.
docker exec web1 curl http://web2
# curl: (6) Could not resolve host: web2# ============================================
# PART 2: A USER-DEFINED BRIDGE
# ============================================
docker network create my-net
docker run -d --network my-net --name web3 nginx
docker run -d --network my-net --name web4 nginx
# web3 can resolve web4 by name.
docker exec web3 curl http://web4
# <html>...# ============================================
# PART 3: THE HOST DRIVER
# ============================================
docker run -d --network host --name web-host nginx
# The container binds to the host's port 80 directly.
curl http://localhost:80
# No port mapping needed.# ============================================
# PART 4: THE NONE DRIVER
# ============================================
docker run -d --network none --name isolated alpine sleep 3600
# The container has no network access.
docker exec isolated ip addr
# Only the loopback interface.# ============================================
# PART 5: LISTING NETWORKS
# ============================================
docker network ls
# NETWORK ID NAME DRIVER SCOPE
# ... bridge bridge local
# ... host host local
# ... none null local
# ... my-net bridge local# ============================================
# PART 6: INSPECTING A NETWORK
# ============================================
docker network inspect my-net
# Shows the subnet, gateway, and connected containers.# ============================================
# PART 7: CONNECTING A RUNNING CONTAINER
# ============================================
docker network connect my-net web1
# web1 is now on both the default bridge and my-net.
docker exec web1 curl http://web3# ============================================
# PART 8: DISCONNECTING
# ============================================
docker network disconnect my-net web1# ============================================
# PART 9: PORT PUBLISHING
# ============================================
docker run -d --network my-net -p 8080:80 --name web-pub nginx
# The container is reachable from the host on port 8080.
curl http://localhost:8080# ============================================
# PART 10: REMOVING A NETWORK
# ============================================
docker network rm my-net
# Error: network my-net has active endpoints
# Disconnect the containers first.
docker network disconnect my-net web3
docker network disconnect my-net web4
docker network rm my-netThe ten parts covered the default bridge’s name-resolution failure, the user-defined bridge’s DNS, the host driver, the none driver, listing networks, inspecting, connecting a running container, disconnecting, port publishing, and network removal.
Quick Reference
Network drivers
| Driver | Isolation | Multi-host | Name resolution | Use case |
|---|---|---|---|---|
bridge (default) | Yes | No | No | Quick tests, legacy |
bridge (user-defined) | Yes | No | Yes | Normal container communication |
host | No | No | N/A | Performance, host port access |
none | Complete | No | No | Fully isolated containers |
overlay | Yes | Yes | Yes | Swarm services, multi-host |
macvlan | LAN-level | No | LAN DNS | Containers as physical hosts |
ipvlan | LAN-level | No | LAN DNS | Same, with MAC restrictions |
Bridge comparison
| Feature | Default bridge | User-defined bridge |
|---|---|---|
| DNS by name | No | Yes |
| Scoped isolation | No (all containers) | Yes (only attached) |
| Configure per network | No | Yes |
| Attach/detach at runtime | No | Yes |
Key commands
| Command | Purpose |
|---|---|
docker network create <name> | Create a user-defined network |
docker network ls | List networks |
docker network inspect <name> | Show network details |
docker network connect <net> <ctr> | Attach a running container |
docker network disconnect <net> <ctr> | Detach |
docker network rm <name> | Remove |
Overlay specifics
| Item | Value |
|---|---|
| Encapsulation | VXLAN over UDP (port 4789) |
| Multi-host | Yes (Swarm or standalone) |
| Encryption | Optional, IPsec, off by default |
| Ingress | Swarm routing mesh |
Best Practices
✅ Do This:
# Use a user-defined bridge for container-to-container communication
docker network create app-net # ✅# Use --name so containers can resolve each other
docker run --network app-net --name db postgres # ✅# Use host only when the container needs the host's network stack
docker run --network host nginx # ✅# Use macvlan when the container must appear as a LAN device
docker network create -d macvlan ... # ✅❌ Don’t Do This:
# Rely on the default bridge for name resolution
docker run --name web nginx
docker exec other curl http://web # fails # ❌# Use host networking for isolation
docker run --network host ... # ❌ (no isolation)# Use overlay on a single host
# Bridge provides the same connectivity without the multi-host overhead # ❌# Assume macvlan works on Wi-Fi
# Many Wi-Fi drivers do not support macvlan # ❌Common Pitfalls
| Pitfall | Why It Happens | Fix |
|---|---|---|
| Container name does not resolve | On the default bridge | Use a user-defined bridge |
| Port not reachable from outside | No -p flag | Publish the port |
| Container cannot reach the internet | No gateway or NAT | Check the bridge gateway and iptables |
| Overlay network not working | Swarm not initialized or ports blocked | Initialize Swarm; open VXLAN port |
| macvlan not working | Wi-Fi or restricted interface | Use a wired interface or ipvlan |
| Network cannot be removed | Active endpoints | Disconnect containers first |
Real-World Examples
1. Create a user-defined bridge
docker network create app-net2. Run a container on it
docker run --network app-net --name db postgres3. Resolve by name
docker exec app curl http://db:54324. Host networking
docker run --network host nginx5. None networking
docker run --network none alpine sleep 36006. Publish a port
docker run -p 8080:80 nginx7. Inspect a network
docker network inspect app-net8. Connect a running container
docker network connect app-net web9. Disconnect
docker network disconnect app-net web10. Create an overlay network (Swarm)
docker network create -d overlay my-overlayVisual
The bridge network
┌─────────────────────────────────────────────────────────────┐
│ BRIDGE NETWORK │
│ │
│ Host │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ docker0 bridge (172.17.0.1) ││
│ │ │ ││
│ │ ├── container A (172.17.0.2) ││
│ │ │ ││
│ │ └── container B (172.17.0.3) ││
│ │ ││
│ │ NAT for outbound traffic ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ Containers on the default bridge cannot resolve each other │
│ by name. User-defined bridges can. │
└─────────────────────────────────────────────────────────────┘The overlay network
┌─────────────────────────────────────────────────────────────┐
│ OVERLAY NETWORK │
│ │
│ Host 1 Host 2 │
│ ┌──────────────┐ ┌──────────────┐ │
│ │ container A │ │ container B │ │
│ │ 10.0.0.2 │ │ 10.0.0.3 │ │
│ └──────┬───────┘ └──────┬───────┘ │
│ │ │ │
│ ▼ ▼ │
│ VXLAN encapsulation VXLAN decapsulation │
│ UDP port 4789 UDP port 4789 │
│ │ │ │
│ └────────── network ────────────┘ │
│ │
│ Containers appear on the same virtual network. │
└─────────────────────────────────────────────────────────────┘macvlan vs ipvlan
┌─────────────────────────────────────────────────────────────┐
│ MACVLAN IPVLAN │
│ │
│ Container gets its own MAC Container shares host MAC │
│ Appears as separate device Appears as host device │
│ DHCP can assign IP DHCP may not work │
│ MAC limit applies No MAC limit │
└─────────────────────────────────────────────────────────────┘Network selection decision
┌─────────────────────────────────────────────────────────────┐
│ WHICH DRIVER? │
│ │
│ Containers on the same host need to talk? │
│ └── User-defined bridge │
│ │
│ Containers on different hosts need to talk? │
│ └── Overlay (Swarm) │
│ │
│ Container needs the host's network stack? │
│ └── Host │
│ │
│ Container needs to appear as a physical LAN device? │
│ ├── MAC restrictions? ──► ipvlan │
│ └── No restrictions? ──► macvlan │
└─────────────────────────────────────────────────────────────┘Summary
| Item | Value |
|---|---|
| Default driver | bridge |
| User-defined bridge | DNS by name, scoped isolation |
| Host driver | No isolation, host network stack |
| None driver | Complete isolation |
| Overlay driver | Multi-host, VXLAN, Swarm |
| Macvlan | Container as LAN device, own MAC |
| Ipvlan | Container as LAN device, shared MAC |
| Port publishing | -p host:container |
| Network creation | docker network create |
Key takeaways:
- The default bridge does not resolve container names. Containers on the default bridge can only reach each other by IP address. A user-defined bridge provides embedded DNS that resolves names and aliases .
- User-defined bridges are scoped. Only containers explicitly attached to the network can communicate. The default bridge is shared by every container that does not specify a network, which is why it is not recommended for production .
- The host driver removes isolation. The container shares the host’s network stack. It can bind to host ports directly, but it has no network namespace of its own and no isolation from the host .
- Overlay networks span hosts using VXLAN. The driver encapsulates container traffic in UDP datagrams (port 4789) and tags each frame with a VXLAN Network ID. Encryption is optional and off by default .
- Macvlan and ipvlan make containers look like physical devices. Macvlan assigns a MAC address; ipvlan shares the host’s MAC. The choice depends on the network’s MAC address restrictions and the behavior of the network equipment .
- Port publishing is required for external access. A container on a bridge network is not reachable from outside the host unless a port is published with
-p. The default binding is all host addresses, but it can be restricted .
Remember: Docker networking is a decision about isolation and reachability. The bridge driver isolates containers on the same host. The host driver removes isolation. The overlay driver connects hosts. Macvlan and ipvlan connect containers to the physical LAN. The default bridge is a starting point, not a production choice: it lacks name resolution and is shared by every container. Use a user-defined bridge for container-to-container communication, publish ports only for the services that need external access, and choose the driver that matches the network topology the application expects.
Stop using slow, ad-bloated tool sites! 🤮
🔎 Search “KandZ Tools” on Google to use many professional utilities for free.
KandZ.me is the ultimate minimalist hub for:
✅ Finance (Mortgage, Interest, Inflation)
✅ Tech (Base64, JSON, Dev Suite, IP)
✅ Health (BMI, BMR, TDEE)
✅ Productivity (Timer, Workspace, QR)
⚡️ Fast & Private
🔒 No data leaves your device
💎 100% Free
🔗 Use it now: https://tools.kandz.me
🔖 Bookmark it—you’ll need it later!