Skip to main content
Welcome to this comprehensive lesson on Docker networking. In this guide, we explore the various networking options available in Docker and how they relate to network namespaces. We’ll begin by focusing on a single Docker host— a server with Docker installed. Assume the host has an Ethernet interface (eth0) with the IP address 192.168.1.10 on the local network.

​
Docker Networking Modes

When you run a container, Docker provides several networking modes to tailor connectivity to your application’s needs:

​
None Network

With the “none” network mode, the container is not attached to any network. As a result, it cannot communicate with external systems, nor can external systems reach the container. For example:
Multiple containers started in the none network mode remain completely isolated from each other and the external network.

​
Host Network

In the host network mode, the container shares its host’s network stack. This means there is no network isolation between the host and the container. For instance, if a web application inside the container listens on port 80, that application immediately becomes accessible on port 80 of the host. However, running a second container that also attempts to bind to the same port will result in a failure because two processes cannot share the same port on the host. For example:

​
Bridge Network

The default Docker networking mode is the bridge network. When Docker is installed, it automatically creates an internal private network called “bridge” (visible as “docker0” on the host) with a default subnet (usually 172.17.0.0/16). Each container connected to this network receives a unique IP address from this subnet. For example, running two containers:
These containers communicate with each other over the internal bridge network. To inspect the list of available networks, use:
An example output might look like:
Internally, Docker creates the “docker0” interface on the host, serving as the bridge between host and containers. Although the command output names it “bridge,” it is implemented as the “docker0” interface. Verify this by running:
By default, the “docker0” interface is assigned the IP address 172.17.0.1. When a container is launched, Docker creates a new network namespace for it (similar to those discussed in earlier lessons). To list the available network namespaces (a minor hack may be required to display Docker-created namespaces):
Typically, the namespace will have a name starting with an identifier like b3165.... To view the network namespace details associated with a container, inspect the container details with:
A snippet of the output under “NetworkSettings” might appear as follows:

​
Container Attachment to the Bridge Network

Docker attaches each container to the bridge network by creating a pair of virtual interfaces—essentially a virtual cable with an interface at each end. One interface is connected to the host’s “docker0” bridge, and the other interface is placed inside the container’s network namespace. Inspect the interfaces on the Docker host using:
You might see an output similar to:
To inspect the network namespace of a container (for example, with namespace ID b3165c10a92b), run:
The output might be similar to:
To view the IP address assigned to the container’s network interface:
This may display:
Each time a new container is created, Docker follows these sequential steps:
  1. Creates a new network namespace.
  2. Establishes a pair of virtual interfaces.
  3. Attaches one end to the container’s namespace and the other to the “docker0” bridge.
  4. Assigns an IP address to the container’s interface.
The virtual interface pairs are numbered consistently, with odd and even numbers forming a pair (e.g., 7 and 8, 9 and 10).

​
Port Mapping

Consider a scenario where a container runs an nginx web application that listens on port 80. By default, since the container runs in a private network segment, only other containers on the same network or the host can access application endpoints. Port mapping (port publishing) in Docker enables external access by mapping a port on the host to a port on the container. For example, to map port 8080 on the host to port 80 within the container:
After setting up port mapping, you can test connectivity as follows:
  • Accessing the container directly via its IP on port 80 might result in a failure:
  • However, accessing the application using the host’s IP and port 8080 should succeed:
All incoming traffic to port 8080 on the Docker host is forwarded to port 80 in the container.

​
How Port Forwarding Works

Docker employs IP tables to implement port forwarding. This mechanism adds a Network Address Translation (NAT) rule to translate traffic arriving on a specific host port to the corresponding container port. For example, Docker might add a rule similar to the following:
This rule directs traffic arriving at port 8080 on the host to port 80 on the container. You can review the active NAT table rules by running:
An excerpt from the output might resemble:
After the mapping is configured, testing access to the container using:
should return a response like:

​
Conclusion

In summary, Docker networking offers multiple modes—none, host, and bridge—to manage connectivity for containers. The default bridge network uses a virtual switch (docker0) to connect containers via dedicated network namespaces, while port mapping enables external access by forwarding traffic from a designated host port to the container’s port.
For a deeper dive into container networking, consider exploring the Kubernetes Networking Basics and other resources in the Docker Documentation.
Happy learning!

Watch Video