广播风暴本质是二层广播帧在多网桥间无节制泛洪，导致CPU飙升、延迟激增及容器通信中断；需通过关闭STP、拆分广播域、限制广播速率等手段隔离与抑制，而非归咎Docker设计缺陷。
多网桥转发引发的广播风暴，本质是大量二层广播帧（如 arp、stp bpdu）在多个桥接域间无节制泛洪，导致 cpu 占用飙升、网络延迟激增甚至容器通信中断。这不是 docker 自身设计缺陷，而是 linux 网桥默认行为叠加拓扑不当所致。解决核心在于“隔离广播域”和“抑制非必要泛洪”，而非简单关闭某项功能。
确认是否真为广播风暴
先排除误判：高 CPU 或丢包未必是广播风暴。需实证：
- 运行 sudo tcpdump -i docker0 -nn ether proto 0x0806 or icmp or stp -c 100，若每秒抓到数十上百条 ARP 或 STP 包，且来源/目标 MAC 高度重复，基本可定性
- 检查 cat /proc/net/dev 中各 bridge 接口的 RX packets 和 rx_errors，若 docker0 或自定义网桥的 errors 明显上升（尤其是 frame/drop），说明链路已过载
- 观察 top -p $(pgrep -f "dockerd|bridge")，若内核线程 ksoftirqd 或 kswapd 占用持续超 70%，常是软中断处理广播帧过载的表现
关闭网桥 STP 并禁用不必要的桥接端口
STP 是广播风暴的常见推手——尤其当多个网桥物理或逻辑上形成环路时，BPDU 泛洪会自我放大。生产环境应默认关闭：
- 对每个网桥执行 echo 0 | sudo tee /sys/class/net/docker0/bridge/stp_state（替换 docker0 为你的网桥名，如 br-abc123）
- 检查 brctl show 输出，确认所有网桥的 STP 列显示为 disabled；若显示 enabled，说明配置未生效
- 移除闲置 veth 接口：ip link show master docker0 | grep veth | awk '{print $2}' | xargs -I{} sudo ip link delete {}（仅限调试，勿在运行中容器上执行）
拆分广播域：避免多个网桥互连
广播风暴最常发生在人为将多个 bridge 用物理网卡或路由规则强行“桥接”起来，例如把 docker0 和 br-ext 用 iptables FORWARD + IP 转发打通。正确做法是：
- 不同业务容器组使用独立的自定义 bridge 网络，例如 docker network create --driver bridge net-app 和 docker network create --driver bridge net-db
- 跨网段通信交由三层路由（宿主机内核路由表 + iptables NAT），而非二层桥接。确保 net.ipv4.ip_forward = 1 开启，但 net.bridge.bridge-nf-call-iptables = 0（避免 iptables 干预桥接帧）
- 绝对禁止用 brctl addif br-a br-b 或类似方式将两个网桥设备直接绑定——Linux 不支持网桥嵌套，此举必然导致泛洪失控
限制广播流量速率（应急手段）
当无法立即重构网络时，可用 tc（traffic control）对网桥入口做广播限速：
- 创建 qdisc：sudo tc qdisc add dev docker0 root handle 1: htb default 30
- 添加 class 限制广播包：sudo tc class add dev docker0 parent 1: classid 1:1 htb rate 100kbit ceil 100kbit
- 匹配并重定向广播帧：sudo tc filter add dev docker0 parent 1: protocol ip u32 match ip dst 255.255.255.255 flowid 1:1
- 该配置将全网广播包限速至 100kbit/s，不影响单播通信，适合临时压测或故障收敛
