Docker networking is a crucial aspect of containerization that enables containers to communicate with each other and the outside world. Understanding how Docker manages network connectivity is essential for building scalable, secure container applications.
π― What You'll Learn: In this comprehensive networking tutorial, you'll discover:
- How Docker's default bridge network operates
- Container-to-container communication patterns
- Network inspection and troubleshooting techniques
- IP address assignment and network isolation
- Testing connectivity between containers using ping and HTTP requests
- Understanding network configuration and IPAM (IP Address Management)
Time to read: ~12 minutes | Difficulty: Intermediate
π Understanding Docker Network Architecture
Docker provides several networking options, but the default bridge network is where most container communication begins. This network acts as a virtual bridge on your host system, allowing containers to communicate while providing isolation from the host network.
Prerequisites
Before we begin, make sure you have:
- Docker installed and running on your system
- Basic understanding of Docker containers
- Familiarity with networking concepts (IP addresses, subnets)
- Understanding of Linux command-line tools
π Step 1: Examining Default Docker Networks
Let's start by exploring the default networks that Docker creates automatically.
Listing Available Networks
docker network ls
This command reveals Docker's default network configuration:
NETWORK ID NAME DRIVER SCOPE
10acedb416a3 bridge bridge local
4014e1a64d4c host host local
b84fc03ca6b5 none null local
Network | Driver | Purpose | Use Case |
---|---|---|---|
bridge | bridge | Default container network | Standard container-to-container communication |
host | host | Uses host network directly | High-performance applications, no isolation |
none | null | No networking | Isolated containers with no network access |
Inspecting the Default Bridge Network
Let's examine the default bridge network configuration:
docker network inspect bridge
This command returns detailed network information in JSON format:
[
{
"Name": "bridge",
"Id": "10acedb416a3a8d61f5e135384cbbb9f42bf500d735c0a71a7ff5d66728833c8",
"Created": "2025-09-12T12:43:20.409918758+05:00",
"Scope": "local",
"Driver": "bridge",
"EnableIPv4": true,
"EnableIPv6": false,
"IPAM": {
"Driver": "default",
"Options": null,
"Config": [
{
"Subnet": "172.17.0.0/16",
"Gateway": "172.17.0.1"
}
]
},
"Internal": false,
"Attachable": false,
"Ingress": false,
"ConfigFrom": {
"Network": ""
},
"ConfigOnly": false,
"Containers": {},
"Options": {
"com.docker.network.bridge.default_bridge": "true",
"com.docker.network.bridge.enable_icc": "true",
"com.docker.network.bridge.enable_ip_masquerade": "true",
"com.docker.network.bridge.host_binding_ipv4": "0.0.0.0",
"com.docker.network.bridge.name": "docker0",
"com.docker.network.driver.mtu": "1500"
},
"Labels": {}
}
]
Key Network Properties:
Property | Value | Explanation |
---|---|---|
Subnet | 172.17.0.0/16 | IP range available for containers (172.17.0.1 to 172.17.255.254) |
Gateway | 172.17.0.1 | Bridge gateway IP address |
Driver | bridge | Linux bridge networking driver |
Containers | Currently empty - no containers attached |
β Network Analysis: The default bridge network provides a private IP range (172.17.0.0/16) with automatic IP assignment starting from 172.17.0.2 (the first IP after the gateway).
π₯οΈ Step 2: Creating Containers on the Default Network
Let's create containers and observe how they're assigned to the default network.
Creating the First Container
docker run -d --name web-server-1 nginx:alpine
Docker pulls the nginx:alpine image and creates the container:
Unable to find image 'nginx:alpine' locally
alpine: Pulling from library/nginx
9824c27679d3: Pull complete
6bc572a340ec: Pull complete
403e3f251637: Pull complete
9adfbae99cb7: Pull complete
7a8a46741e18: Pull complete
c9ebe2ff2d2c: Pull complete
a992fbc61ecc: Pull complete
cb1ff4086f82: Pull complete
Digest: sha256:42a516af16b852e33b7682d5ef8acbd5d13fe08fecadc7ed98605ba5e3b26ab8
Status: Downloaded newer image for nginx:alpine
51213765205e4a632912a3722149be9b1a2783040779aeb0876351962644716c
Verifying Container Status
docker ps
Output confirms the container is running:
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
51213765205e nginx:alpine "/docker-entrypoint.β¦" 2 seconds ago Up 2 seconds 80/tcp web-server-1
Container Details:
Field | Value | Description |
---|---|---|
CONTAINER ID | 51213765205e | Shortened unique identifier |
IMAGE | nginx:alpine | Lightweight Alpine-based Nginx |
PORTS | 80/tcp | Internal port 80 exposed (not published to host) |
STATUS | Up 2 seconds | Container running for 2 seconds |
Inspecting Network After Container Creation
docker network inspect bridge
The network now shows the attached container:
"Containers": {
"51213765205e4a632912a3722149be9b1a2783040779aeb0876351962644716c": {
"Name": "web-server-1",
"EndpointID": "9dcd879a713a7bff3bfb45b5588d23d0943df4d70c0fff01559da5b04105467d",
"MacAddress": "62:a2:32:80:a0:09",
"IPv4Address": "172.17.0.2/16",
"IPv6Address": ""
}
}
π‘ IP Assignment: Docker automatically assigned 172.17.0.2
to our first container, which is the first available IP after the gateway (172.17.0.1).
π Step 3: Adding More Containers
Let's create additional containers to see how Docker handles multiple containers on the same network.
Creating Additional Containers
docker run -d --name web-server-2 nginx:alpine
docker run -d --name alpine-client alpine:latest sleep 3600
The Alpine client requires downloading a new image:
# web-server-2 output
7ea2cda4c9c913e65e43a64b8b1cb86c2b1538bed88f388f65872d611f32fec0
# alpine-client output
Unable to find image 'alpine:latest' locally
latest: Pulling from library/alpine
9824c27679d3: Already exists
Digest: sha256:4bcff63911fcb4448bd4fdacec207030997caf25e9bea4045fa6c8c44de311d1
Status: Downloaded newer image for alpine:latest
2b7034890c35344265b6cdfe8dde4237f45ecd59883267ecfa8d39c097ea89fc
Verifying All Containers
docker ps
All three containers are now running:
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
2b7034890c35 alpine:latest "sleep 3600" 8 seconds ago Up 7 seconds alpine-client
7ea2cda4c9c9 nginx:alpine "/docker-entrypoint.β¦" 38 seconds ago Up 38 seconds 80/tcp web-server-2
51213765205e nginx:alpine "/docker-entrypoint.β¦" 2 minutes ago Up 2 minutes 80/tcp web-server-1
Examining Network with Multiple Containers
docker network inspect bridge
The network now shows all three containers with sequential IP assignments:
"Containers": {
"2b7034890c35344265b6cdfe8dde4237f45ecd59883267ecfa8d39c097ea89fc": {
"Name": "alpine-client",
"EndpointID": "5a2c9627602d75a386dd0809e0663015698b51813246786d013f79ba0b3937d3",
"MacAddress": "ca:c8:af:8c:bb:38",
"IPv4Address": "172.17.0.4/16",
"IPv6Address": ""
},
"51213765205e4a632912a3722149be9b1a2783040779aeb0876351962644716c": {
"Name": "web-server-1",
"EndpointID": "9dcd879a713a7bff3bfb45b5588d23d0943df4d70c0fff01559da5b04105467d",
"MacAddress": "62:a2:32:80:a0:09",
"IPv4Address": "172.17.0.2/16",
"IPv6Address": ""
},
"7ea2cda4c9c913e65e43a64b8b1cb86c2b1538bed88f388f65872d611f32fec0": {
"Name": "web-server-2",
"EndpointID": "fdcbefb89413497565a69e11841d578255e4147d6003e9e005052a3b4a2e6369",
"MacAddress": "4a:d0:70:40:e0:d4",
"IPv4Address": "172.17.0.3/16",
"IPv6Address": ""
}
}
IP Assignment Pattern:
Container | IP Address | MAC Address | Creation Order |
---|---|---|---|
web-server-1 | 172.17.0.2 | 62:a2:32:80:a0:09 | First |
web-server-2 | 172.17.0.3 | 4a:d0:70:40:e0:d4 | Second |
alpine-client | 172.17.0.4 | ca:c8:af:8c:bb:38 | Third |
β Sequential Assignment: Docker assigns IP addresses sequentially starting from 172.17.0.2, with each container getting a unique MAC address automatically.
π Step 4: Testing Container-to-Container Communication
Now let's test how containers communicate with each other using their assigned IP addresses.
Finding Container IP Addresses
docker inspect web-server-1 | grep IPAddress
This command extracts IP information:
"SecondaryIPAddresses": null,
"IPAddress": "172.17.0.2",
"IPAddress": "172.17.0.2",
Testing Network Connectivity with Ping
docker exec alpine-client ping -c 3 172.17.0.2
The ping test demonstrates successful connectivity:
PING 172.17.0.2 (172.17.0.2): 56 data bytes
64 bytes from 172.17.0.2: seq=0 ttl=64 time=0.135 ms
64 bytes from 172.17.0.2: seq=1 ttl=64 time=0.092 ms
64 bytes from 172.17.0.2: seq=2 ttl=64 time=0.093 ms
--- 172.17.0.2 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 0.092/0.106/0.135 ms
Ping Results Analysis:
Metric | Value | Meaning |
---|---|---|
Packets Transmitted | 3 | All requested packets were sent |
Packets Received | 3 | All packets reached the destination |
Packet Loss | 0% | Perfect connectivity |
Average Latency | 0.106 ms | Very low latency (sub-millisecond) |
Testing HTTP Communication
Let's test HTTP connectivity between containers.
docker exec alpine-client wget -qO- http://172.17.0.2
This successfully retrieves the Nginx welcome page:
<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
<style>
html { color-scheme: light dark; }
body { width: 35em; margin: 0 auto;
font-family: Tahoma, Verdana, Arial, sans-serif; }
</style>
</head>
<body>
<h1>Welcome to nginx!</h1>
<p>If you see this page, the nginx web server is successfully installed and
working. Further configuration is required.</p>
<p>For online documentation and support please refer to
<a href="http://nginx.org/">nginx.org</a>.<br/>
Commercial support is available at
<a href="http://nginx.com/">nginx.com</a>.</p>
<p><em>Thank you for using nginx.</em></p>
</body>
</html>
β Communication Success: The alpine-client container successfully communicated with the nginx web server using HTTP, demonstrating that containers on the same bridge network can communicate freely using IP addresses.
π Key Networking Concepts Demonstrated
Container Communication Patterns
Communication Type | Example | Use Case | Advantages |
---|---|---|---|
IP-based Communication | 172.17.0.2 β 172.17.0.3 | Direct container access | Simple, predictable addressing |
Protocol Testing | Ping for connectivity | Network troubleshooting | Quick connection verification |
Application Testing | HTTP requests | Service validation | End-to-end functionality testing |
Port Exposure | 80/tcp internally available | Service communication | Container-to-container service access |
Network Isolation Characteristics
- Internal Communication: Containers can communicate freely within the same network
- Automatic IP Assignment: Docker handles IP allocation automatically
- MAC Address Generation: Each container gets a unique MAC address
- Port Accessibility: Container ports are accessible from other containers on the same network
- Host Isolation: Containers are isolated from the host network by default
π― Key Takeaways
β Bridge Network Fundamentals
- Default Behavior: Containers automatically join the bridge network when no network is specified
- IP Management: Docker assigns IP addresses sequentially starting from 172.17.0.2
- Communication: Containers on the same network can communicate using IP addresses
- Isolation: The bridge network provides isolation from the host while enabling container communication
- Service Discovery: While IP-based communication works, it's not ideal for dynamic environments
π What's Next?
In Part 2 of this Docker networking series, we'll explore:
- Creating custom bridge networks
- Container name-based communication (DNS resolution)
- Network isolation and security
- Port mapping and host connectivity
- Advanced network management and cleanup
π Excellent Progress! You now understand the fundamentals of Docker bridge networking, including how containers communicate, receive IP addresses, and interact with each other on the default network.
π¬ Discussion
I'd love to hear about your Docker networking experiences:
- What networking challenges have you encountered in containerized applications?
- How do you typically test connectivity between containers?
- Have you worked with more complex multi-container applications?
- What networking patterns work best for your use cases?
Connect with me:
- π GitHub - Docker networking examples and configurations
- π§ Contact - Advanced networking questions and discussions