Bridge Network Driver in Docker

--- title: Bridge network driver description: All about using user-defined bridge networks and the default bridge keywords: network, bridge, user-defined, standalone aliases: - /config/containers/bridges/ - /engine/userguide/networking/default_network/build-bridges/ - /engine/userguide/networking/default_network/custom-docker0/ - /engine/userguide/networking/work-with-networks/ - /network/bridge/ - /network/drivers/bridge/ --- In terms of networking, a bridge network is a Link Layer device which forwards traffic between network segments. A bridge can be a hardware device or a software device running within a host machine's kernel. In terms of Docker, a bridge network uses a software bridge which lets containers connected to the same bridge network communicate, while providing isolation from containers that aren't connected to that bridge network. The Docker bridge driver automatically installs rules in the host machine so that containers on different bridge networks can't communicate directly with each other. Bridge networks apply to containers running on the same Docker daemon host. For communication among containers running on different Docker daemon hosts, you can either manage routing at the OS level, or you can use an [overlay network](overlay.md). When you start Docker, a [default bridge network](#use-the-default-bridge-network) (also called `bridge`) is created automatically, and newly-started containers connect to it unless otherwise specified. You can also create user-defined custom bridge networks. **User-defined bridge networks are superior to the default `bridge` network.** ## Differences between user-defined bridges and the default bridge - **User-defined bridges provide automatic DNS resolution between containers**. Containers on the default bridge network can only access each other by IP addresses, unless you use the [`--link` option](../links.md), which is considered legacy. On a user-defined bridge network, containers can resolve each other by name or alias. Imagine an application with a web front-end and a database back-end. If you call your containers `web` and `db`, the web container can connect to the db container at `db`, no matter which Docker host the application stack is running on. If you run the same application stack on the default bridge network, you need to manually create links between the containers (using the legacy `--link` flag). These links need to be created in both directions, so you can see this gets complex with more than two containers which need to communicate. Alternatively, you can manipulate the `/etc/hosts` files within the containers, but this creates problems that are difficult to debug. - **User-defined bridges provide better isolation**. All containers without a `--network` specified, are attached to the default bridge network. This can be a risk, as unrelated stacks/services/containers are then able to communicate. Using a user-defined network provides a scoped network in which only containers attached to that network are able to communicate. - **Containers can be attached and detached from user-defined networks on the fly**. During a container's lifetime, you can connect or disconnect it from user-defined networks on the fly. To remove a container from the default bridge network, you need to stop the container and recreate it with different network options. - **Each user-defined network creates a configurable bridge**. If your containers use the default bridge network, you can configure it, but all the containers use the same settings, such as MTU and `iptables` rules. In addition, configuring the default bridge network happens outside of Docker itself, and requires a restart of Docker. User-defined bridge networks are created and configured using `docker network create`. If different groups of applications have different network requirements, you can configure each user-defined bridge separately, as you create it.

This section explains bridge networks in Docker, highlighting that they are Link Layer devices forwarding traffic between network segments. Docker uses a software bridge for container communication and isolation. User-defined bridge networks offer superior features like automatic DNS resolution, better isolation, dynamic attachment/detachment, and configurable bridges compared to the default bridge network. The default bridge network is automatically created but has limitations.