排查虚拟化网桥丢包需依次检查网桥状态（ip link show docker0是否UP、IP是否配置）、邻居缓存（ip neigh flush dev docker0）、rp_filter（设为0）和FORWARD链策略（确保ACCEPT），并验证物理网卡与tc规则是否干扰流量。
排查虚拟化环境中网桥丢包，关键不是盯着容器或虚机“连不通”，而是先确认宿主机网络栈是否把包正确收进来、送出去。问题往往藏在网桥状态、内核转发行为、邻居表老化和防火墙策略这四层里。
检查 docker0（或自定义网桥）基础状态
网桥设备本身宕了或没配地址，所有流量就卡在起点：
- 运行
ip link show docker0，确认状态是UP；若为DOWN，执行ip link set docker0 up - 用
ip addr show docker0查看是否有 IP（如172.17.0.1/16）；没有就补上：ip addr add 172.17.0.1/16 dev docker0 - 验证桥接转发是否启用：
cat /sys/devices/virtual/net/docker0/bridge/forward_delay，非零才正常；若为 0，临时修复：echo 1500 > /sys/devices/virtual/net/docker0/bridge/forward_delay
清理陈旧的 ARP 和邻居缓存
容器频繁启停后，docker0 的邻居表常残留失效条目，导致新容器 IP 解析失败，表现为“能 ping 通但 TCP 连接超时”或随机丢包：
Zynq Linux Hardware Debug
下载
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
- 查看当前缓存：
ip neigh show dev docker0 - 清空动态条目：
ip neigh flush dev docker0（不影响静态配置） - 如需长期缓解，可缩短老化时间（谨慎）：
sysctl -w net.ipv4.neigh.docker0.gc_stale_time=60 - 若用的是自定义网桥（如
br-abc123），把命令中的docker0替换为对应桥名
关闭 rp_filter 并校准 FORWARD 链策略
这两个内核参数是虚拟化网桥丢包最常见诱因：
- 检查反向路径过滤：
sysctl net.ipv4.conf.docker0.rp_filter；若返回1或2，设为0：sysctl -w net.ipv4.conf.docker0.rp_filter=0，并写入/etc/sysctl.conf持久化 - 检查 iptables FORWARD 链：
iptables -L FORWARD -n；确认策略是ACCEPT，且存在DOCKER-USER、DOCKER-ISOLATION-STAGE-1等链；若策略为DROP，需调整为ACCEPT或确保 Docker 规则已加载
验证网卡与 tc 规则是否干扰网桥流量
网桥流量最终要走宿主机物理网卡，别忽略底层链路和人为限流：
- 查物理网卡丢包：
ethtool -S eth0 | grep -i "drop\|over\|missed"，重点关注rx_over_errors（Ring Buffer 溢出）、rx_dropped（NAPI 处理慢） - 查 tc 是否在网桥出口或物理接口上配置了丢包策略：
tc qdisc show dev eth0；若看到netem loss 5%或类似规则，说明是人为注入丢包，用tc qdisc del dev eth0 root清除 - 注意：CNI 插件（如 Calico、Flannel）可能在 host interface 上挂 tc 规则，不能只查容器内网卡
