Linux bridge — switch L2 ảo (docker0)

TL;DR: Linux bridge là switch L2 ảo trong kernel: nhiều netdev (veth, tap, eth) gắn làm port, frame được forward theo MAC — không “route” IP giữa port. Tạo bằng ip link add … type bridge, gắn port bằng ip link set <dev> master <br>, học MAC vào FDB (Forwarding Database). docker0 chính là bridge mặc định của Docker: mỗi container một veth, đầu host là port trên docker0. Pitfall hay gặp: bridge thiếu IP (container mất gateway), port/ip_forward off, hoặc quên up cả veth lẫn bridge.

Staging: hai container cùng bridge network, ping chéo timeout. Junior đã kiểm tra IP trong netns — đúng subnet 172.17.0.0/16. Bạn hỏi: “đầu host của veth đã master docker0 và UP chưa? FDB có MAC peer chưa?” Một đầu veth còn dangling (không master), bridge không học được đường L2. ip link set … master docker0 + up → ARP/ping sống. Không phải DNS, không phải app — cổng switch ảo chưa cắm.

Bài 02 — Virtual network devices đã cho cáp (veth). Bài này cho switch gắn nhiều cáp thành một LAN ảo — đúng mảnh Docker gọi “bridge network”. Stack softirq/sk_buff bài 01 vẫn chạy; bridge thêm bước L2 forward giữa port trước khi gói lên IP/local hay ra netfilter FORWARD (bài 04).

Bài này implement bridge + veth và quan sát MAC learning, fade: lab gắn port 1 đủ bước → bạn tự gắn port 2 trước khi xem lời giải.

1. Analogy — Switch rack, bảng MAC, và cổng docker0

Hình dung một switch Ethernet trong rack lab:

1. Nhiều cổng (port) — cắm cáp từ máy A, máy B, máy C.
2. Switch học MAC: “máy A gắn cổng 3” sau khi thấy frame từ A vào cổng 3.
3. Frame tới MAC đã học → chỉ ra đúng cổng; broadcast/unknown → flood các cổng còn lại (trừ cổng vào).
4. Switch không “route” theo IP giữa các cổng cùng VLAN/LAN — nó sống ở L2.

2. Bridge là gì — vì sao gọi là switch L2?

Linux bridge (kernel bridge module / netdev type bridge) gom nhiều interface thành một miền broadcast L2. Kernel:

• Nhận Ethernet frame trên một port.
• Tra FDB theo MAC đích.
• Forward frame ra port đúng (hoặc flood nếu chưa biết / broadcast).
• Có thể đồng thời coi bridge như một netdev trên host: gán IP cho br0/docker0 để host làm gateway L3 của LAN ảo.

Bridge ≠ router (và ≠ veth)

Hai container trên cùng docker0 ping nhau chủ yếu là path L2 qua bridge (veth → bridge → veth). Container ra Internet thêm bước L3: default route tới IP trên docker0, rồi host forward + NAT — netfilter (bài 04), không phải “bridge tự route WAN”.

flowchart TB
    C1["Container eth0"] -->|"veth peer"| H1["Host veth port"]
    C2["Container eth0"] -->|"veth peer"| H2["Host veth port"]
    H1 --> BR["bridge docker0 / br0"]
    H2 --> BR
    BR -->|"optional IP gateway"| HOST["Host IP stack"]
    HOST -->|"forward + NAT later"| WAN["Outside"]

Vì sao container cần bridge thay vì chỉ một veth pair?

Một veth pair chỉ nối hai đầu. Ba container cần “cùng LAN” → hoặc mesh nhiều pair (không scale), hoặc một switch nhiều port. Bridge = mô hình switch: N veth host-side làm N port, mỗi container một cáp.

3. Tạo bridge và gắn veth — lab fade

Chạy trên Linux (VM/WSL2/host), thường cần sudo. Lab cùng netns (đơn giản hoá): hai “đầu máy” là hai veth peer; hai đầu host-side gắn br0. (Production: peer nằm netns container — cùng cơ chế master/FDB; netns đầy đủ ở module sau.)

3.1 Worked — tạo bridge + pair 1 + gắn port 1

# 1) Create a bridge (virtual L2 switch)
sudo ip link add name br0 type bridge
sudo ip link set br0 up

# 2) Create first veth pair: host-side port + "endpoint" side
sudo ip link add veth-h1 type veth peer name veth-e1

# 3) Attach ONLY the host-side end as a bridge port (worked step)
sudo ip link set veth-h1 master br0
sudo ip link set veth-h1 up
sudo ip link set veth-e1 up

# 4) Give the endpoint an IP (host is not on this IP yet)
sudo ip addr add 10.30.0.11/24 dev veth-e1

# 5) Bridge often needs an IP if it is the gateway for the LAN
sudo ip addr add 10.30.0.1/24 dev br0

# Inspect: veth-h1 should show master br0
ip link show veth-h1
ip link show br0

Bạn đã có: switch br0, một port (veth-h1), một endpoint veth-e1 với IP 10.30.0.11. Endpoint thứ hai chưa có — chưa ping được “máy” khác trên cùng bridge.

3.2 Lời giải — gắn interface 2

# Create second pair
sudo ip link add veth-h2 type veth peer name veth-e2

# Host-side -> bridge port (this is the step most people skip)
sudo ip link set veth-h2 master br0
sudo ip link set veth-h2 up
sudo ip link set veth-e2 up

# Endpoint IP on the "other machine"
sudo ip addr add 10.30.0.12/24 dev veth-e2

# L2 via bridge: e1 <-> br0 <-> e2
ping -c 2 -I veth-e1 10.30.0.12
# or: ping -c 2 10.30.0.12  if routing/src selection already prefers veth-e1

# Optional cleanup
# sudo ip link del veth-h1
# sudo ip link del veth-h2
# sudo ip link del br0

Cơ chế: frame từ veth-e1 → peer veth-h1 (port) → bridge học/flood → ra veth-h2 → peer veth-e2. Không cần route giữa .11 và .12 nếu cùng /24 và ARP resolve qua bridge. Nếu ping fail: kiểm tra cả hai host-side có master br0, cả bridge + bốn đầu veth UP, IP đúng iface.

flowchart LR
    E1["veth-e1 .11"] -->|"pair"| H1["veth-h1 port"]
    E2["veth-e2 .12"] -->|"pair"| H2["veth-h2 port"]
    H1 --> BR0["br0"]
    H2 --> BR0

4. FDB — bridge học MAC thế nào?

FDB (Forwarding Database) là bảng MAC → port của bridge — tương đương bảng MAC trên switch vật lý.

1. Frame vào port P với MAC nguồn S → bridge học: “S nằm sau port P” (dynamic entry, có ageing timeout).
2. Frame có MAC đích D:
   • D đã học → forward chỉ ra port đã ghi;
   • D là broadcast/multicast hoặc unknown → flood các port khác (trừ port vào).
3. Sau vài ARP/ping hai chiều, FDB thường có MAC của cả hai endpoint (và có thể MAC của bridge/host nếu host gửi từ br0).

Quan sát FDB

# Show FDB entries (needs bridge utility from iproute2)
bridge fdb show br br0
# Older alias style still seen in docs:
# bridge fdb show | grep br0

# After ping between .11 and .12, look for dynamic entries
# pointing at veth-h1 / veth-h2 (or the port ifnames you used)

Kết quả kỳ vọng (mechanism): traffic hai chiều thường để lại ít nhất MAC của hai endpoint (và có thể thêm MAC host/bridge). Unknown unicast trước khi học → flood; sau khi học → unicast đúng port — đó là lý do switch scale hơn hub thuần tuý.

Liên hệ bài 01: frame trên port bridge vẫn đi softirq/sk_buff path; bridge code quyết định port egress ở L2. Gói tới IP của host trên br0 có thể local-deliver; gói giữa hai port là bridge forward L2; gói container → WAN sau đó mới là IP forward + netfilter.

5. docker0 — bridge mặc định Docker

Khi Docker dùng bridge network mặc định, daemon tạo (hoặc dùng) netdev docker0:

• Type bridge — đúng object bài này, không phải “DNS magic”.
• IP host điển hình 172.17.0.1/16 (subnet mặc định có thể đổi theo config daemon).
• Mỗi container: veth pair — eth0 trong netns container; đầu host tên dạng veth… với master docker0.
• Container-to-container cùng network: L2 qua docker0.
• Container ra ngoài: route default → 172.17.0.1, host ip_forward + rule NAT/filter (bài 04).

# On a host with Docker engine running (illustrative)
ip link show docker0
ip addr show docker0
bridge fdb show br docker0 | head
# ip link show master docker0   # list ports enslaved to docker0

CNI / user-defined bridge network có thể tạo bridge khác tên (br-…) — cùng pattern: bridge + veth port + FDB + IP gateway trên bridge. Học br0 lab = đọc được docker0 production.

6. Pitfall tổng hợp

❌ Nhầm 1: “Gán IP hai đầu veth là đủ — không cần master bridge.”
✅ Hai endpoint cùng pair thì nói chuyện point-to-point không qua bridge. Muốn nhiều endpoint cùng LAN như Docker → mỗi host-side phải master <bridge>. Quên master = cáp cắm vào… không đâu.

❌ Nhầm 2: “Bridge chỉ cần tồn tại; IP trên br0/docker0 là optional luôn.”
✅ Container-to-container thuần L2 có thể không cần IP host. Nhưng path default gateway ra host/WAN cần IP trên bridge (vd 172.17.0.1). Bridge thiếu IP → “ping nhau được, ra Internet không” hoặc ARP gateway fail.

❌ Nhầm 3: “Ping container ra ngoài fail = chắc bridge hỏng.”
✅ Ra ngoài cần IP forward (net.ipv4.ip_forward=1) + netfilter NAT/FORWARD. Bridge UP và FDB đẹp vẫn fail WAN nếu forward/NAT off — tách L2 LAN vs L3 egress.

❌ Nhầm 4: “brctl là cách duy nhất / hiện đại.”
✅ brctl (bridge-utils) là legacy. Chuẩn hiện tại: ip link … type bridge + bridge (iproute2) cho FDB/vlan. Docker cũng bám netlink hiện đại.

📚 Deep Dive — man page & kernel

Liên hệ các bài khác

• 00 — Tổng quan module — mảnh 3: switch ảo sau cáp veth.
• 01 — Linux network stack — softirq/sk_buff/netfilter sau khi frame đã vào netdev (gồm port bridge).
• 02 — Virtual network devices — veth pair = cáp; bài này gắn đầu host vào bridge.
• 04 — iptables và netfilter — FORWARD/NAT khi traffic đã qua veth + bridge ra ngoài host.
• Networking Foundations — từ URL tới response — path end-to-end; bài này là switch L2 trên một hop Linux.

Tóm tắt

• Linux bridge = switch L2 trong kernel: nhiều port, forward theo MAC/FDB.
• Tạo: ip link add name br0 type bridge + up; gắn port: ip link set <dev> master br0.
• veth: endpoint (container) ↔ host-side port trên bridge — mô hình Docker bridge.
• FDB học MAC từ traffic; bridge fdb show để chứng minh path L2.
• docker0 = bridge mặc định + IP gateway host; cùng pattern với br0 lab.
• Pitfall: quên master, port DOWN, bridge thiếu IP, ip_forward off khi cần egress — checklist L2 rồi mới netfilter.
• Fade lab: port 1 worked → tự gắn port 2 → đối chiếu lời giải + ping + FDB.

7. Tự kiểm tra

Bài tiếp theo: iptables và netfilter — tables, chains, Docker map