南瓜丶奇迹师1. VXLAN核心思路与适用场景
1.1 VXLAN到底解决了什么问题
先聊一个我经常被问到的场景：某公司机房扩容，业务部门要求在现有物理网络上跑300个隔离的租户网络，之前用的VLAN只有12位，满打满算4094个可用ID，刨掉保留地址实际可分配的大概3960个，勉强能塞下。但如果未来要扩展到上千个租户，或者要在多个机房之间打通二层域，VLAN这套玩法基本就到头了。
VXLAN（Virtual Extensible LAN）就是冲着这个需求来的。它最核心的思路是“MAC in UDP”——把虚拟机或容器的以太网帧原封不动塞进一个UDP报文里，再用24位的VNI（VXLAN Network Identifier）来区分不同的租户网络。24位意味着理论上支持1600万个隔离网络，这个量级给云计算平台做多租户隔离绰绰有余。
我接触VXLAN是在某云平台做网络虚拟化改造的时候。当时业务方提的需求很直白：跨机房的虚拟机迁移要保留IP和MAC，不能因为换了物理位置就断网；同时底层交换机要灵活，最好不做大改。VXLAN天然适合这种场景——它在IP网络上叠加出一个二层域，物理网络的拓扑变化不会影响虚拟网络的连通性。
还有一个容易被忽视的点：传统VLAN的标准只定义了12位，二层的生成树协议（STP）在大二层网络里也非常痛苦。VXLAN的Overlay架构天然绕开了STP的很多限制，因为VTEP（VXLAN Tunnel Endpoint）之间走的是三层路由，不需要跑STP。只要底层IP网络可达，VTEP就能建立隧道。
1.2 VXLAN适合谁用、用在什么场景
从我的实际经验来看，VXLAN的典型用户有三类。
第一类是云平台厂商或大中型的虚拟化集群管理员。他们需要在几千台物理机上动态创建、销毁隔离网络，并且要求虚拟机能在不同宿主机之间无缝迁移。传统VLAN在大规模场景下配置量巨大，VXLAN配合控制平面自动化能大幅降低配置负担。
第二类是多机房或者混合云场景下的网络架构师。比如某公司分别在两个机房部署了OpenStack集群，希望让这两边跑在同一个二层域里，虚拟机漂移过去网络不感知。VXLAN隧道可以穿过三层网络甚至穿越公网，只要两端VTEP能通信就行。
第三类是企业内部做网络虚拟化改造的运维工程师。很多公司的传统网络是“一网多用”，办公、测试、生产都在一张物理网上，隔离靠VLAN，安全靠ACL，管理上容易出乱子。用VXLAN做Overlay之后，物理网络只需要提供IP转发能力，所有策略和隔离都放在Overlay层控制。
需要说明的是，VXLAN不是银弹。如果你的网络规模很小，几十台服务器，VLAN完全够用，没必要引入VXLAN的复杂度。只有当“规模”“跨机房”“虚拟化迁移”这三个关键词同时出现时，VXLAN才真正值得投入。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. VXLAN核心技术细节与封装原理
2.1 VXLAN封装的“从里到外”怎么看
要理解VXLAN，第一步就是看报文封装。原始的二层以太网帧（包括目的MAC、源MAC、可能存在的802.1Q VLAN Tag、上层IP和负载）整个作为VXLAN的payload。前面加上8字节的VXLAN头，其中24位是VNI，还有标志位和保留字段。再往前加UDP头，目的端口固定为4789（这是IANA分配的知名端口），源端口一般由VTEP根据原始帧的哈希自动计算。
最终外层封装是：外层以太网头 + 外层IP头 + 外层UDP头 + VXLAN头 + 原始以太网帧。
这里有几个关键点值得展开。
第一，为什么用UDP而不是直接基于IP？因为UDP有端口号，天然支持多路复用，并且现网中的负载均衡设备（包括交换机的ECMP、网卡的RSS）都能基于五元组做哈希分流。如果直接基于IP封装，外层没有端口维度，ECMP就只能靠IP地址哈希，流分布的粒度不够细。
第二，源UDP端口的选择。我做过测试，如果所有隧道流量的源端口都固定，那么跨多链路的ECMP哈希会选择同一条物理链路，容易造成链路拥塞。标准做法是把原始二层帧的头部字段（源MAC、目的MAC、VNI等）丢进哈希函数，算出一个随机化的源UDP端口，这样每条流的外层五元组都不一样，ECMP能把流量均匀打散到多条链路上，带宽利用率能提升不少。
第三，关于VNI的作用域。VNI只在一个VTEP的本地有意义，不同VTEP之间通过VXLAN隧道通信时，VNI的映射关系由控制平面或静态配置来协商。同一个二层广播域对应同一个VNI，不同广播域用不同VNI。这个设计非常像VLAN ID，只不过范围从4094扩展到了1600万。
2.2 VTEP、NVE、VNI，三个名字别搞混
VXLAN体系里有三个基础概念：NVE（Network Virtualization Edge，网络虚拟化边缘）是承载VXLAN功能的逻辑实体，通常集成在交换机或服务器虚拟化软件上；VTEP是NVE的具体实现，负责VXLAN报文的封装和解封装，每个VTEP有一个IP地址，通常叫VTEP IP或者Tunnel IP，这个IP在底层Underlay网络中必须路由可达；VNI则用来标识Overlay网络中的不同租户或不同二层域。
我见过很多人在刚开始接触VXLAN时，把VTEP和VNI搞反。一句话总结：VTEP是“隧道端点”，负责加密封装的动作；VNI是“隧道标签”，负责区分隧道里跑的是哪一家的业务。两者配合才能完成跨节点的二层扩展。
还有一个容易混淆的点：VTEP不一定非要跑在硬件交换机上。在服务器虚拟化场景里，虚拟交换机（比如Open vSwitch）本身就实现了VTEP功能，宿主机内核也能直接支持VXLAN封装。而在传统数据中心里，接入交换机或汇聚交换机也可以作为VTEP接入VXLAN网络。两种方式各有优劣：服务器做VTEP部署灵活，性能依赖CPU或网卡卸载能力；交换机做VTEP性能好，但硬件支持度、配置灵活性和成本都要权衡。
我自己的经验是：如果云平台用的是成熟虚拟化方案（比如OpenStack Neutron），首选让各宿主机上的虚拟交换机充当VTEP，配置闭环，灵活性强；如果网络团队对硬件方案更熟悉，或者对转发性能要求极高，可以选用带VXLAN卸载能力的TOR交换机。
2.3 报文转发流程：从虚拟机A到虚拟机B
为了讲清楚VXLAN的实际转发，我拿一个最常见的场景来说：同VNI、跨宿主机的两台虚拟机通信。
假设虚拟机A在宿主机1上，IP是10.0.0.1，MAC是AA:AA:AA:AA:AA:01；虚拟机B在宿主机2上，IP是10.0.0.2，MAC是BB:BB:BB:BB:BB:02。两台宿主机上的VTEP IP分别是192.168.1.1和192.168.1.2，底层网络能互相路由。
当虚拟机A发出一个IP包给虚拟机B（IP层目的10.0.0.2），虚拟交换机先查自己的MAC转发表，发现目的MAC对应的出接口不在本地，而在某个VXLAN网络上。于是它把这个二层帧交给VTEP模块，VTEP查VNI对应的VXLAN转发表，找到目的VTEP的IP是192.168.1.2，然后执行封装：原始二层帧作为payload，加上VXLAN头（VNI设为10），加上UDP头（目的端口4789），加上外层IP头（源192.168.1.1，目的192.168.1.2），最后加上外层以太网头发给物理网络。
物理网络完全不懂VXLAN，它只知道这个报文是一个普通的UDP包，目的IP是192.168.1.2，于是按常规路由转发过去。宿主机2收到之后，根据目的端口4789识别出这是VXLAN报文，交给VTEP模块解封装，取出里面的原始二层帧，按照VNI 10查对应的虚拟网络，找到虚拟机B的接口，把帧送进去。虚拟机B看到的就是一个普通二层帧，完全没有感知到中间经过了一层隧道封装。
这里出现一个常见的疑问：如果虚拟机A不知道虚拟机B的MAC地址怎么办？那就会先发ARP广播。在VXLAN网络里，广播的实现是把ARP请求封装成多播或通过控制平面发送给同一个VNI下的所有远程VTEP。后面讲控制平面的时候我再详细展开。
3. 控制平面方案选型与数据平面行为解析
3.1 静态泛洪与BGP EVPN，怎么选
VXLAN本身只定义了数据平面的封装格式，没有硬性规定控制平面怎么建。实际落地时主流有两条路：一是“头端复制+ARP泛洪”的传统模式，二是基于BGP EVPN的现代模式。
先讲传统模式。在这种方案里，VTEP之间不会主动交换MAC地址表，而是靠多播或头端复制来处理BUM（广播、未知单播、组播）流量。如果底层网络开启了多播，VTEP会把ARP请求封装成组播包发给同VNI的一组VTEP；如果底层不开多播，就需要在配置里把头端复制列表写上，即接入VTEP主动把BUM报文逐一封装并单播给对端VTEP。
头端复制在规模小的时候很省事，不需要额外的控制平面协议，所有VTEP之间手动建VXLAN隧道或者用小工具自动发现就行。但问题也很明显：BUM流量会被放大N倍（N为对端VTEP数量），网络规模一大，广播风暴的风险就很高。另外，MAC地址表学习完全依赖数据平面的源MAC学习，出现环路时需要额外的水平分割机制。
再说BGP EVPN。这套方案把VXLAN的控制平面建立在BGP之上，通过EVPN地址族传递MAC地址、IP地址、VNI信息。VTEP学习到远端MAC后，直接写入转发表。最重要的是，BGP EVPN原生支持ARP抑制、多活接入等高级特性，在大型云平台、大规模VXLAN部署里是事实标准。
给我的建议：规模几个节点、几十个节点的内部实验环境或者小机房，用静态+VLAN映射就可以了，头端复制带来的流量放大问题不太明显；如果是上百台宿主机、上千个VNI、经常做虚拟化迁移的生产环境，务必上BGP EVPN，不然广播流量会教你做人。
3.2 BGP EVPN的工作机制：从MAC路由到隧道建立
在BGP EVPN方案里，每个VTEP（无论是硬件交换机的NVE接口还是服务器上的虚拟交换机）都与一个BGP对端建立会话。这个BGP对端可以是交换机、路由器，也可以是一组专门跑反射器的服务器（RR，Route Reflector）。
当宿主机1上的虚拟机A首次发送ARP请求时，VTEP发现目标MAC不在本地缓存中，除了正常泛洪（或者做ARP抑制）外，它还会通过EVPN的MAC/IP Advertisement路由把“我这里有MAC AA:AA:AA:AA:AA:01，IP是10.0.0.1，属于VNI 10，我是192.168.1.1”这份信息发布出去。远端VTEP收到这条路由后，在自己的转发表里添加一条远程MAC地址表项，指向对端VTEP的IP地址。
这种机制最大的好处是：MAC表的建立是“按需学习”，BUM流量被极大地压缩。同时，如果虚拟机迁移到另一台宿主机，它发出的免费ARP或者新的EVPN路由会把新位置信息传播出去，旧的位置信息自动撤销，网络感知到迁移几乎是瞬时的。
我搭建实验环境时，用Linux自带的FRRouting或标准交换机配置BGP EVPN，步骤并不复杂，核心是把BGP进程配好，family l2vpn evpn启用起来，然后把VNI和EVPN实例关联。这些在配置层面就是几条命令的事，但里面牵扯了很多状态机的细节。想深入的话，建议先搭两到三台虚拟机做一个小型VXLAN环境，配合BGP EVPN验证一下，进展会快很多。
3.3 VXLAN的数据平面相关特性解析
控制平面解决“怎么知道目的MAC在哪”，数据平面解决“报文怎么封装转发”。这里有几个数据平面的高频话题值得单独拿出来说。
一个是MTU。VXLAN封装一次性增加了50字节（外层以太网14字节 + 外层IP 20字节 + 外层UDP 8字节 + VXLAN头8字节）。如果你的Underlay网络MTU是1500，那虚拟机的网络MTU只能设成1500-50=1450，否则大包会在VTEP出接口被分片，转发性能下降。
实际运维中我一般建议把Underlay的MTU调到9000（巨型帧），这样Overlay网络的虚拟机可以继续使用1500的标准MTU，不会因为分片问题引发奇奇怪怪的TCP性能问题。尤其现在很多云主机默认网卡都会协商MTU，如果Underlay不开巨型帧，VXLAN隧道里的流量很容易出现“能Ping通但大文件传输很慢”的症状，排查起来特别坑。
另一个是ARP抑制。在BGP EVPN方案中，VTEP收到虚拟机发出的ARP请求时，可以先查一下本地是否已经有对应的MAC/IP映射缓存，如果有，直接代理回复，不再向远端泛洪。这个特性对减少BUM流量作用很大，尤其在大二层场景下，广播域内有几百台虚拟机时，ARP抑制能把广播流量降低两个数量级。
第三个是BUM流量的处理细节。即便有了ARP抑制，VXLAN网络里仍然可能有未知单播或多播流量。VTEP对于这类报文要么用组播地址承载（需要Underlay支持PIM或其他组播协议），要么用头端复制列表（接入VTEP主动封装给所有成员）。后一种方案好在配置简单，坏在如果成员数量多，每个BUM包会被复制出N份，对VTEP的CPU和链路带宽都是考验。
4. 实操落地：从零搭建一个VXLAN实验环境
4.1 实验拓扑与环境准备
纸上谈兵没用，我建议用虚拟机直接动手搭一套最小化的VXLAN环境。我用Linux环境做过完整验证，大家可以照着这个思路往下走（不同操作系统环境差异不大）。
准备三台“物理机”（实际的物理机或者功能完整的虚拟机都行），分别叫node1、node2，以及一层Underlay设备/路由设备用于转发。在node1和node2上各创建一个网桥，通过VXLAN类型端口把两个网桥连接成一个虚拟二层域。
环境需求清单：
- 两台Linux服务器（Ubuntu或CentOS，需要内核版本支持VXLAN，一般3.12以上就行）
- 两个独立的网络命名空间或虚拟网桥，用来模拟两台虚拟机（或者直接用两个容器）
- Underlay网段：192.168.1.0/24，node1的VTEP IP是192.168.1.11，node2是192.168.1.12
- VNI选择：100，表示一个业务网络
这个架构非常贴近真实场景：两台宿主机上的虚拟网络通过VXLAN隧道打通，底层网络不用做任何VLAN划分。
4.2 配置步骤与验证命令
我用ip命令来配置VXLAN，标准Linux下不需要额外安装工具包。
先在node1上创建VXLAN接口：
code复制ip link add vxlan100 type vxlan id 100 dstport 4789 remote 192.168.1.12 dev eth0
ip link set vxlan100 up
这个命令创建一个VNI为100的VXLAN接口，remote指定对端VTEP IP（仅适用于点对点场景），dev eth0表示隧道底层走哪个物理接口。如果是多点场景，可以去掉remote，配置组播组或者交给BGP EVPN管理。
node2上同样操作：
code复制ip link add vxlan100 type vxlan id 100 dstport 4789 remote 192.168.1.11 dev eth0
ip link set vxlan100 up
然后把两个节点的vxlan100接口都加入同一个Linux网桥：
code复制ip link add br0 type bridge
ip link set vxlan100 master br0
ip link set br0 up
如果node1和node2上各有一台虚拟机（或者网络命名空间）连着br0，那么这两台虚拟机就处于同一个二层域，可以互相Ping通。
验证命令如下：
code复制ip -d link show vxlan100
bridge fdb show
ip neighbor show
第一条能看到VXLAN的详细配置（ID、端口、远程VTEP）；第二条查看FDB表，里面会有“00:00:00:00:00:00”这种所有流量全交给remote的默认条目；第三条确认邻居表有没有学到对端的VTEP MAC。
我在第一次实验时踩过一个坑：忘了打开网桥的组播/转发相关设置，导致两边的虚拟机虽然能通过VXLAN通信，但广播包没法跨节点传播，ARP直接失败。Linux bridge默认开了MAC学习，但对VXLAN接口的泛洪行为需要额外设置，比如用ip link set vxlan100 type bridge_slave flooding on（部分版本的命令细节有差异）。如果实验时发现单播通、广播不通，优先检查这个。
4.3 参数计算：MTU和安全组/防火墙端口怎么设
VXLAN部署中，最不值得踩但最常见的就是MTU和UDP端口被墙的问题。
先算一下MTU。假设Underlay网卡MTU是1500，VXLAN封装额外开销是50字节（如果你开了其他隧道还有额外开销，但标准VXLAN就是50）。那么Overlay网络的MTU必须是1500-50=1450。如果你创建的是Linux bridge，可以在虚拟机或命名空间的接口上直接设置为1450，也可以在网桥接口上设置。
如果想保留VM的MTU为1500，那就把Underlay物理网卡的MTU改成1500+50=1550（或者直接开巨型帧9000）。有个小技巧：先查物理网卡支持的MTU最大值，用ip link show看一下，很多主流网卡都支持9000，直接开9000最省心。
防火墙端口：VXLAN的默认UDP端口是4789。所有VTEP之间的UDP 4789必须放通，包括本机防火墙（firewalld或ufw）和物理网络ACL。如果你改了端口，记得在ip link add命令里用dstport参数指定，所有VTEP要一致。
另外说一个容易被忽略的点：很多云环境或托管机房的安全组默认禁止非目的端口为4789的UDP流量入境，如果VTEP之间建立不了隧道，先别怀疑配置，把安全组规则拉出来看一遍。
4.4 用抓包验证封装的每个细节
配置完成后，想真正理解VXLAN，一定要抓一次包。在node1上执行tcpdump -i eth0 udp port 4789 -vvv，然后在虚拟机A里Ping虚拟机B。
你能看到两类报文：
一类是ARP请求。原始二层帧是广播，目的MAC是FF:FF:FF:FF:FF:FF，被完整封装在VXLAN-UDP包里，外层目的IP是对端VTEP。这时你能直观地看到“二层帧套在IP包里”。
另一类是ICMP请求/应答。原始帧是单播，目的MAC是虚拟机B的MAC，被封装后外层目的IP是对端VTEP的IP，源UDP端口是随机值（由原始五元组哈希得出），目的UDP端口是4789。
抓包还能验证一个细节：VXLAN头里有一个24位的VNI字段，在tcpdump的详细输出里显示为“vni 100”。如果你同时抓了node1物理网卡的vxlan100接口，对比一下就能完整理解“出主机前被封装，进主机后被解封装”的过程。
我在这个阶段最大的体会是：VXLAN的排错多数不是配置或路由不通，而是对“内外两层地址”的区分不够清晰。抓包是建立这种“双层思维”最快的方式。
5. 常见问题与排查技巧实录
5.1 隧道建立不了/虚拟机无法通信，从哪查起
这是被问得最多的问题。我按排查顺序给大家列一个“速查路径”。
第一，先验证底层Underlay的IP连通性。在宿主机A上直接Ping宿主机B的VTEP IP，如果不通，先把Underlay路由搞清楚。这一步能排除80%的配置错误。
第二，检查VXLAN隧道状态。在Linux环境用ip -d link show vxlan100能看到VXLAN当前的状态。如果interface down，查一下物理网卡是否up、VNI和remote参数是否准确。
第三，检查UDP 4789是否可达。可以用nc或telnet测试一下，但注意很多环境UDP探活工具不一定准，最好用tcpdump抓包确认对端是否收到UDP包。如果抓包看不到对端的包，大概率是安全组或防火墙拦截。
第四，检查ARP学习。在虚拟机A里Ping虚拟机B前，先看宿主机A的FDB表里有没有虚拟机B的MAC。如果FDB表没有，说明ARP泛洪没生效；如果有，再看ARP解析是否完成，能区分问题出在数据面还是控制面。
我用这个路径排查过至少十几个VXLAN问题了，命中率很高。
5.2 流量转发通了，但延迟高/传输慢是怎么回事
这种情况最常见的原因是MTU不一致。前面提到过，VXLAN封装给Underlay增加了50字节开销。如果Underlay MTU没配好，大包会被分片甚至丢弃。表现出来就是：小包能通（因为小包小于1450），一旦涉及大文件或大包传输，要么超时要么速度骤降。
排查方法：在两台虚拟机之间做一次带DF标志的大包Ping测试。
code复制ping -M do -s 1400 10.0.0.2 # 在VM A里执行
ping -M do -s 1472 10.0.0.2 # 逐步加大包长，1472是标准MTU下的最大不触发分片的包
如果1400通、1472反而不通（输出里的MTU相关错误），基本可以确定是MTU问题。解决办法就是把Underlay的MTU开成9000，或者把Overlay的MTU降下来，二选一。
还有一个容易漏掉的点：某些虚拟化平台默认对VTEP的封装卸载功能有开关，比如网卡上的VXLAN Offload。如果硬件卸载与虚拟化驱动的版本兼容性不好，可能会产生奇奇怪怪的丢包或性能问题，排查时也可以关注一下是否关闭了相关卸载功能。
5.3 BUM流量过多，广播风暴怎么控制
VXLAN本身并不减少广播，它只是把广播的传播范围从物理网络扩展到了Overlay逻辑网络。如果一个大二层域里有几百台VM，广播量很可观。
控制BUM流量常用几个手段。
第一，在VTEP上做ARP抑制。BGP EVPN方案自带这个功能，传统模式下可以借助Open vSwitch的arp_responder功能或管理系统。有了ARP抑制，首次ARP请求只在本地VTEP被代理应答，不再泛洪到远端。
第二，合理规划大二层域的大小。不要把所有VM都扔进同一个VNI。业务隔离、故障域隔离都要通过VNI区分开。VXLAN虽然理论上有1600万个VNI，但同一个广播域的规模仍然要控制在合理范围内。
第三，如果必须用多播承载BUM流量，务必在Underlay里做好组播组规划，避免多个VNI共用同一个组播组导致的串扰。我见过有团队为了省组播组，把多个VNI映射到同一个组，结果广播流量互相影响。
5.4 一个经典案例：“明明配置都对，但还是不通”
分享一个我印象很深的排障经历。某次跨机房的VXLAN搭建完成后，同机房的虚拟机通信正常，但跨机房的虚拟机之间怎么Ping都不通。
当时的排查过程：先看Underlay——两边机房的路由是通的，Ping对端VTEP IP能通；再看配置——VNI、端口、remote全部正确；最后抓包——发现本端发的UDP包确实到了对端，但对端没有回包。
最后定位到的问题非常讽刺：对端机房防火墙虽然放行了UDP 4789，但只放行了“来源IP为VTEP IP”的入站流量。而VXLAN报文的源IP是由外层封装的VTEP IP决定的，这没问题，可是当我们使用“源端口哈希随机化”特性时，防火墙策略里匹配“源端口为4789”的规则失效了——因为随机的源端口不等于4789。
解决方式有两种：统一调整防火墙规则，只匹配目的端口4789即可；如果防火墙策略实在改不动，临时把VTEP的源端口固定（不推荐生产环境这种作法，ECMP能力会下降）。
这个案例想表达的核心观点是：VXLAN报文的“外层五元组”是完全独立于“内层虚拟机五元组”的。任何防火墙、ACL、安全组策略，如果要作用于VXLAN隧道，都必须对着外层五元组来写，而不是内层虚拟机的地址。这一点特别容易绕晕，但理清之后，排错能力和配置准确度都会有质的提升。
另外一个常被忽视的问题是VXLAN隧道与Overlay路由的联动关系。如果Overlay域里有分布式的网关（比如在每台宿主机上都配了网关地址），那么虚拟机跨子网通信需要额外跑三层路由，这部分如果配置混乱，会出现“二层通，三层却不通”的现象。建议在架构设计阶段就明确：谁来做分布式网关、网关MAC/IP怎么统一、如何通过EVPN同步，这些细节不提前商量好，后期排错会非常头疼。
6. 落地部署经验与我的个人体会
从接触VXLAN到在多个生产环境落地，我的核心体会是：VXLAN最大的难度不在封装格式，不在配置命令，而在整体架构思维的转变。传统网络里，二层广播域和三层子网的边界是由物理设备决定的；而在VXLAN里，这个边界被完全逻辑化了。你可以在任何地方创建任意大小的二层域，域内所有设备的转发行为完全由Overlay控制。
这种逻辑化带来的红利是前所未有的灵活性：虚拟机迁移不再受物理机位置限制，网络拓扑可以跟随业务需求动态调整，物理网络升级维护时不再担心影响业务网络。但相应的代价是运维人员必须要对Underlay和Overlay有清晰的分层认知，不能把两个平面混在一起排查。
我个人在实际操作中的习惯是：先把Underlay网络调清楚，确认底层IP全通、MTU一致、ECMP正常，再在上面叠加VXLAN。很多人一上来就配VXLAN，结果隧道一塌糊涂，查了半天发现Underlay本身就有问题，浪费了大量时间。Underlay是地基，地基不牢，Overlay再花哨也是白搭。
最后再分享一个小技巧：如果你准备在生产环境上BGP EVPN，一定提前把路由反射器（RR）部署好，所有VTEP只跟RR建立BGP会话，避免全互联的BGP会话风暴。同时为EVPN的Address Family开启快速收敛（例如调低BGP Hold Time），配合BFD检测，这样底层链路出故障时VXLAN的收敛速度会快很多，对业务的影响能控制在秒级以内。
VXLAN这套技术本身并不难，难的是把它用对。从实验环境起步，逐步把它引入生产，再配合自动化控制平面收敛架构，这条路走完一遍，你对现代数据中心网络的理解会上一个新台阶。