Bridge network default behavior in Docker - Step-by-Step Execution

Process Flow - Bridge network default behavior

Docker daemon starts

↓

Create default bridge network

↓

Container connects to bridge

↓

Assign container IP from bridge subnet

↓

Enable container communication via bridge

↓

Enable NAT for external access

↓

Container can communicate internally and externally

Docker creates a default bridge network at startup. Containers connected to it get IPs and can talk to each other and outside via NAT.

Execution Sample

Docker

docker network ls
docker run -d --name c1 nginx
docker inspect c1
ping <container_ip>

List networks, run a container on default bridge, inspect IP, and ping to test connectivity.

Process Table

Step	Action	Result	Network State
1	Docker daemon starts	Default bridge network 'bridge' created	bridge network exists with subnet 172.17.0.0/16
2	Run container c1 without network option	Container connected to default bridge	c1 assigned IP 172.17.0.2
3	Inspect container c1	Shows IP 172.17.0.2 and bridge network	bridge network has 1 container connected
4	Run container c2	Connected to default bridge	c2 assigned IP 172.17.0.3
5	Ping c2 from c1	Ping successful	Containers communicate internally via bridge
6	Container c1 accesses internet	Access allowed via NAT	Bridge network performs NAT for outbound traffic
7	Stop container c1	Container removed from bridge	bridge network has 1 container connected
8	Remove container c2	No containers connected	bridge network empty
9	Exit	No more containers connected	bridge network remains available

💡 No more containers connected, default bridge network remains active for future use

Status Tracker

Variable	Start	After Step 2	After Step 4	After Step 7	After Step 8
bridge network	Created with subnet 172.17.0.0/16	1 container connected (c1)	2 containers connected (c1, c2)	1 container connected (c2)	0 containers connected

Key Moments - 3 Insights

Why does the container get an IP address automatically?

Because the container connects to the default bridge network which assigns IPs from its subnet automatically, as shown in execution_table step 2 and 4.

Can containers on the default bridge communicate with each other?

Yes, containers connected to the default bridge can communicate internally, demonstrated by the successful ping in step 5.

How does a container access the internet if connected to the default bridge?

The default bridge network uses NAT (Network Address Translation) to allow containers to access external networks, shown in step 6.

Visual Quiz - 3 Questions

Look at the execution table, what IP address is assigned to container c1 after step 2?

A 172.17.0.2

B 172.17.0.3

C 192.168.1.2

D 10.0.0.2

💡 Hint

Check the 'Result' column in row for step 2 in the execution_table.

At which step do containers first communicate with each other?

A Step 3

B Step 5

C Step 6

D Step 4

💡 Hint

Look for the 'Ping successful' action in the execution_table.

If container c1 is removed, how many containers remain connected to the bridge network?

A 0

B 2

C 1

D None, network is deleted

💡 Hint

Check the 'Network State' column after step 7 in the execution_table.

Concept Snapshot

Docker default bridge network:
- Created automatically at Docker start
- Assigns IPs to containers from 172.17.0.0/16
- Enables container-to-container communication
- Provides NAT for internet access
- Network persists even if no containers connected

Full Transcript

When Docker starts, it creates a default bridge network named 'bridge'. Containers run without specifying a network connect to this bridge automatically. Each container gets an IP address from the bridge subnet, typically 172.17.0.x. Containers connected to this bridge can communicate with each other directly. The bridge network also provides NAT so containers can access the internet. Even if all containers stop or are removed, the default bridge network remains available for future containers.

Practice

1. What is the default behavior of Docker's bridge network regarding container communication?

easy

A. Containers can communicate by container name without extra setup.

B. Containers cannot communicate with each other at all.

C. Containers can communicate with each other by IP address only.

D. Containers share the host network directly.

Solution

1. Step 1: Understand bridge network basics

   The default bridge network connects containers on the same Docker host and allows communication by IP address.

2. Step 2: Analyze name resolution behavior

   By default, containers on the bridge network cannot resolve each other's names without a custom network.

3. Final Answer:

   Containers can communicate with each other by IP address only. -> Option C

4. Quick Check:

   Bridge network communication = IP only [OK]

Hint: Default bridge allows IP communication, not name resolution [OK]

Common Mistakes:

• Assuming container names resolve by default
• Thinking containers share host network directly
• Believing containers cannot communicate at all

2. Which Docker command shows the default bridge network details?

easy

A. docker info bridge

B. docker network ls

C. docker container ls

D. docker network inspect bridge

Solution

1. Step 1: Identify command to inspect networks

   To see details of a specific network, use docker network inspect <network-name>.

2. Step 2: Apply to default bridge network

   The default bridge network is named "bridge", so the command is docker network inspect bridge.

3. Final Answer:

   docker network inspect bridge -> Option D

4. Quick Check:

   Inspect bridge network = docker network inspect bridge [OK]

Hint: Inspect networks with 'docker network inspect <name>' [OK]

Common Mistakes:

• Using 'docker container ls' to see networks
• Trying 'docker info bridge' which is invalid
• Confusing 'docker network ls' with inspect

3. Given two containers on the default bridge network, what happens if you try to ping one container by its name from the other?

medium

A. Ping fails because default bridge does not support container name resolution.

B. Ping fails unless containers are on a custom network.

C. Ping succeeds only if containers share the same image.

D. Ping succeeds because default bridge supports name resolution.

Solution

1. Step 1: Recall default bridge network name resolution

   The default bridge network does not provide automatic DNS resolution for container names.

2. Step 2: Understand ping behavior by name

   Trying to ping by container name will fail because the name cannot be resolved to an IP address.

3. Final Answer:

   Ping fails because default bridge does not support container name resolution. -> Option A

4. Quick Check:

   Default bridge name resolution = no [OK]

Hint: Default bridge lacks DNS for container names [OK]

Common Mistakes:

• Assuming ping by name works by default
• Confusing image sharing with network name resolution
• Thinking custom networks are not needed

4. You created two containers on the default bridge network and tried to connect them by name, but it failed. What is the likely cause?

medium

A. The containers are not running.

B. You forgot to create a user-defined bridge network.

C. The Docker daemon is not started.

D. You used the wrong container names.

Solution

1. Step 1: Understand default bridge limitations

   Default bridge network does not support container name resolution for communication.

2. Step 2: Identify solution for name-based communication

   Creating a user-defined bridge network enables automatic DNS resolution of container names.

3. Final Answer:

   You forgot to create a user-defined bridge network. -> Option B

4. Quick Check:

   Name resolution needs user-defined bridge [OK]

Hint: Use user-defined bridge for name resolution [OK]

Common Mistakes:

• Blaming container state without checking network
• Assuming Docker daemon is stopped without evidence
• Ignoring network type for name resolution

5. You want two containers to communicate by name and also access the internet. Which approach using Docker's networking should you take?

hard

A. Connect both containers to a user-defined bridge network which supports name resolution and NAT for internet access.

B. Use the default bridge network and manually edit /etc/hosts in each container.

C. Connect containers to the host network to share internet and name resolution.

D. Create a macvlan network to enable name resolution and internet access.

Solution

1. Step 1: Identify network supporting name resolution and NAT

   User-defined bridge networks provide automatic DNS for container names and NAT for internet access.

2. Step 2: Evaluate other options

   Default bridge lacks name resolution; host network shares host IP but no DNS; macvlan isolates containers and does not provide NAT by default.

3. Final Answer:

   Connect both containers to a user-defined bridge network which supports name resolution and NAT for internet access. -> Option A

4. Quick Check:

   User-defined bridge = name resolution + NAT [OK]

Hint: User-defined bridge = name resolution + internet [OK]

Common Mistakes:

• Editing /etc/hosts manually is error-prone
• Assuming host network provides container DNS
• Using macvlan without NAT causes no internet