HOME

NSX-T 嵌套实验故障排查：TEP 回环、T0 邻居与 OpenWrt 回程路由

作者：祥积宫 3013字 预计阅读时间：15.1分钟 VMware
文章目录10 节

在一套单机嵌套 NSX-T 4.1 实验环境中，我把 ESXi Host TEP 和两台 Edge 虚拟机的 TEP 放在同一个 VLAN、同一个 IP 子网。三个地址可以互相 ping 通，NSX 配置状态也显示成功，但主机页面一直报告“故障 TEP”，Overlay Segment 上的测试虚拟机也无法通过 NSX DHCP 获取地址。

排查最终确认，这不是“NSX 不允许 Host TEP 与 Edge TEP 同网段”。问题出在这套特殊拓扑：Edge 虚拟机就运行在承载 Host TEP 的同一台 ESXi 上，且 Edge 数据网卡与 Host TEP 共用同一台 VDS 和同一二层 TEP 网络。普通 IP 流量可以在 VDS 内部转发，Geneve BFD 却没有形成正常的双向会话。

我把 Edge TEP 迁移到独立 VLAN 和子网，并通过 OpenWrt 在两个 TEP 网段间进行无 NAT 路由。主机与两台 Edge 的 Geneve BFD 随后恢复为 Up，NSX 告警归零，测试虚拟机也成功获得 DHCP 地址。

本文使用脱敏后的管理面信息，保留实测 TEP 地址、VLAN、状态和命令输出，以便说明数据路径。

故障拓扑与现象

最初的 TEP 规划如下：

节点TEP 地址传输 VLAN底层位置
ESXi Host TEP172.31.20.2/24VLAN 20NSX-T-DVS 上的 vmk10
Edge01 TEP172.31.20.3/24VLAN 20同一 ESXi 上的 Edge 虚拟机数据网卡
Edge02 TEP172.31.20.4/24VLAN 20同一 ESXi 上的 Edge 虚拟机数据网卡

Edge 数据网卡连接到 VDS Trunk 端口组，允许 VLAN 0-4094。主机与 Edge 的上行链路配置文件都使用 Transport VLAN 20。

表面上看，配置已经实现：

  • ESXi 的 vmk10 获得 172.31.20.2/24；
  • 两台 Edge 分别获得 .3 和 .4；
  • ESXi 可以 ping 通两台 Edge；
  • NSX Manager 与三个传输节点的控制连接正常；
  • Edge 和主机都能看到远端隧道端口对象。

但运行状态并不正常：

State4: DOWN : BFD_DOWN/VALID_IP

Local IP: 172.31.20.2
Remote IP: 172.31.20.3
Local State: down
Remote State: down

Local IP: 172.31.20.2
Remote IP: 172.31.20.4
Local State: down
Remote State: down

VALID_IP 表明 TEP 地址已经有效，BFD_DOWN 则说明 NSX 用来判断隧道转发能力的 BFD 会话没有建立。仅看到 TEP IP 和隧道对象，并不能证明 Overlay 数据面可用。

普通 ping 正常，为什么 Overlay 仍然失败

我先从 ESXi 的 VXLAN/Overlay netstack 测试两台 Edge TEP。

风险等级：INFO（只读）

作用： 从 ESXi 的 vmk10 和 Overlay netstack 测试 TEP IP 连通性，并用不分片的大包初步检查 MTU。 执行对象： ESXi Shell。需要将接口名、目标地址和包长替换为实际环境值。命令不修改配置。

vmkping ++netstack=vxlan -I vmk10 -c 3 172.31.20.3
vmkping ++netstack=vxlan -I vmk10 -c 3 172.31.20.4
vmkping ++netstack=vxlan -I vmk10 -d -s 1572 -c 3 172.31.20.3

三项测试均为 0% 丢包，大包也能通过。VDS 与两块承载 NSX 流量的物理网卡 MTU 均为 1600。

这只能证明底层 IP 和所测包长可达。Geneve 隧道状态还取决于封装后的 BFD 报文能否按 NSX 数据路径双向处理。

直接检查 BFD，而不是只看隧道对象

在 ESXi 上读取 VTEP 和 BFD 表，可以直接看到主机认为哪条隧道可用。

风险等级：INFO（只读）

作用： 查看 ESXi 上的 VTEP、Transport VLAN、网关和 BFD 会话。net-vdl2 属于低层诊断命令，本段只使用查询参数。 执行对象： ESXi Shell。将 VDS 名称替换为实际名称。不要使用该工具的修改参数。

net-vdl2 -l
net-vdl2 -M bfd -s NSX-T-DVS

在 Edge 的 admin NSX CLI 中直接执行：

风险等级：INFO（只读）

作用： 区分管理 BFD、Edge 间 TEP BFD，以及 Edge 到 ESXi 的 Geneve BFD。 执行对象： Edge 的 admin NSX CLI 提示符。进入 NSX-T-Edge> 后直接输入命令，不要再套用 nsxcli -c。

get bfd-sessions

Edge01 到 ESXi 的关键结果为：

Encap           : geneve
Local_address   : 172.31.20.3
Remote_address  : 172.31.20.2
Remote_discr    : 0
Remote_state    : down
State           : down
Forwarding      : last false (current false)

两台 Edge 之间另有一条 Encap: vlan、UDP 4784 的 BFD 会话为 Up。它只能证明 Edge TEP 之间的底层 VLAN 会话正常，不能替代 Edge 到 ESXi 的 Geneve BFD 结果。

抓包暴露了同主机回环路径

接下来我在 ESXi 的 vmk10 上抓取 UDP 6081。

风险等级：INFO（只读诊断）

作用： 在 ESXi TEP 处捕获少量 Geneve 报文，确认 Edge 发出的 BFD 是否已经到达主机。 执行对象： ESXi Shell。抓包会产生少量诊断负载，并可能包含业务数据；应限制数量和过滤条件，不要公开原始完整报文。

pktcap-uw --vmk vmk10 --dir 2 --udpport 6081 -c 6

抓包同时看到了来自 .3 和 .4 的报文，外层目的地址均为 ESXi TEP .2，VLAN 标签为 20；Geneve 内层是发往 UDP 3784 的 BFD。说明 Edge 报文已经到达主机 TEP 路径。

主机 VTEP 统计中还有一条很关键的记录：

tx.total:             20
tx.drop.total:         0
rx.total:              0
rx.drop.loopback:    362
rx.drop.total:       362

这个计数与本次拓扑高度吻合：Edge 虚拟机和 Host TEP 同处一台 ESXi、同一 VDS、同一二层 TEP 网络，报文没有形成正常的 Geneve/BFD 双向处理。由于计数是累计值，不能把其中每一个包都逐一对应到当时抓到的六个报文；它与 BFD Down、同主机拓扑和后续隔离测试共同构成证据。

我还把两台 Edge 数据端口组的混杂模式临时设为接受，BFD 依然 Down。这个对照说明混杂模式不是修复点，测试后应恢复原设置。

把 Edge TEP 隔离到 VLAN 30

为了绕开同 VDS、同二层网络的本机回环路径，我保留 Host TEP 在 VLAN20，将两台 Edge TEP 迁移到独立的 VLAN30：

节点调整后的 TEPTransport VLAN网关
ESXi Host TEP172.31.20.2/2420172.31.20.1
Edge01 TEP172.31.30.2/2430172.31.30.1
Edge02 TEP172.31.30.3/2430172.31.30.1

OpenWrt 同时终结两个 VLAN，在 VLAN20 与 VLAN30 之间执行三层路由。TEP 跨子网通信不需要处于同一广播域，但中间路径不能做 NAT，并且必须允许 Geneve/BFD 及足够的 MTU。

我为 Edge 新建了 Transport VLAN 为 30 的上行链路配置文件和地址池。迁移完成后，OpenWrt 上的 VLAN20、VLAN30 接口已具备双向路由能力，两个 TEP 网段之间不做 NAT。

恢复验证：BFD、告警和 DHCP 全部闭环

完成 TEP 网络隔离后，ESXi 能够从 VXLAN netstack 跨路由访问两台 Edge：

172.31.20.2 → 172.31.30.2：0% packet loss
172.31.20.2 → 172.31.30.3：0% packet loss

随后 ESXi 的两条隧道都变为：

Local IP: 172.31.20.2
Remote IP: 172.31.30.2
Local State: up
Remote State: up

Local IP: 172.31.20.2
Remote IP: 172.31.30.3
Local State: up
Remote State: up

两台 Edge 对应的 Geneve BFD 也显示：

Encap        : geneve
Remote_state : up
State        : up
Forwarding   : last true (current true)

NSX 主机页面中，两条隧道由红色向下变为绿色向上，Host TEP 状态变为 UP : NORMAL，未解决告警从 1 变为 0。

最后，连接 Overlay Segment 的 Windows 测试虚拟机成功获取租约：

项目实测结果
IPv4 地址10.10.10.10
默认网关10.10.10.1
DHCP Server10.10.10.2
租约时长86400 秒

ESXi 的 Segment ARP 表也学到了测试虚拟机的 IP 与 MAC 映射，Edge 的 DHCP 租约表记录了同一个地址。到这里，TEP、Geneve、Overlay Segment 和 DHCP 数据路径形成了完整闭环。

T0 到外部网络：流跟踪中的 NEIGH 丢弃

Overlay 和 DHCP 恢复后，我让测试虚拟机访问家庭网络网关 10.0.0.1。流跟踪显示，报文已经经过 Edge Tunnel、T1 到 T0 的 transit port、T0 本身和 Edge Firewall，最后在 T0-GW-outport-01 上显示“由 NEIGH 丢弃”。这说明路由查找已经把报文送到 T0 外部口，丢弃发生在下一跳邻居解析阶段，而不是 T0 到 T1 的路由没有命中。

在 Edge 的 T0 Service Router 中读取邻居表时，10.0.0.1 的状态是 incomp，MAC 为全零；T0 外部接口则是 10.0.0.111/16，HA VIP 是 10.0.0.110/16。这个现象表示 T0 当时没有拿到家庭网关的有效 ARP 解析结果。OpenWrt 的实时配置确认家庭 LAN 使用 br-lan.1，地址为 10.0.0.1/16，VLAN 1 在物理 LAN 上以 native/untagged 方式承载。这里需要把外部 Segment 的 VLAN 语义、Edge 上行端口组和 OpenWrt 的 native VLAN 一起核对，不能只看端口组是否写着“允许所有 VLAN”。

回程路由不能漏掉

邻居解析恢复后，OpenWrt 还必须知道 10.10.10.0/24 位于 NSX 后方。检查 OpenWrt 的路由选择时，发现访问测试机地址会命中 PPPoE 默认路由，而不是 T0：

10.10.10.3 via 100.69.0.1 dev pppoe-wan

于是我在 OpenWrt 的 lan 接口上增加了下面的静态路由：

项目值
路由类型unicast
目标10.10.10.0/24
网关10.0.0.110（T0 HA VIP）
接口lan（实际设备为 br-lan.1）

这条路由的作用是让返回流量沿着 OpenWrt → T0 HA VIP → T1 → test-vm 返回。它不是把 10.0.0.1 再指向自己，也不是替代 T0 上的默认路由；它只告诉 OpenWrt 如何返回 NSX Overlay 业务网段。

风险等级：INFO（只读）

作用： 验证 OpenWrt 对测试机网段的选路和 T0 VIP 的邻居解析。命令只读取当前状态，不修改路由。 执行对象： OpenWrt Shell。将地址替换为自己的 Overlay 业务地址和 T0 HA VIP。 完成验证： 目标网段应经 T0 VIP，VIP 的邻居状态应为 REACHABLE、STALE 等已解析状态，而不是 FAILED。

ip route get 10.10.10.3
ip neigh show 10.0.0.110

配置完成后，测试虚拟机可以 ping 通 10.0.0.1，并可以通过域名 ping 通 www.baidu.com。这同时验证了 T0 外部邻居、OpenWrt 回程路由、T0 默认出口、OpenWrt 的 WAN 路由/NAT 和测试机 DNS 解析。

最终数据路径如下：

test-vm 10.10.10.3
  -> T1
  -> T0
  -> T0 外部口 / HA VIP 10.0.0.110
  -> OpenWrt 10.0.0.1
  -> PPPoE/WAN
  -> Internet

本次恢复验证覆盖了 BFD、DHCP 和现有测试流量，没有完成最大业务帧经过 Geneve 与 OpenWrt 路由后的端到端 MTU 验证。实验时 OpenWrt 的 VLAN20、VLAN30 接口 MTU 为 1500；后续如果虚拟机发送接近 1500 字节的内层报文，还需要通过不分片的大包、抓包和业务测试确认是否发生分片或丢包。生产环境应按 NSX 版本和网络设备能力规划一致的 Underlay MTU。

这次问题应当如何表述

不能把结论写成“Host TEP 与 Edge TEP 不能在同一网段”。在常规物理部署中，它们可以使用同一 TEP VLAN 和子网，这也是常见设计。

更准确的结论是：

在本次单机嵌套实验中，Edge 虚拟机与 Host TEP 位于同一台 ESXi、同一台 VDS、同一二层 TEP 网络，普通 IP 通信正常，但 Geneve BFD 无法形成有效双向会话，并出现回环丢包计数。将 Edge TEP 隔离到独立 VLAN 和子网、通过无 NAT 的三层路径转发后，隧道恢复。

因此，单机嵌套实验更稳妥的规划是：

ESXi Host TEP：VLAN20 / 172.31.20.0/24
                     │
               OpenWrt 三层路由
                     │
Edge TEP：      VLAN30 / 172.31.30.0/24

这不是生产环境必须照搬的固定模板，而是针对“Edge VM 与 Host TEP 同宿主、同 VDS”的实验拓扑规避方案。生产设计仍应结合官方支持矩阵、冗余、MTU、路由和故障域规划。

可复用的排查顺序

这次最容易误判的地方，是把“配置成功”“TEP 有 IP”“ping 正常”和“隧道健康”混成一件事。遇到类似问题时，可以按下面顺序收敛范围：

  1. 核对 Transport Node Profile、上行映射、Transport VLAN、IP 池和实际 TEP 地址。
  2. 使用 Overlay netstack 测试 TEP IP 与 MTU，但不要把 ping 成功当作最终结论。
  3. 分别读取 ESXi 与 Edge 的 BFD 会话，确认 Geneve 会话的 State、Remote_state 和 Forwarding。
  4. 在 TEP、VDS 端口和物理上行处定点抓包，判断报文在哪一层停止。
  5. 嵌套 Edge 与 Host TEP 同宿主时，检查同 VDS 的本机回环路径。
  6. 跨 TEP 子网时，同时核对路由、NAT、中间访问控制、Geneve/BFD 和端到端 MTU。
  7. 最终用真实 Overlay 业务闭环验证，例如 DHCP 租约、Segment MAC/ARP 表和虚拟机网关连通性。

这套顺序能把“配置对象已经存在”和“数据平面确实能转发”分开验证，也避免围绕 IP 池、混杂模式或服务重启反复试错。

NSX-T ESXi TEP Geneve OpenWrt 故障排查