Docker Networking

🧠 What is Docker Networking?

In simple terms, Docker networking is how containers communicate with:

• Other containers

• The host machine

• The external internet

• Services running in other environments

Docker abstracts networking infrastructure using virtual networks, giving each container a virtual NIC (vNIC) and a unique IP address, managed by an internal DNS and routing system.

---

🔍 Core Objectives of Docker Networking:

1. Isolation
   Each container can have its own network namespace, offering security and isolation.

2. Connectivity
   Containers can talk to each other via IP, hostname, or DNS—locally or across hosts.

3. Portability
   Docker’s networking model is designed to work across platforms: local machines, VMs, cloud, and Swarm/K8s clusters.

4. Programmability
   You can define custom networks, apply firewall rules, load balancing, and service discovery.

---

🌉 1. Docker Default Bridge Network

When you install Docker, it automatically creates a default bridge network named:

docker network ls
# Output:
# NETWORK ID     NAME      DRIVER    SCOPE
# abcd1234...    bridge    bridge    local

---

⚙️ Technical Architecture: What Happens Under the Hood

🔗 a. Virtual Ethernet (veth) Pair

Each time a container is launched into a bridge network:

• Docker creates a veth pair:

  • One end lives inside the container as eth0

  • The other end connects to the bridge (e.g., br-xxxxx) on the host

🧠 b. Linux Bridge (docker0)

Docker creates a Linux bridge interface called docker0:

ip link show docker0

This acts like a virtual Layer 2 switch on the host. All container veth interfaces plug into this bridge.

🌐 c. IP Allocation

Docker runs an internal DHCP server that:

• Assigns IPs from the 172.17.0.0/16 subnet

• Example: 172.17.0.2, 172.17.0.3, ...

These are private IPs, not accessible from the outside directly.

🔁 d. NAT and IPTables

To allow containers to access the internet:

• Docker sets up IP masquerading (NAT) via iptables rules

• Outbound traffic from the container appears to originate from the host

To expose ports externally, Docker uses iptables DNAT rules.

---

🛜 Container Communication in Default Bridge

✅ Can:

• Containers on the same bridge can talk via IP

• Host ↔ Container via localhost:port (if port is published)

❌ Cannot:

• Containers on different bridges cannot talk

• Containers do not get DNS names unless on user-defined bridge (more on that later)

Example:

docker run -d --name c1 busybox sleep 1000
docker run -d --name c2 busybox sleep 1000

docker exec c1 ping c2
# ping: unknown host (fails — no DNS)

docker exec c1 ping 172.17.0.X
# works if you know the IP

---

🔐 Port Publishing in Bridge Network

When you use -p or --publish:

docker run -d -p 8080:80 nginx

Docker:

• Maps port 8080 on host → container:80

• Creates an iptables DNAT rule

• Allows external traffic to reach your container via localhost:8080

Use ss -tuln or iptables -t nat -L -n to verify.

---

📦 Creating and Using Default Bridge Network

You don’t need to create it—it already exists.

docker network inspect bridge

---

🌉 2. User-Defined Bridge Network

A user-defined bridge network is a Docker network you explicitly create using:

docker network create --driver bridge my_bridge

It uses the same bridge driver as the default bridge network, but with better isolation, built-in DNS-based service discovery, and custom configurability.

---

🔍 Differences from the Default Bridge Network

---

⚙️ How to Create a User-Defined Bridge Network

✅ Simple:

docker network create mynet

✅ With custom subnet and gateway:

docker network create \
  --driver bridge \
  --subnet 192.168.50.0/24 \
  --gateway 192.168.50.1 \
  mynet

Inspect it:

docker network inspect mynet

---

🧪 Container Communication: The Power of DNS

Launch two containers in this network:

docker network create mynet

docker run -dit --name c1 --network mynet busybox
docker run -dit --name c2 --network mynet busybox

Now from c1:

docker exec -it c1 ping c2
# ✅ Success: resolves 'c2' via embedded Docker DNS

📌 This is not possible with the default bridge.

---

🧱 Behind the Scenes

• A Linux bridge device (like br-xxxxx) is created.

• Docker sets up:

  • Custom IPAM (IP Address Management)

  • Built-in DNS service (typically on .11)

  • Isolated veth interfaces

• Each container gets:

  • A unique private IP from the subnet

  • A veth pair connecting container ↔ host bridge

---

🔐 Port Exposure and NAT

Just like default bridge:

docker run -d --name web --network mynet -p 8080:80 nginx

• iptables rules map host 8080 → container 80

• NAT still applies for external traffic

---

🧠 Real-World Use Cases

---

** ✅ Also :

containers on the default bridge network cannot directly communicate with containers on a user-defined bridge network.

✅ Summary of communication of containers within their bridges :

---

🔧 3. Host Network

When you run a container with --network host, the container does not get its own network namespace.

Instead, it shares the host’s network stack directly—same:

• IP address

• Network interfaces

• Open ports

• Routing table

• DNS resolution

No virtual NIC, no bridge, no NAT—pure host-level access.

---

📜 How to Use It

docker run --rm -it --network host nginx

Inside the container:

ip a                                    # You’ll see host's interfaces like eth0, lo, etc.

hostname -I                              # Same IP as host

---

🔍 What Actually Happens?

Normally (bridge):

• Docker creates a container with its own network namespace

• Isolated interfaces, IP, and NAT

With --network host:

• Container shares PID 1’s (host’s) network namespace

• No veth pair

• No Docker bridge

• No IPTables NAT

This reduces overhead but removes isolation.

---

🧠 Implications of host Networking

---

⚠️ Behavior Differences from Bridge and Host Networks

---

📦 Use Case Example

Run NGINX in host mode:

docker run --rm --network host nginx

If NGINX listens on port 80, it binds directly to host port 80.

You can verify using:

ss -tuln | grep :80

Or curl from another machine using the host IP.

---

🔐 Security Considerations

• Zero network isolation from host: container can sniff or interfere with all traffic

• Should never be used for untrusted containers