把不带标签的接入端口映射到正确的 EVPN VNI

不带标签的主机帧由接入端口归类，再由 VTEP 作为 VNI 承载。分发、接入与服务模型要分别检查。

普通以太网主机发送不带标签的帧，EVPN 网络仍然必须把它们承载在正确的租户业务里。接入端口把帧归类到本地网段，VTEP 把该网段映射为 VNI，远端接入点再按主机期望的形式把帧呈现出来。VLAN 与 VNI 标识的是这条路径上不同的环节，两者不必使用同一个编号。请按顺序执行下面的 runbook，因为在任何一步出错都会给出同一个症状：主机在发送，却什么都收不到。

跟踪一个帧穿过网络

对于简单的基于 VLAN 的业务，一条示例路径是这样的：

Host A: untagged frame
  to access port: local VLAN 110
  to VTEP A: L2VNI 50110
  to VTEP B: corresponding local service
  to access port: untagged frame to Host B

VLAN 与 VNI 的编号只是示例，不是规则。本地 VLAN 是只存在于一台交换机上的入向分类；L2VNI 是两台 VTEP 都理解的 overlay 业务标识。overlay 规范 RFC 8365 把业务标识与主机接入方式分开，并列出三种形态：基于 VLAN、捆绑式，以及 VLAN 感知式。

配置入向分类

主机有地址却什么都访问不到，而端口本身是可见的。先判断端口实际处于哪种接入模式——承载不带标签帧的接入端口，还是带 native VLAN 的 trunk——并把它显式设置成那一种。不带标签的帧仍然会在一个具名的本地网段里离开端口，而这个网段是一项决定，不是平台的副作用。打开端口的运行配置，读取它真正拥有的分类，而不是相信一个你从未设置过的厂商默认值。

在典型交换机上，顺序是切换模式并分配接入 VLAN，然后检查端口确实处于 up 且在该状态。如果端口是 trunk，则由 native VLAN 处理不带标签的帧，那是另一种配置，失败方式也不同。在继续之前，把模式和 VLAN 都记录下来。

show running-config interface Ethernet1/1
show interface Ethernet1/1 switchport
show vlan brief

配置 VTEP 与 VNI 映射

VTEP 负责添加 VXLAN 封装和 VNI。主机不生成这层头部，也不需要知道该业务存在。

用平台支持的命令形式把本地 VLAN 映射到 L2VNI，并让该映射在业务两端保持一致。租户 L2VNI 与用于子网间路由的 L3VNI 是不同的对象，混用它们的编号会破坏路由却不影响 L2 路径；还要记住，通往远端 VTEP 的可用 underlay 路由属于配置中的另一层。

如果映射错了，帧照样进入网络，只是落在错误的业务里。这正是这项检查属于业务检查而非链路检查的原因。

配置出向呈现

在远端，收到的业务必须还原成主机期望的样子：接入端口上的裸以太网、你所控制的 trunk 上的特定标签，以及与所选业务模型相符的内层标签处理。在归咎于 overlay 之前，先检查 trunk 的允许 VLAN 列表，因为出向 trunk 不允许的标签会在 overlay 已经完成工作之后被丢弃。确认远端主机期望的是它实际收到的呈现方式，而不是你图纸上假设的那一种。

内层标签是否保留，取决于你所选择的业务模型，所以任何文章都无法一概承诺剥离或保留。假设一种行为的设计，遇上实现另一种行为的平台，会通过链路测试，却在应用层失败。

把本地 MAC 学习、EVPN 业务路由与远端接入映射放在一起阅读，并推动应用所需的邻居发现，而不是只做一次 ping。在另一个桥域里学到的 MAC 地址在那里完全有效，却仍然可能指向错误的业务。

用一对主机验证

先拉起一对主机并验证完整路径，然后再加第二对。随后读取两台 VTEP 上的状态，确认同一个业务标识在两端都出现。

show mac address-table vlan 110
show bgp l2vpn evpn
show nve peers

为每一端记下四个值：端口呈现方式、本地网段、L2VNI，以及出向的反向呈现方式。这份记录能让下一位工程师看出，为什么主机只有一条简单的不带标签连接，而网络却在承载租户业务。如果某项变更失败，就把端口退回到原来的 VLAN 并重新测试同一对主机，让回滚成为一个已知状态，而不是猜测。

相关文章