Understanding Docker Networking: CNM, Libnetwork, and Bridge Networks

Introduction

Containers in a microservices application need to communicate with each other and, often, with external systems. Docker's networking capabilities are built on three components: the Container Network Model (CNM), which is the design specification, libnetwork, which implements it, and drivers, which extend it with specific network topologies.

The Container Network Model

The CNM defines three fundamental building blocks. A sandbox is an isolated network stack inside a container, including interfaces, routing tables, and DNS configuration. Endpoints are virtual network interfaces that connect a sandbox to a network. Networks are virtual switches — typically software implementations of an 802.1d bridge — that group endpoints needing to communicate.

Each container gets its own sandbox with at least one endpoint. A container with two endpoints connected to two different networks can reach both, but the endpoints themselves cannot communicate directly with each other, since each behaves like a standard network adapter tied to a single network.

Libnetwork

Libnetwork is the open-source reference implementation of the CNM, maintained as part of the Moby project. Docker originally implemented networking directly inside the daemon, but eventually extracted it into this standalone library, which also implements the network control plane, including service discovery and ingress load balancing.

Drivers

While libnetwork handles the control plane, drivers implement the data plane — creating networks and ensuring connectivity and isolation. Docker ships with built-in drivers such as bridge, overlay, and macvlan, and third parties can implement additional drivers for more advanced topologies. A single host or Swarm cluster can run multiple networks, each managed by a different driver.

Single-Host Bridge Networks

The simplest Docker network type is the single-host bridge network, created using the built-in bridge driver. Every Docker host automatically gets a default network called bridge, which maps to a Linux bridge called docker0 in the host's kernel. This mapping can be confirmed with:

docker network inspect bridge | grep bridge.name

A custom bridge network can be created with:

docker network create -d bridge localnet

This also creates a corresponding Linux bridge on the host, visible with the brctl show command. Containers attached to the same custom bridge network can resolve each other by name, thanks to Docker's internal DNS resolver — a feature not available on the default bridge network.

External Access via Port Mappings

Containers on the same bridge network can talk to each other directly, but reaching them from outside requires mapping a container's port to a port on the Docker host:

docker run -d --name web --network localnet --publish 5005:80 nginx

Once published, the service becomes reachable through the host's IP address on the mapped port, both from other containers and external clients. While functional, this approach doesn't scale well, since only one process can bind to a given host port at a time — one of the reasons single-host bridge networks are best suited to local development and small applications.

Conclusion

Understanding the CNM, libnetwork, and the role of drivers provides the foundation for working with any Docker network topology. Single-host bridge networks, while simple, illustrate the core mechanics — sandboxes, endpoints, and DNS-based service discovery — that scale up to more advanced network types like overlay and macvlan networks.