Docker Bridge Network Hands-On: Container Communication & Isolation Explained

This comprehensive study note explores Docker networking fundamentals, focusing specifically on the Bridge Network driver. You will learn how Docker manages container communication, how default bridge networks differ from custom user-defined bridge networks, and how network segmentation provides application isolation.

1. Why Do We Need Docker Networking?

By default, Docker containers are isolated entities running in their own namespaces. However, real-world applications rarely exist in isolation; a web server container must communicate with a database container, or a caching layer needs to talk to an API service.

• Inter-Container Communication: Networking allows discrete containers running on the same host or cluster to talk to each other securely and reliably.
• Application Isolation: Network segmentation ensures that unrelated services or multi-tenant applications cannot access each other's traffic unless explicitly permitted.
• External Connectivity: Containers need pathways to initiate outbound connections to the internet (e.g., downloading packages or querying external APIs) while remaining protected from uninvited inbound traffic.

2. Core Mental Model: The Virtual Switch and Network Rooms

To understand Docker networking, imagine a physical office building (the Docker Host / VM):

Real-Life Analogy:

• The Default Bridge Network is like the building's main lobby or open-floor office where everyone shares the same open space and can talk directly to one another using desk phone extensions (IP addresses).
• Custom Bridge Networks (new net) are like locked departmental rooms (HR, Engineering). People inside the Engineering room can talk freely to each other, but someone sitting in Engineering cannot talk directly to someone in HR, even though both rooms are inside the same building.

3. Overview of Docker Bridge Network Characteristics

The bridge network driver is the default networking mode when you install and run Docker. Key technical characteristics include:

• Automatic Subnet Assignment: Docker automatically assigns a private CIDR block (subnet) to every bridge network.
• Intra-Network Communication: Containers attached to the exact same bridge network can communicate with each other freely.
• Outbound Internet Access: Containers can initiate outbound traffic to the internet (e.g., pinging google.com), leveraging Network Address Translation (NAT) configured on the Docker host.
• Inbound Traffic Blocked by Default: External traffic from the internet cannot reach containers on a bridge network unless explicit port mapping (-p flag) is configured.
• Strict Network Isolation: Containers on different bridge networks cannot communicate with one another by default, providing vital security segmentation.

4. Inspecting the Default Docker Environment

Before launching containers, we must inspect the pre-existing network drivers on the host system.

Listing Docker Networks

Run the following command to view all available network drivers on your Docker host:

docker network ls

Output Structure:

NETWORK ID     NAME      DRIVER    SCOPE
123456789abc   bridge    bridge    local
fedcba987654   host      host      local
0123456789ab   none      null      local

Inspecting the Default Bridge Network

To inspect the internal configuration, subnet, and active containers attached to the default bridge network:

docker network inspect bridge

At this initial stage, the "Containers" JSON block is empty ({}), meaning zero containers are currently utilizing the default bridge.

5. Phase 1: Default Bridge Network Hands-On & Communication

We will pull a CentOS 8 image and launch two containers (container1 and container2) inside the default bridge network to test bi-directional communication.

Step 1: Pull the CentOS 8 Image

docker pull centos:8
docker images

Step 2: Launch Container 1 and Container 2

Launch two interactive detached containers using the CentOS image:

docker run -itd --name container1 centos:8
docker run -itd --name container2 centos:8

Verify they are running:

docker ps

Step 3: Extract Container IP Addresses

To ping containers directly, we retrieve their internal IP addresses assigned by the default bridge driver:

# Get IP for container 1
docker inspect container1 | grep -iA 4 "IPAddress"

# Get IP for container 2
docker inspect container2 | grep -iA 4 "IPAddress"

(Assume container1 gets 172.17.0.2 and container2 gets 172.17.0.3).

Step 4: Testing Inter-Container Communication

Enter container1 via an interactive shell:

docker exec -it container1 /bin/bash

Inside container1, verify outbound internet connectivity:

ping -c 3 google.com

Result: Successful response. Containers can reach the outside world.

Next, ping container2 using its internal bridge IP address:

ping -c 3 172.17.0.3

Result: Successful communication with zero packet loss because both reside on the default bridge network.

Exit container1:

exit

Repeat the reverse verification by entering container2 and pinging container1:

docker exec -it container2 /bin/bash
ping -c 3 172.17.0.2
exit

Result: Communication flows successfully in both directions.

6. Phase 2: Creating a Custom Bridge Network (new net)

To achieve security isolation, we will create a dedicated user-defined bridge network named new net.

Step 1: Create the Custom Network

Execute the network creation command specifying the bridge driver:

docker network create --driver bridge new net

(Note: In the transcript command, it is typed as new net).

Verify the new network is created:

docker network ls

Step 2: Inspect the Custom Network

docker network inspect new net

Notice that the subnet CIDR block assigned to new net (e.g., 172.18.0.0/16) differs from the default bridge subnet (172.17.0.0/16).

7. Phase 3: Testing Isolation Across Different Networks

We will launch container3 attached explicitly to new net and test communication boundaries.

Step 1: Launch Container 3 in new net

docker run -itd --name container3 --network new net centos:8

Step 2: Test Cross-Network Communication Failure (Isolation Test)

Let's verify if container2 (on the default bridge network) can ping container3 (on new net).

1. Retrieve container3's IP address (172.18.0.2).
2. Enter container2:

docker exec -it container2 /bin/bash

3. Attempt to ping container3:

ping -c 3 172.18.0.2

• Result: 100% packet loss.
• Why?: Even though both are bridge networks, Docker enforces network segmentation and routing isolation between distinct user-defined and default bridge networks.

Exit container2:

exit

8. Phase 4: Intra-Network Communication in Custom Networks

To prove that containers within the same custom network can talk to each other, we will launch a fourth container (container4) inside new net.

Step 1: Launch Container 4

docker run -itd --name container4 --network new net centos:8

Step 2: Verify Network Membership

Inspect new net to confirm both container3 and container4 are attached:

docker network inspect new net

Step 3: Test Communication Between Container 3 and Container 4

Enter container4 and ping container3:

docker exec -it container4 /bin/bash
ping -c 3 172.18.0.2  # IP of container 3

• Result: Packets transmit successfully with 0% packet loss because both containers share the exact same custom bridge network (new net).

Exit container4:

exit

9. Summary Comparison of Network Behavior

10. Summary and Key Takeaways

• Default vs. Custom Bridges: Docker comes with a default bridge network, but best practices dictate creating custom user-defined bridge networks (docker network create) for production workloads.
• Network Interface Cards (NICs): Containers do not possess independent physical NICs; instead, they utilize virtual interfaces tethered to the Docker host's networking stack.
• Namespace-Driven Isolation: Network isolation is achieved through Linux kernel namespaces and routing rules, not through physical hardware separation.
• Default Interoperability: Containers attached to the same bridge network can communicate freely with one another by default.
• Microservice Segmentation: Custom bridge networks allow DevOps engineers to isolate microservices (e.g., placing frontend apps and backend databases on separate networks for enhanced security).
• Outbound NAT: Containers can seamlessly initiate outbound traffic to the public internet (e.g., google.com), while remaining shielded from inbound unsolicited requests.