VXLAN分布式网关M-LAG配置错误

这个测试现象源于一个经典的配置错误：两台Leaf设备将evpn m-lag local-ip和remote-ip写反了。虽然你观察到Underlay路由、BGP邻居和VXLAN隧道都在表象层面“正常”，但本质上建立在了一个【错误的邻居关系】上，从而导致控制平面和数据平面出现了严重分裂。

你遇到的“首包双Tag，后续单Tag”现象是这种分裂下的典型表现。

控制平面：一个基于错误身份的邻居关系

当evpn m-lag local-ip和remote-ip互换时，两台Leaf的BGP身份识别出现了问题，这直接破坏了EVPN控制平面。

1. BGP邻居“看似正常”：
   BGP会话的建立通常基于IP层的可达性。只要两台Leaf设备的环回口IP地址能够互相ping通，并且两者之间的BGP配置了正确的peer地址，TCP会话就能建立，BGP邻居状态就可能是Established 。

   • 由于两台 Leaf 的环回口 IP 地址分别是 1.1.1.1 和 1.1.1.2，它们是路由可达的。因此，即使 local-ip 配置错误，设备也可能认为 BGP 邻居是正常的。

2. 真正的损害是MVXLAN身份声明错误：
   尽管BGP邻居亮了，但设备在VXLAN控制平面（MP-BGP EVPN） 却使用了错误的身份来通告自己的路由。

   • 正常情况下：Leaf-A会以1.1.1.1的身份，向Leaf-B通告自己的MAC和路由。

   • 在你的错误配置下：Leaf-A会错误地以1.1.1.2的身份来通告信息，Leaf-B也同理。

   • 结果：每台Leaf都认为自己是对方，这违反了VTEP的惟一性原则，导致EVPN路由无法被正确处理，VXLAN隧道参数错配。对于你单挂在Leaf下的服务器来说，由于这台服务器的流量没有经过M-LAG系统进行负载分担，它受到了更严重的影响 [5†L8-L10]。具体来说，控制层面的问题导致两台Leaf之间并未真正建立VXLAN隧道-1。你可以通过display vxlan tunnel命令确认这一点，正常隧道无法建立正是首包触发慢路径、后续包按硬件降级的根本起因。

 数据平面：硬件学习紊乱，导致“首包+后续单Tag”

控制平面分裂的直接后果，就是数据平面出现混乱，引发了这一精确到你描述的现象。

1. 流量必须“绕行”Peer-link

由于两台Leaf之间没有可用的VXLAN隧道，当服务器A需要跨Leaf访问服务器B时，流量路径变为：服务器A → Leaf-B → Peer-link → Leaf-A → 服务器B。这与预期中“Leaf-B解封装后直接通过VXLAN隧道发送”的正常路径不同，这就是所谓的“绕行”转发。

2. 硬件学习过程紊乱：首包 vs 后续包

设备在通过Peer-link处理这种“绕行”流量时，其硬件学习过程出现了错误，导致了“首包走慢路径，后续包走降级路径”的情况。

• 首包（触发慢路径）：

  • 当第一个跨Leaf的报文（如ping请求）到达Leaf-B时，由于硬件转发表项缺失，它会被送往CPU。

  • CPU通过“慢路径”处理，在首包上生成了符合规范的双层Tag（外层S-VLAN + 内层C-VLAN） 封装，并将其送往Peer-link [5†L21-L22]。

  • 同时，CPU会尝试将这个含双层Tag的完整转发规则下发并固化到硬件转发表，以备后续流量使用 [5†L22-L23]。

• 后续包（执行降级规则）：

  • 由于local-ip和remote-ip配置错误，设备内部的状态机是不一致的。

  • 当第二个报文到达时，硬件在查找你刚才生成的表项时，并没有找到完整的“双层Tag”约束。

  • 错误的状态机导致它激活了一个“备用”的转发规则，即一个简化版本——只携带S-VLAN的单层Tag 。

 解决方案

解决此问题的根本方法是修正 evpn m-lag local remote 下的 local-ip 和 remote-ip 配置，确保两台Leaf的身份声明是正确的，使EVPN控制平面恢复正常。同时，建议升级设备软件版本至最新，部分已知问题可能在后续版本中得到优化。此外，还可以在相应接口下手动配置正常的双VLAN标签转发规则，调整参数强制硬件稳定处理。

建议你优先检查两台Leaf设备上的local-ip和remote-ip配置（使用display this命令查看），并确保它们与环回口地址一致。如果修正后问题仍存在，可能需要进一步排查软件版本或联系H3C技术支持。