Docker Networking Demystified Part 2: Single Host Bridge Networks.

If you read Part 1, you should have atleast a basic idea of the Container Networking Model (CNM), the Docker Network CLI and the underlying default connectivity architecture for containers.

Single Host Bridge Networks: What they are and what they do.

The name in itself gives us an indication about what Single Host Bridge Networks might look like.

Bridge networks are the default topology for Docker containers. Infact, after installing the Docker runtime engine, one can check the types of topologies that are available out of the box:

The Scope being local means that ONLY those containers that are connected to the same Bridge Network may speak with each other.

Demo: Only containers on the same Bridge Network can talk to each other.

Let's run 2 containers on the default Bridge network (w/ id 14374b050e0c).

Since we didn't specifically name a network for the containers to join, Docker will assume we are intending to use the out of the box Bridge container. This is confirmed through the following docker network inspect command:

To confirm our hypothesis about containers on same Bridge Network being able to speak to each other, we can run the following commands:

Visually, the network layout will resemble something that looks as follows:

Since Mickey and Minnie are on the same Bridge network, they should be able to send simple ICMP messages to each other (and they will as shown below):

Additionally, if we inspect Mickey (or Minnie), we will notice it has an VETH interface (which it MUST have as per the CNM specs):

Demo: Containers on seperate Bridge Networks cannot talk to each other.

Let's create user-defined Bridge Network and call it The-Other.

Add a container (call it Pete) to The-Other Bridge Network.

Lets a take quick peek inside Pete:

Even though both the Bridge networks are on the same underlying OS networking stack, they will not be able to communicate. For instance, Pete will not be able to connect to Minnie:

Notice the text in red which tells us that no packets were successfully sent or received and there was, therefore, a 100% loss of data packets. This is because (and no drum rolls necessary) Pete and Minnie are on seperate Bridge networks and are theoretically not on speaking terms.

Can we make Pete and Minnie talk to each other using some modification in the Bridge networks?

Yes! This process is called Dual-Hosting (which means a container can be attached to multiple bridge type networks).

Before we go ahead, lets confirm the container and network layout visually:

Since we know that for containers to talk using Bridge networks, they should be on the same one. We also know that Pete and Minnie are on seperate networks. Therefore, the simple logical conclusion is that if we were able to get either Pete or Minnie (or both) to connect to the other network AS WELL, they should be able to ping each other.

Assuming we want to enable Pete and Minnie's conversation, the following commands will connect Pete to the default Bridge network:

Now if we check Pete's IP addresses, we will see it has not one but TWO VETH interfaces:

Since Pete is now on both networks, it will be able to ping Minnie and Mickey (using their IPs) and Sylvester using either its IP or name.

In Part 3, we will explore Multi-Host Overlay Networks.

Container on !

I write to remember and if in the process, I can help someone learn about Containers, Orchestration (Docker Compose, Kubernetes), GitOps, DevSecOps, VR/AR, Architecture, and Data Management, that is just icing on the cake.