Linux Overlay网络不通怎么排查？从VXLAN、网桥到路由逐层定位

两台 Linux 节点之间的底层地址可以互相 ping，但挂在 VXLAN 网桥上的地址超时，通常不代表“网络整体不通”，而是故障位于某一层：底层 VTEP 路由、UDP 封装、VXLAN 参数、网桥转发、FDB 学习，或最终的 Overlay 路由与防火墙。排查时不要先删除并重建接口，应先保留现场，按照“底层 IP → VXLAN → 网桥/FDB → 地址与路由 → 抓包验证”的顺序缩小范围。

下面以两个 Linux 节点构成的静态单播 VXLAN 为例。节点 A 的底层地址为 192.0.2.11，节点 B 为 192.0.2.12，底层接口均为 eth0；两端使用 VNI 100、UDP 端口 4789，Overlay 网桥地址分别为 10.10.10.1/24 和 10.10.10.2/24。这些地址是文档示例，实际排查时替换为现场值。

一、先确认故障属于哪一层

典型数据路径如下：

Overlay 主机或容器
        │
        ▼
br-overlay（Linux 网桥）
        │
        ▼
vxlan100（封装/解封装）
        │  UDP 4789
        ▼
eth0（底层 VTEP 网络）
        │
        ▼
对端 eth0 → vxlan100 → br-overlay → Overlay 地址

先在两台节点分别保存接口、地址、路由和网桥状态。以下命令是只读检查，适用于大多数使用 iproute2 的 Linux 发行版：

hostname
ip -br link
ip -br addr
ip route
ip -d link show vxlan100
bridge link show
bridge fdb show

可以先根据结果建立初步判断：

一个常见的配置不生效问题是：VXLAN 设备已经创建，但没有加入预期的网桥；或者 VXLAN 已加入网桥，却把 Overlay 地址继续配置在 vxlan100 上。对于以网桥承载二层 Overlay 的场景，通常应把业务地址配置在 br-overlay，而不是配置在作为网桥端口的 VXLAN 设备上。

二、第一优先级：检查底层 VTEP 网络

1. 确认底层接口、地址和路由

在节点 A 上执行：

ip -br addr show dev eth0
ip link show dev eth0
ip route get 192.0.2.12
ping -c 3 -I 192.0.2.11 192.0.2.12

节点 B 执行相反方向的检查：

ip route get 192.0.2.11
ping -c 3 -I 192.0.2.12 192.0.2.11

正常情况下，节点 A 的路由查询应类似：

192.0.2.12 dev eth0 src 192.0.2.11

重点不是输出格式完全一致，而是确认：

• 下一跳使用的是正确的底层接口；
• 源地址是本机 VTEP 地址；
• 没有误走另一块网卡、默认路由或 Overlay 网桥；
• 底层接口处于 UP 状态；
• 两端的底层地址确实可以双向通信。

如果底层 ping 失败，暂时不要检查 Overlay 地址。此时应先查看底层邻居和路由：

ip neigh show dev eth0
ip route

邻居状态为 REACHABLE、STALE 等，通常表示二层邻居已经解析；INCOMPLETE 或 FAILED 则需要先处理底层地址解析、网段配置或底层网络访问控制。

2. 确认 UDP 4789 没有被拦截

VXLAN 的数据包通常以 UDP 形式承载。实际端口必须以当前配置为准，示例中使用 4789。在节点 A 上监听底层接口：

tcpdump -ni eth0 'udp port 4789'

然后从 Overlay 地址发起一次测试：

ping -c 3 -I 10.10.10.1 10.10.10.2

观察结果可以这样理解：

• 完全没有发出的 UDP 包：本机没有进入 VXLAN 发送路径，优先检查 Overlay 路由、网桥端口和 FDB；
• 节点 A 有发出，节点 B 看不到：中间网络或节点 B 的入方向规则可能丢包；
• 节点 B 能看到，节点 A 看不到返回包：反向路径、节点 B 的 VXLAN 参数或出方向规则可能有问题；
• 双方都能看到 UDP 包，但 Overlay 仍不通：继续检查 VNI、VXLAN 设备归属、FDB 和内层包。

查看主机侧防火墙规则时先使用只读命令：

nft list ruleset

如果系统仍使用兼容的 iptables 规则，也可以查看：

iptables -S
iptables -t nat -S

不要为了验证而直接清空防火墙。需要调整规则时，应先导出当前规则，明确只允许两端 VTEP 地址之间的目标 UDP 端口，并记录回滚方式。清空规则或放开所有来源会改变整台主机的安全边界，也可能影响其他业务。

三、第二优先级：核对 VXLAN 参数是否真正生效

1. 以内核实际状态为准

配置文件中写了什么，不等于内核当前使用了什么。先执行：

ip -d link show vxlan100

典型输出中需要重点关注以下字段：

vxlan id 100
local 192.0.2.11
remote 192.0.2.12
dev eth0
dstport 4789

两端应逐项对照：

VNI 不一致时，即使抓包能看到 UDP，接收端也可能无法将报文交给预期的 VXLAN 设备。local 或 remote 写错时，常见结果是包从错误接口发出，或者本机根本没有返回包。UDP 端口不一致时，抓包能证明网络上有 UDP 流量，但不会自动证明它是当前 VXLAN 实例可以处理的流量。

2. 检查 VXLAN 是否加入了正确的网桥

执行：

bridge link show

或者直接查看指定设备：

ip link show master br-overlay

期望看到 vxlan100 是 br-overlay 的端口。也可以使用：

bridge link show dev vxlan100

如果 vxlan100 存在，但没有显示 master br-overlay，说明 VXLAN 设备没有接入该网桥。此时 Overlay 地址即使配置正确，也可能无法通过网桥转发。

还要检查业务地址所在位置：

ip -br addr show dev br-overlay
ip -br addr show dev vxlan100

在二层 Overlay 示例中，预期类似：

br-overlay UP 10.10.10.1/24
vxlan100 UP

如果发现 10.10.10.1/24 配在 vxlan100，而 br-overlay 没有地址，应先确认这确实是网桥承载的二层设计，再在维护窗口内调整。不要在地址未核对、业务仍在线时直接删除旧地址，否则可能中断依赖该接口的连接。

3. 识别手工配置与网络管理服务的冲突

手工执行 ip link add 创建的设备，可能被网络管理服务接管、重命名、删除或重新配置。先确认当前由谁管理：

systemctl is-active NetworkManager
systemctl is-active systemd-networkd

如果使用 NetworkManager，可查看连接与设备：

nmcli -f NAME,TYPE,DEVICE connection show
nmcli device show vxlan100

如果使用 systemd-networkd，可查看：

networkctl status vxlan100
networkctl status br-overlay

常见冲突表现包括：

• 手工命令刚执行成功，重启网络服务后参数恢复错误；
• 配置文件中的 VNI 是 100，但 ip -d link show 显示成了其他值；
• 网桥名称一致，但 VXLAN 端口在服务重启后被移除；
• 同一个接口同时存在两套连接配置；
• Overlay 地址被服务重新放回 vxlan100，而不是 br-overlay。

处理时应选择一个配置管理者。临时使用 ip 命令验证可以帮助定位，但确认修复后必须同步修改实际生效的 NetworkManager、systemd-networkd 或其他网络配置，避免重启网络后故障复现。

四、第三优先级：检查网桥转发和 FDB 学习

VXLAN 设备负责封装和解封装，网桥负责二层转发。两者都显示 UP，不代表网桥已经学到正确的远端 MAC。

1. 查看网桥端口状态

bridge link show master br-overlay
bridge vlan show

如果没有使用 VLAN 过滤，重点看 vxlan100 是否属于 br-overlay，以及端口是否处于转发状态。启用了 VLAN 过滤时，还要确认业务 VLAN 没有被端口规则排除。

查看网桥本身：

ip -d link show br-overlay
ip link show dev br-overlay

如果配置中打开了 VLAN 过滤，而 Overlay 测试流量没有进入允许的 VLAN，可能表现为：

• VXLAN 外层 UDP 正常；
• vxlan100 也在网桥中；
• 但网桥端口之间没有内层转发。

此时不要只看接口是否存在，还要核对 VLAN 过滤配置和业务标签是否一致。

2. 查看 FDB 是否出现远端 MAC

执行：

bridge fdb show dev vxlan100
bridge fdb show dev br-overlay

在产生过 ARP 或 ICMP 流量后，再执行一次。动态学习模式下，通常可以看到与远端 MAC、远端 VTEP 地址相关的条目；使用静态 FDB 的场景，则应看到预先配置的远端映射。不同内核版本的输出格式可能不同，不要只按某一行固定文本判断。

如果 FDB 长时间没有远端条目，可按以下顺序判断：

1. Overlay 地址的路由是否真的选择了 br-overlay；
2. ARP 请求是否出现在 br-overlay 或 vxlan100；
3. VXLAN 是否允许广播和未知单播进入远端；
4. 静态 FDB 方案是否遗漏了远端 MAC；
5. 两端的 VNI 和 UDP 端口是否一致。

查看邻居表：

ip neigh show dev br-overlay

常见状态含义如下：

• REACHABLE：最近一次邻居通信成功；
• STALE：条目存在，但暂时没有近期确认；
• INCOMPLETE：正在解析 MAC，但还没有收到有效响应；
• FAILED：多次解析失败。

10.10.10.2 INCOMPLETE 时，不应先把问题归因于 ICMP 被禁。ARP 本身可能还没有跨过网桥和 VXLAN。可以用抓包确认：

tcpdump -ni br-overlay -e 'arp or icmp'
tcpdump -ni vxlan100 -e 'arp or icmp'

如果 br-overlay 能看到 ARP 请求，但 vxlan100 没有对应流量，优先检查网桥端口和 FDB。如果 vxlan100 能看到内层 ARP，但对端没有返回，继续检查对端解封装、VNI 和网桥状态。

五、第四优先级：检查 Overlay 地址和路由

1. 区分二层 Overlay 和三层 Overlay

两台 VTEP 使用同一个 10.10.10.0/24 网段时，通常是二层 Overlay。此时节点 A 的路由应类似：

ip route get 10.10.10.2

期望结果接近：

10.10.10.2 dev br-overlay src 10.10.10.1

如果结果显示走 eth0、其他网卡或默认网关，说明本机路由没有把 Overlay 地址交给网桥。常见原因是：

• 10.10.10.1/24 没有配置在 br-overlay；
• 地址掩码配置错误；
• 存在更精确但错误的路由；
• 网络管理服务重新生成了路由；
• 业务使用了不同的 Overlay 网段，但检查时仍按同网段方式判断。

如果是不同网段之间通过 Linux 节点转发，则不能只依赖二层网桥，还要检查：

ip route
sysctl net.ipv4.ip_forward

这类三层转发场景需要明确每个网段的下一跳、回程路由和防火墙策略。net.ipv4.ip_forward 为 0 时，主机不会按普通路由器转发 IPv4 报文；但对于同一网桥内的二层转发，不能简单用这个参数解释所有问题。

2. 检查反向路径和本机过滤

如果抓包显示请求已经到达，但响应没有从预期接口发出，需要检查本机过滤规则和反向路径检查：

sysctl net.ipv4.conf.all.rp_filter
sysctl net.ipv4.conf.default.rp_filter
sysctl net.ipv4.conf.eth0.rp_filter
sysctl net.ipv4.conf.br-overlay.rp_filter
sysctl net.ipv4.conf.vxlan100.rp_filter

严格反向路径检查在存在多出口、策略路由或非对称路径的环境中，可能丢弃看似合法的返回流量。不要在没有证据时直接全局关闭 rp_filter。如果确实需要临时调整，应先保存旧值，限制到受影响接口，并在验证完成后恢复。

同时检查：

nft list ruleset

重点关注是否有规则针对 br-overlay、vxlan100、Overlay 地址段或 ICMP 做了丢弃。修改防火墙前应导出规则；验证完成后保留最小范围的允许规则，而不是使用“允许全部流量”作为长期修复。

六、用抓包把故障定位到具体跳点

当命令输出无法确定问题时，抓包比反复重启接口更可靠。建议在同一次测试中同时观察外层接口和 Overlay 接口：

tcpdump -ni eth0 -vv 'udp port 4789'

tcpdump -ni vxlan100 -e 'arp or icmp'

tcpdump -ni br-overlay -e 'arp or icmp'

然后从节点 A 发起：

ping -c 3 -I 10.10.10.1 10.10.10.2

可以按照下面的结果分支定位：

ping 只能证明 ICMP 请求和响应是否完成，不能单独证明 VNI、FDB 或所有业务协议都正常。对于同一二层 Overlay 内的地址，traceroute 通常不会显示出类似普通三层网络的多个中间跳点，因为中间的 VXLAN 封装对内层主机表现为二层传输。此时可以分别测试：

traceroute -n -s 192.0.2.11 192.0.2.12

和：

traceroute -n -s 10.10.10.1 10.10.10.2

第一条用于观察底层 VTEP 路径；第二条用于观察 Overlay 地址是否存在三层路径。即使第二条只显示直连、没有中间跳点，也不能据此判断 VXLAN 没有工作。

七、检查 MTU：小包正常不代表业务一定正常

VXLAN 会在原始报文外增加外层 IP、UDP、VXLAN 以及外层二层封装。以常见 IPv4、底层 MTU 1500 为例，Overlay 接口常见的可用 MTU 约为 1450，但实际值仍取决于底层链路和其他封装。

先查看：

ip link show dev eth0
ip link show dev vxlan100
ip link show dev br-overlay

然后进行不同尺寸的测试：

ping -M do -c 3 -I 10.10.10.1 -s 1400 10.10.10.2
ping -M do -c 3 -I 10.10.10.1 -s 1472 10.10.10.2

这里 -M do 要求 IPv4 不进行分片，-s 是 ICMP 数据部分大小。1472 加上 IPv4 和 ICMP 头后约为 1500 字节，经过 VXLAN 封装后通常会超过底层 MTU；它失败并不能直接证明 VXLAN配置错误。若 1400 成功而较大尺寸失败，应重点检查：

• VXLAN 设备和网桥 MTU 是否低于底层允许值；
• 底层是否支持更大的 MTU；
• ICMP “需要分片”消息是否被过滤；
• 应用是否设置了合适的 MSS；
• 路径中是否还有额外封装。

MTU 修复应统一规划两端及相关业务端口，不能只修改一端。修改前记录当前值，确认没有其他业务共享该接口；修改后若造成异常，可按记录恢复原 MTU。

八、典型配置修正：地址放错位置或两端参数不一致

在维护窗口、且已经确认当前配置需要调整时，可以参考下面的目标结构。命令会修改网络状态，不建议在承载生产连接的主机上直接照抄执行。

节点 A 的目标关系：

eth0
 └── 底层地址 192.0.2.11/24

vxlan100
 └── VNI 100
 └── local 192.0.2.11
 └── remote 192.0.2.12
 └── dstport 4789
 └── master br-overlay

br-overlay
 └── 10.10.10.1/24

节点 B 则将 192.0.2.11 与 192.0.2.12、10.10.10.1 与 10.10.10.2 对调，VNI 和 UDP 端口保持一致。

如果只是临时实验环境，可以用以下命令表达这种关系；执行前应先确认接口没有被其他配置管理服务占用：

ip link add br-overlay type bridge
ip link add vxlan100 type vxlan \
    id 100 \
    local 192.0.2.11 \
    remote 192.0.2.12 \
    dev eth0 \
    dstport 4789

ip link set vxlan100 master br-overlay
ip addr add 10.10.10.1/24 dev br-overlay
ip link set vxlan100 up
ip link set br-overlay up

如果接口已经存在，不要重复执行 ip link add。应先查看实际参数：

ip -d link show vxlan100
ip -br addr show br-overlay
ip -br addr show vxlan100

确认地址确实放错后，调整地址时需要明确前缀长度，并提前记录旧状态。例如当前错误地配置为 10.10.10.1/24 的场景，修正动作可能是：

ip addr del 10.10.10.1/24 dev vxlan100
ip addr add 10.10.10.1/24 dev br-overlay

这会造成短暂的网络中断，也可能影响依赖旧接口的服务。回滚就是将地址从 br-overlay 移回原接口，但只有在原配置确实如此且业务设计允许时才能执行。临时修正完成后，还必须同步到实际使用的持久化网络配置中，否则网络服务重启、主机重启后可能再次恢复错误状态。

九、修复后的验证顺序

不要只用一次 ping 判断修复完成。建议按以下顺序复测：

1. 验证底层地址

   ping -c 5 -I 192.0.2.11 192.0.2.12

确认底层 VTEP 双向稳定可达。

1. 确认 VXLAN 参数未被改写

   ip -d link show vxlan100

核对 VNI、local、remote、底层设备和 UDP 端口。

1. 确认网桥关系

   bridge link show master br-overlay
   ip route get 10.10.10.2

预期 vxlan100 属于 br-overlay，Overlay 目标地址使用 br-overlay。

1. 确认邻居解析和 FDB

   ip neigh show dev br-overlay
   bridge fdb show dev vxlan100

发起几次 ARP 或 ICMP 后再次查看，确认状态不再停留在 INCOMPLETE 或 FAILED。

1. 验证 Overlay 连通性

   ping -c 5 -I 10.10.10.1 10.10.10.2

1. 验证报文尺寸

   ping -M do -c 3 -I 10.10.10.1 -s 1400 10.10.10.2

1. 观察一段时间

   ip -s link show dev eth0
   ip -s link show dev vxlan100
   ip -s link show dev br-overlay

重点观察错误、丢包、载荷错误和接口计数是否持续增长。必要时再次使用 tcpdump 确认外层 UDP 和内层 ICMP 都能双向出现。

如果修复后小包持续正常、大包仍然失败，应继续处理 MTU；如果外层 UDP 双向正常但内层间歇性消失，应重点观察 FDB 是否频繁变化、网络管理服务是否反复改写接口，以及防火墙或反向路径检查是否存在丢包。通过保存修复前后的 ip -d link、bridge fdb、路由表和抓包结果，可以判断问题是否真正解决，而不是仅仅因为一次邻居缓存或短暂状态变化而恢复。