在容器网络里，veth 的"对端"十有八九不是一个命名空间，而是一个 Linux bridge——换句话说，那根软件网线的另一端，插在了一台"软件交换机"上。
这篇文章就把这台交换机拆开。重点不在"怎么用 brctl/ip link"，而在内核里 net/bridge/ 这套代码到底怎么让一个以太帧从端口 A 走到端口 B，又怎么决定哪些帧要上送 CPU、哪些要洪泛。读完你应该能回答一个很具体的问题：为什么容器 A ping 容器 B，包根本没进宿主的 IP 协议栈，却照样通了？
本文基于主线内核 net/bridge/ 实现（5.x 系），个别函数签名与早期 3.x 略有差异，关键路径一致。
一、Bridge 不是网卡，是内核里的二层交换机
很多人第一次配网桥会困惑：br0 明明能配 IP、能 ping 通，它不就是块网卡吗？不是。br0 是一个 net_device，但它的 priv_flags 带 IFF_EBRIDGE 标志，内核见到这个标志就知道——这不是一块真网卡，而是一个二层交换实体的管理接口（你可以把它理解成交换机上的"CPU 口"）。
真正干活的是两类设备：
- bridge 设备本身（
br0）：负责把帧上送给本机协议栈，以及本机经 br0 发出去的流量（"CPU 口"）。 - 被 enslave 的 slave 端口（
eth0、veth0 等）：这些才是真正接线的口。
把一块网卡塞进桥，走的是 br_add_if()。它的关键一步：
intbr_add_if(struct net_bridge *br, struct net_device *dev){structnet_bridge_port *p; ... p = new_nbp(br, dev); // 分配 net_bridge_port，挂进 br->port_list ... err = netdev_rx_handler_register(dev, br_handle_frame, p); // 把收包拦截到桥 ...}
netdev_rx_handler_register(dev, br_handle_frame, p) 这句话是整个 bridge 的"开关"：它给从设备（slave）的 dev->rx_handler 挂上 br_handle_frame，并把 p（端口上下文）作为 rx_handler_data。从此这块网卡收到的每一帧，在 __netif_receive_skb_core() 里会被 skb->dev->rx_handler 截走，先去 bridge 走一遍，而不是直接进 IP 栈。
注意一个反直觉但极其重要的点：br0 自己没有注册 rx_handler。所以帧从 slave 端口进桥、处理完再 br_pass_frame_up 交给 br0 时，br0 不会再被 rx_handler 截一次——桥不会自己跟自己死循环。
二、先认清楚三大数据结构
讲路径之前，先把内核里的三个核心结构钉死，后面全是它们的字段在跳转：
// net/bridge/br_private.h（简化）structnet_bridge {structnet_device *dev;// 对应的 br0structlist_headport_list;// 所有 slave 端口链表structrhashtablefdb_hash_tbl;// 转发表 FDB（现代内核用 rhashtable） u32 ageing_time; // FDB 表项老化时间，默认 300s ...};structnet_bridge_port {structnet_bridge *br;// 归属哪台桥structnet_device *dev;// 对应的真实 net_device（eth0/veth0） u8 state; // STP 端口状态：DISABLED/BLOCKING/LEARNING/FORWARDINGunsignedlong flags; // BR_HAIRPIN_MODE 等structlist_headlist;// 串在 br->port_list 上 ...};structnet_bridge_fdb_entry {structrhash_headrhnode;// 挂进 fdb_hash_tblstructnet_bridge_port *dst;// 命中后从哪个端口出去structnet_bridge_fdb_keykey;// { addr: MAC, vlan_id }unsignedlong flags; // BR_FDB_LOCAL / BR_FDB_STATIC ...unsignedlong updated; // 最近更新时间，用于老化 ...};
一句话串起来：bridge 持有一串端口（port_list）和一张转发表（fdb_hash_tbl）；每个端口知道自己属于哪台桥、对应哪块网卡、当前 STP 状态；转发表里每条记录就是把"目的 MAC + VLAN"映射到"从哪个端口出去"。
三、帧进桥的第一道门：br_handle_frame
帧从网卡驱动上来，经 __netif_receive_skb_core()，一旦 dev->rx_handler 非空（slave 端口都有），就调用 br_handle_frame()。它运行在 rcu_read_lock 下，返回一个 rx_handler_result_t 告诉协议栈"这帧你别管了"还是"放行"。
br_handle_frame 一进来先判断目的 MAC 是不是 link-local 地址（01:80:C2:00:00:0X，生成树 BPDU、LLDP 这类）——这是二层管理帧，不能按普通转发逻辑处理。
- 是 link-local：走
NF_BR_LOCAL_IN 钩子，最终到 br_handle_local_finish()，交给 STP 等二层协议处理——这些帧不能按普通转发逻辑乱跑。 - 不是：端口处于 LEARNING/FORWARDING 态时，进入
NF_BR_PRE_ROUTING 钩子，最终落到 br_handle_frame_finish()——这才是真正的"转发决策点"。
四、决策点：br_handle_frame_finish
这个函数很短，却是整台"交换机"的大脑。它干两件事：先学，再查。
1. 学源 MAC（MAC learning）
br_fdb_update(br, p, eth_hdr(skb)->h_source, vid, flags);
br_fdb_update() 用源 MAC + VLAN 算哈希查 FDB：命中就刷新 updated 时间戳，端口变了就更新 dst（端口迁移）；没命中就 fdb_create() 新建一条。关键点：学习只在端口处于 LEARNING 或 FORWARDING 态时发生——STP 在 BLOCKING/LISTENING 态时端口不学 MAC，这是避免临时环路里学到错表项的基本纪律。
2. 查目的 MAC，分三路
查 FDB 拿到目的 MAC 对应的表项，分支如下：
- 命中且是本地（
BR_FDB_LOCAL）：说明这个 MAC 就是 br0 自己（或者某个 bridge 端口的硬件地址）。调 br_pass_frame_up()，把 skb->dev 换成 br0，重新 netif_receive_skb()，帧就此"上楼"进 IP 协议栈——这就是 br0 能配 IP 收发流量的本质。 - 命中且非本地：已知单播，调
br_forward() 从对应端口出去。 - 未命中 / 广播 / 组播：调
br_flood()（或 br_multicast_flood()），洪泛到所有转发端口。注意广播与组播帧在洪泛的同时，还会经 br_pass_frame_up 上送一份给本机（若本机在该广播域），即"上送 + 洪泛"两路并行。
br_pass_frame_up() 为什么不会回环？因为它把 skb->dev 改成了 br0，而 br0 没有 rx_handler，下一轮 __netif_receive_skb_core 不会再把它截回桥里。
五、已知单播怎么转出去：br_forward 与 should_deliver
br_forward() 的核心是"能不能从端口 to 发、要不要克隆"：
voidbr_forward(conststruct net_bridge_port *to, struct sk_buff *skb, struct sk_buff *skb0){if (should_deliver(to, skb)) {if (skb0) deliver_clone(to, skb, __br_forward); // 洪泛时每口一份克隆else __br_forward(to, skb);return; }if (!skb0) kfree_skb(skb);}
should_deliver() 是交换机"别把帧从进来的口又扔回去"这道铁律的内核实现：
staticinlineintshould_deliver(conststruct net_bridge_port *p, conststruct sk_buff *skb){return (((p->flags & BR_HAIRPIN_MODE) || skb->dev != p->dev) && br_allowed_egress(...) && p->state == BR_STATE_FORWARDING);}
核心三条件缺一不可（现代内核还额外叠加了 isolated 端口隔离与 switchdev 硬件卸载出口两项检查，逻辑一致）：
skb->dev != p->dev：出口不能是进来的那个口（除非开了 BR_HAIRPIN_MODE，比如某些虚拟化场景需要同口进出）。br_allowed_egress()：VLAN 放行检查。p->state == BR_STATE_FORWARDING：端口必须处于转发态，BLOCKING 态的口一律不发。
过了检查，__br_forward() 做一件要紧事——把 skb->dev 从入端口换成出端口 to->dev，然后依次过桥的 Netfilter 钩子：
staticvoid __br_forward(conststruct net_bridge_port *to, struct sk_buff *skb){structnet_device *indev = skb->dev; skb = br_handle_vlan(to->br, nbp_get_vlan_info(to), skb); ... skb->dev = to->dev; skb_forward_csum(skb); NF_HOOK(NFPROTO_BRIDGE, NF_BR_FORWARD, skb, indev, skb->dev, br_forward_finish);}intbr_forward_finish(struct sk_buff *skb){return NF_HOOK(NFPROTO_BRIDGE, NF_BR_POST_ROUTING, skb, NULL, skb->dev, br_dev_queue_push_xmit);}
br_dev_queue_push_xmit() 做 MTU/分片判断后，最终 dev_queue_xmit(skb)——帧从出端口的网卡驱动真正发出去。到此，一次二层转发闭环完成，全程没碰 IP 路由表。这正是容器 A ping 容器 B 却"绕过"宿主协议栈的原因：包在 bridge 里就改道了。
六、未知帧怎么铺开：br_flood
目的 MAC 查不到（或广播/组播）时，br_flood() 遍历 br->port_list，对每个端口用 maybe_deliver() 问一遍 should_deliver()，能发的就 __br_forward。
voidbr_flood_forward(struct net_bridge *br, struct sk_buff *skb, struct sk_buff *skb2){ br_flood(br, skb, skb2, __br_forward);}
洪泛时每个出口都要独立的 skb 副本，所以走的是 deliver_clone()——克隆一份再 __br_forward，避免多个口共用同一块 skb 互相踩踏。这点和真实交换机的"未知单播洪泛"行为完全一致。
七、桥的"CPU 口"：本地收发
之前都是"从端口进、从端口出"的纯桥接。还有两条路径涉及 br0 本身：
收（帧上送本机）：第四节讲过，br_pass_frame_up() 把帧交给 br0，skb 重新进 __netif_receive_skb_core，这次因 br0 无 rx_handler 而直接进入 IP 栈。于是本机进程能通过 br0 的 IP 收发流量。
发（本机经 br0 出）：当你 ping 一个经 br0 可达的地址，协议栈把帧交给 br0 的 ndo_start_xmit——也就是 br_dev_xmit()：
netdev_tx_tbr_dev_xmit(struct sk_buff *skb, struct net_device *dev){ ...if (is_broadcast_ether_addr(dest)) br_flood_deliver(br, skb, false); // 广播：所有转发端口elseif (is_multicast_ether_addr(dest)) br_multicast_deliver(...); // 组播：走 MDB / 组播 FDBelseif ((dst = __br_fdb_get(br, dest, vid))) br_deliver(dst->dst, skb); // 已知单播：指定端口else br_flood_deliver(br, skb, true); // 未知单播：洪泛（与入向对称）// br_deliver / br_flood_deliver 最终都走 __br_deliver → NF_BR_LOCAL_OUT → br_forward_finish ...}
br_deliver() 对应"已知单播本地发出"，br_flood_deliver() 对应"广播本地发出"，它们和入向的 br_forward/br_flood 对称，只是起点是桥设备、先过 NF_BR_LOCAL_OUT 钩子。这就是交换机的"CPU 口"双向逻辑。
八、转发表 FDB 的细节
FDB 是现代内核的 rhashtable（br->fdb_hash_tbl），查找走 br_fdb_find_rcu()：
static u32 br_mac_hash(constunsignedchar *mac, __u16 vid){/* 越过 MAC 前 2 字节，取其后 4 字节（含 OUI 末字节）参与哈希 */ u32 key = get_unaligned((u32 *)(mac + 2));return jhash_2words(key, vid, fdb_salt); // rhashtable 框架负责最终取模}
哈希取 MAC 偏移 2 字节起的 4 字节（OUI 末字节 + 随后 3 字节 NIC 地址）+ VLAN ID 做 jhash，由 rhashtable 负责最终取模到桶。表项有两类特殊标志值得记住：
BR_FDB_LOCAL：MAC 属于桥自身（如 br0 的 MAC、各端口硬件地址），命中即上送 CPU，绝不从别的口转发出去。BR_FDB_STATIC：用户 bridge fdb add 写的静态项，不参与老化，重启学习不会覆盖它。
老化靠 ageing_time（默认 300 秒）。有个细节：hold_time(br) 在 topology_change（STP 拓扑刚变）时会改用 forward_delay（默认 15 秒）——拓扑震荡期间让旧表项更快失效，防止临时环路。想看实时表：
# 看 FDB：offload 标记来自硬件，self 是内核学的，static 是手配的bridge fdb show dev veth0bridge fdb show br br0
九、桥上的 Netfilter 与 STP
bridge 自己有一套 Netfilter 钩子（NFPROTO_BRIDGE）：NF_BR_PRE_ROUTING、NF_BR_LOCAL_IN、NF_BR_FORWARD、NF_BR_POST_ROUTING、NF_BR_LOCAL_OUT，外加 ebtables 专用的 BROUTING。开启 bridge-netfilter（br-nf）后，经过桥的 IP 包还会被 iptables 的各链看到——这正是"容器出网要配 iptables MASQUERADE"那篇文章（后续选题 #4）能和桥接咬合的接口。
STP 则保证多桥组网不出现二层环路。br_stp_rcv() 处理 BPDU，把端口推到 DISABLED→BLOCKING→LISTENING→LEARNING→FORWARDING 五个状态。回顾第四节：只有 LEARNING/FORWARDING 才学 MAC、才转发，BLOCKING 态端口虽然收 BPDU 但不参与数据转发。Bridge 实现的就是 IEEE 802.1D 这套语义。
十、回到开头那个问题
把整条链路串一遍：容器 A 的 vethA 是桥的一个 slave 端口，容器 B 的 vethB 是另一个。A ping B：
- 帧从
vethA 进 __netif_receive_skb_core，被 rx_handler 截到 br_handle_frame。 br_handle_frame_finish 学下"A 的 MAC 在 vethA 口"，查 B 的 MAC——初始没表项，于是 br_flood 洪泛到所有转发端口（含 vethB）。- 帧到
vethB → 容器 B 协议栈，B 回应。回应帧从 vethB 进桥，这次学下"B 的 MAC 在 vethB"，查 A 的 MAC——已命中 vethA，直接 br_forward 单播送达。 - 全程目的 MAC 都不是
br0，所以帧一直在 bridge 内部改道，一次宿主 IP 栈都没进。
小结
这一篇把 bridge 这台"软件交换机"拆成了：rx_handler 拦截收包 → br_handle_frame_finish 学源查目的 → should_deliver 把关 → __br_forward/br_flood 改道发出，并用 FDB（rhashtable + 老化 + STP 状态）把"查哪出口"这件事做得和硬件交换机同构。
动手验证清单（任选内核机器）：
# 看桥和端口ip link add br0 type bridgeip linkset veth0 master br0ip link show master br0# 看 FDB 怎么随时间学习bridge fdb show br br0# 看 veth0 是否被 enslave 进桥（rx_handler 已挂上的旁证）ls /sys/class/net/veth0/brport/ # 有内容说明它已被桥接管cat /sys/class/net/br0/brif/*/state # 各端口 STP 状态（2=FORWARDING 等）
