VXLAN分布式网关实验详解：从原理到配置排错

1. 为什么全网都在聊VXLAN，以及分布式网关到底解决了什么

先聊点实际的。如果你最近在搞数据中心网络、虚拟化迁移或者跨机房容器网络，一定绕不开VXLAN这个词。我去年的某个项目里，客户要求把两个物理机房的虚拟机网络打通，业务侧要求"看起来就像同一台交换机下面的两台服务器"，而且IP段不能冲突、广播域要统一、虚拟机漂移之后网络策略还得跟着走。一开始大家的第一反应是做传统的大二层，拉光纤、堆交换机，结果一算成本，跨机房的裸光纤费用和波分设备投入直接把预算打爆。后来转向VXLAN方案，才真正体会到这个东西为什么能在数据中心网络里站住脚。

VXLAN全称是Virtual Extensible Network，是一种网络虚拟化技术。它把一个二层以太网帧封装在UDP报文里，通过底层三层的IP网络传输，相当于在现有物理网络上叠加了一层虚拟的二层网络。用大白话说，就是"把二层的网线，接在一张三层的地图上"。

那分布式网关又是怎么回事？传统方案里，不同VXLAN网络之间要互通，通常需要一个集中的三层网关设备，所有跨网段流量都跑到这个网关去转发，性能和可靠性都压在一个点上。分布式网关则是把三层网关功能下沉到每一台参与VXLAN的Leaf交换机上，每个Leaf都能本地响应终端的网关ARP请求，流量就近转发。这个区别，就像"全城只有一个火车站所有人出城都要去那里"和"每个区都有自己的高铁站"的差别。

这篇文章我会从零开始拆一个完整的VXLAN分布式网关实验。实验完全可以在VMware Workstation或者KVM里用几台虚拟机完成，不需要真实硬件，也不需要授权，只要有一颗愿意折腾的心和一台内存不低于16G的电脑。

1.1 实验拓扑和角色分工

先说清楚我实验里的设备角色，你照着搭就能跑起来。

• 两台Leaf交换机：Leaf-1和Leaf-2，承担VXLAN封装解封装和分布式三层网关功能
• 两台Spine交换机：Spine-1和Spine-2，只跑三层路由，负责转发Leaf之间的VXLAN隧道流量
• 两台服务器：Server-1和Server-2，分别连接Leaf-1和Leaf-2，上面跑虚拟机
• 四台虚拟机：VM-A、VM-B跑在Server-1上，VM-C、VM-D跑在Server-2上

IP规划上我采用了典型的两段式设计。Underlay（物理底层）使用10.0.0.0/24网段，Spine和Leaf之间通过Loopback接口建立OSPF邻居，Loopback地址分别规划为10.0.0.1/32和10.0.0.2/32。Overlay（虚拟网络）使用192.168.0.0/24和192.168.1.0/24两个网段，分别对应两个不同的VXLAN网络。

这个实验全网段划分如下，你可以直接抄：

你一定注意到了：Leaf-1和Leaf-2同时配置了Vlan100和Vlan200的网关地址。这就是分布式网关的核心设计——每个Leaf都拥有所有VXLAN网络的网关IP，终端不管连到哪台Leaf，网关MAC都一样，这样虚拟机在Leaf之间迁移时，网关不会变成"别人家的网关"，网络配置完全不用动。

1.2 为什么不用集中式网关而用分布式

先别急着敲命令，我用自己的理解把集中式和分布式的本质差异讲透。集中式网关的做法是：所有VTEP（VXLAN Tunnel End Point，隧道端点）把流量都发到一台专门的网关设备，那台设备上配置所有VXLAN对应的三层接口。好处是设计简单，坏处有三个：一是所有东西向流量都绕远路，延迟高；二是网关单点故障，一旦挂了整个网络瘫痪；三是扩展性差，网关设备转发能力到头了就只能换更大的盒子。

分布式网关的优势在于，每个Leaf都有本地VLAN接口作为VXLAN网络的网关。VM-A要访问VM-C，它先把流量发给Leaf-1上192.168.0.254这个网关，Leaf-1查路由表发现VM-C所在的192.168.1.0/24网络对应的VTEP是Leaf-2，于是做VXLAN封装后直接发给Leaf-2，Leaf-2解封装后转发给VM-C。整个过程中，流量不用绕到某个中心设备，路径短了，时延自然也下来了。

不过分布式网关也有它的痛点——最典型的就是"网关MAC一致性问题"。既然每个Leaf上的Vlan100接口都配了192.168.0.254，那这个网关的MAC地址也必须是同一个，否则虚拟机发出ARP请求时，不同Leaf回的MAC不一样，虚拟机网卡缓存就会错乱。解决这个问题需要Leaf交换机支持"虚拟网关"能力，所有Leaf的网关接口共享同一个虚拟MAC，这个是后面配置的关键点，实验里必须有这一步。

2. 实验环境准备：虚拟设备选型和网络规划避坑

很多初学者卡在第一步就放弃了，因为VXLAN实验不像配个静态路由那么简单，需要同时满足"Overlay能通"和"Underlay能路由"两个条件。我先说设备选型，再说具体规划，最后说三个我踩过的坑。

2.1 用虚拟机模拟交换机和服务器

实验全部在VMware Workstation上进行。Leaf和Spine用思科Nexus 9000系列交换机镜像跑在虚拟机里，服务器则用最小化的Ubuntu Server虚拟机。为什么选Nexus 9000？因为它对VXLAN的支持非常完整，支持分布式网关、BGP EVPN、Anycast Gateway等全套特性，而且命令行和物理设备完全一致，实验经验可以直接迁移到生产环境。

如果你手头有GNS3或者EVE-NG，那更省事，直接拖设备节点就能搭拓扑。不过要注意一点：Workstation里跑交换机镜像，网卡一定要选VMXNET3类型，否则性能会非常差，而且可能无法配置VXLAN隧道。这是第一个坑。

服务器上跑虚拟机跑VXLAN，其实还有另一条路：直接用系统自带的VXLAN模块。Linux内核从3.7开始就原生支持VXLAN，用ip link add vxlan0 type vxlan命令就能创建VXLAN接口。甚至不需要物理交换机，在几台Linux虚拟机之间就能组成VXLAN网络。但我更推荐还是走交换机这一步，因为生产环境里VXLAN基本都是交换机或软交换机承载，把交换机的配置逻辑搞明白，比单纯用Linux命令更接近真实场景。

2.2 Underlay和Overlay双平面规划的细节

实验里最花时间的其实是网络规划，而不是命令行。我给大家一个通用原则：Underlay网络用一套独立的IP段，不要把Loopback地址复用成业务地址；Overlay网络的IP段则要和Underlay段完全错开，这样排查问题时一眼就能看出是哪个平面的流量。

我自己的规划是这样的：

• Underlay互连接口IP：采用10.0.1.x/30、10.0.2.x/30这类掩码30位的点对点地址，节约IP
• Underlay的Loopback接口：采用10.0.0.x/32，专门作为BGP或OSPF的Router-ID以及VTEP源地址
• Overlay业务网段：192.168.0.0/24和192.168.1.0/24，模拟租户的两个二层网段

有一个很容易踩的坑是：VTEP源地址必须使用Loopback地址，而不是物理接口地址。原因在于，如果使用物理接口地址作为隧道源，一旦该接口链路Down了，所有VXLAN隧道都会中断；而Loopback接口是逻辑接口，只要设备本身还活着，它永远可用。配合OSPF或BGP做ECMP（等价多路径）后，流量会在多条物理链路上负载分担，大大增强了网络的健壮性。

2.3 三个前面没说透的规划坑

坑一：VNI号和VLAN ID不能想当然地相等。VNI（VXLAN Network Identifier）是24比特的虚拟网络标识，VLAN ID是12比特的二层标识，二者作用域完全不同。虽然很多实验里习惯让VNI 100对应VLAN 100，但这纯属人为约定，不是协议要求。你要在脑子里明确区分：VLAN是终端接入交换机时的本地二层域，VNI是VXLAN隧道里的全局虚拟网络标识。

坑二：组播组地址的规划。如果采用组播模式做BUM流量（广播、未知单播、组播）的泛洪，需要给每个VNI规划一个组播组地址。这意味着Underlay网络必须开启PIM协议，配置复杂度直线上升。我的建议是实验里先用静态配置头端复制列表（Ingress Replication），让每个VTEP显式知道邻居VTEP的地址，绕过组播的配置，后续想深入再单独玩组播。

坑三：MTU问题。VXLAN封装会额外增加50字节左右的开销（外层IP头20字节，UDP头8字节，VXLAN头8字节，可能还有外层以太网头14字节）。如果物理链路的MTU是1500，那一个标准的1500字节以太网帧封装后就变成1550字节，超过物理链路的承载能力，流量会被丢弃。这个问题的排查极其隐蔽——小包能通，大包不通，ping一个1472字节的包就失败。实验里我建议把Underlay所有接口的MTU设为1600或9000，给封装留足余量。

3. 一步步敲出VXLAN分布式网关的核心配置

环境准备好之后，就进入正题。我不打算罗列所有设备的全部命令，而是挑出每台设备上最关键的配置片段，并解释每一段的作用。你把它们按顺序贴到设备上，就能复现整个实验。

3.1 第一步：Underlay路由先通

分布式网关的前提是VTEP之间三层可达。所以第一件事是把OSPF配起来，让Spine和Leaf的Loopback地址互相能通。Leaf-1上的关键配置如下（Spine和Leaf-2类似，只改IP）：

feature ospf interface loopback0 ip address 10.0.0.3/32 ip router ospf UNDERLAY area 0.0.0.0 interface Ethernet1/1 no switchport ip address 10.0.1.1/30 ip router ospf UNDERLAY area 0.0.0.0 no shutdown router ospf UNDERLAY router-id 10.0.0.3

这里有个细节：我在接口上同时配置了ip router ospf和router-id，让Loopback地址自动宣告进OSPF，这样其他Leaf就能通过OSPF学习到10.0.0.3/32这条主机路由。验证Underlay是否已经通了，直接在Leaf上ping对端Loopback：

Leaf-1# ping 10.0.0.4 source 10.0.0.3 64 bytes from 10.0.0.4: icmp_seq=1 ttl=253 time=0.899 ms

看到Reply就说明Underlay通了，这是后面所有VXLAN配置的基础。

3.2 第二步：配置NVE接口和VXLAN隧道

NVE（Network Virtualization Edge）接口是Nexus交换机上承载VXLAN隧道的逻辑接口，所有VXLAN封装和解封装都在这里发生。Leaf-1的配置：

feature nv overlay interface nve1 source-interface loopback0 member vni 100 ingress-replication protocol static peer-ip 10.0.0.4 member vni 200 ingress-replication protocol static peer-ip 10.0.0.4

解释一下这段配置的含义。source-interface loopback0告诉交换机用哪个地址作为VXLAN隧道源，前面说过必须用Loopback。member vni 100表示将VNI 100映射到这个NVE接口上，同时用ingress-replication协议静态指定对端VTEP地址10.0.0.4，意思就是"这个VNI的所有广播、未知单播、组播流量，都复制一份发给Leaf-2"。

这里还要注意一个对应关系：Leaf-2上必须同样配置VNI 100和VNI 200，并且peer-ip要指向Leaf-1的Loopback地址。VNI是全局标识，两端的VTEP必须都认可同一个VNI，隧道才能建立。如果Leaf-1配置了VNI 100而Leaf-2没配，两边永远协商不出隧道。

3.3 第三步：创建VLAN并绑定VNI

接下来是二层域映射。Leaf-1上创建VLAN 100和VLAN 200，并分别映射到VNI 100和VNI 200：

vlan 100 vn-segment 100 vlan 200 vn-segment 200 interface Vlan100 no shutdown ip address 192.168.0.254/24 fabric forwarding mode anycast-gateway interface Vlan200 no shutdown ip address 192.168.1.254/24 fabric forwarding mode anycast-gateway

这段配置里的fabric forwarding mode anycast-gateway就是分布式网关的精髓。它让Leaf-1和Leaf-2上的Vlan100接口在逻辑上共享同一个虚拟网关IP和虚拟网关MAC，终端不管从哪个Leaf接入，看到的网关都是同一个。这也是我之前强调的"网关MAC一致性"的落地点。

同时，还需要把连接服务器的物理接口加入VLAN：

interface Ethernet1/2 switchport mode trunk switchport trunk allowed vlan 100,200 no shutdown

服务器侧通过trunk口把带VLAN Tag的流量送到Leaf。如果服务器上的虚拟机分别属于VLAN 100和VLAN 200，那它们发出的流量就会在Leaf上被分别映射到VNI 100和VNI 200。

3.4 第四步：三层网关和路由打通

到这一步，VM-A（192.168.0.10）和VM-C（192.168.1.10）不能互通，因为VLAN 100和VLAN 200之间还没走三层。我们在Leaf-1上配置两条静态路由指向对端VTEP，意思就是"要访问另一个VNI的网段，请把流量封装进VXLAN发给对端VTEP"：

ip route 192.168.1.0/24 10.0.0.4

命令很简单，但它背后的逻辑值得展开说。Leaf-1从VM-A收到目的IP为192.168.1.10的数据包之后，先查询路由表，发现下一跳是10.0.0.4（Leaf-2的Loopback地址），于是把数据包做三层转发的同时，又根据192.168.1.0/24这个网段对应的VNI 200，在NVE接口上封装成VXLAN报文，通过Underlay网络发给Leaf-2。Leaf-2解封装后，再在Vlan200里二层转发给VM-C。整个过程对终端完全透明。

Leaf-2上的静态路由则相反，要把192.168.0.0/24路由到10.0.0.3：

ip route 192.168.0.0/24 10.0.0.3

配置到这里，整个分布式网关的骨架就完成了。你可以先做连通性测试：VM-A ping VM-C的192.168.1.10，应该能通。

4. 分布式网关实验的实测记录和排查套路

配置敲完之后，光看配置不验证是没有意义的。这一节我用实测输出说话，再分享我在这个实验里遇到的几个典型问题，以及完整的排查链路。

4.1 联通性测试逐条过

我先在VM-A上ping VM-B（同VNI同Leaf）和VM-C（跨VNI跨Leaf）：

root@VM-A:~# ping 192.168.0.20 PING 192.168.0.20 (192.168.0.20) 56(84) bytes of data. 64 bytes from 192.168.0.20: icmp_seq=1 ttl=64 time=1.11 ms root@VM-A:~# ping 192.168.1.10 PING 192.168.1.10 (192.168.1.10) 56(84) bytes of data. 64 bytes from 192.168.1.10: icmp_seq=1 ttl=63 time=0.890 ms

注意看TTL值：同VNI内ping，TTL是64，说明流量纯二层转发；跨VNI ping，TTL是63，说明经过了一次三层转发（Leaf-1充当网关），这正是分布式网关在工作。

再做一个更有意思的测试，在Leaf-1上查看MAC地址表和隧道信息：

Leaf-1# show mac address-table Vlan Mac Address Type Ports/Move ---- ----------- -------- ------------- 100 0050.0000.0101 DYNAMIC Eth1/2 100 0050.0000.0102 DYNAMIC Eth1/2 100 0050.0000.0201 DYNAMIC nve1 100 0050.0000.0202 DYNAMIC nve1 200 0050.0000.0301 DYNAMIC nve1 Leaf-1# show nve vni Codes: CP - Control Plane DP - Data Plane UC - Unconfigured SA - Suppressed ACK SU - Suppressed Unknown Unicast Interface VNI Multicast-group State Mode --------- --------- ------------------ ----- ---- nve1 100 0.0.0.0 Up DP nve1 200 0.0.0.0 Up DP

从MAC地址表可以看到，Leaf-1学到VM-A和VM-B的MAC都来自物理端口Eth1/2，而VM-C和VM-D的MAC来自nve1接口，也就是说Leaf-1通过VXLAN隧道学到了远端VTEP下的MAC。这说明二层桥接工作正常，VNI的映射也没毛病。

4.2 大包ping不过去的经典迷局

第一次实验时，我随便用默认包大小ping跨VNI地址是通的，但一测大数据传输就卡顿。后来才发现是MTU问题。具体排查过程供你参考：

1. 先用ping -s 1472测，发现通
2. 再用ping -s 1473测，发现不通
3. 对比1472和1473这两个数字，1472 + 28（ICMP头8字节 + IP头20字节）= 1500，正好是物理MTU。1473 + 28 = 1501，超过物理MTU，但因为VXLAN封装还需要额外50字节，所以实际能扛的最大payload是1500 - 28 - 50 = 1422字节
4. 结论：Underlay MTU必须加大

解决办法是把设备物理接口和服务器网卡的MTU统一改成9000，同时保证虚拟机的虚拟网卡MTU也同步调整。这样才能避免VXLAN封装后超过底层承载。很多生产事故的根源就在这里。

4.3 网关MAC飘移引发的配置复盘

实验里我碰到过一个问题：VM-A第一次ping网关192.168.0.254通了，等一段时间再ping，突然不通。排查后发现Leaf-1和Leaf-2上Vlan100的MAC地址不一致——Leaf-1配置了anycast-gateway，但Leaf-2漏配了fabric forwarding mode anycast-gateway，导致Leaf-2的Vlan100 MAC是它自己生成的，VM-A的ARP缓存里记录的还是Leaf-1的MAC，当流量经过Leaf-2的网关时，目的MAC对不上，直接被丢弃。

这个问题的排查过程很有价值：

VM-A:~# ping 192.168.0.254 PING 192.168.0.254 (192.168.0.254) 56(84) bytes of data. --- 192.168.0.254 ping statistics --- 3 packets transmitted, 0 received, 100% packet loss VM-A:~# ip neigh 192.168.0.254 dev eth0 lladdr 0050.0000.8888 REACHABLE

VM-A的ARP表里，网关MAC是0050.0000.8888，而Leaf-1上Vlan100的MAC却是0050.0000.7777，明显不一致。处理方式就是让两端都启用anycast-gateway，然后用同一个虚拟MAC。重新配置后，再看两端Vlan100的MAC地址就一模一样了。这就是分布式网关"看起来简单、细节藏得深"的典型体现。

4.4 一个实用的分层排错顺序

最后分享我的排错习惯。VXLAN网络出问题，我不会一上来就看抓包，而是按下面这个顺序逐层排查：

• 第一层：Underlay连通性。Leaf上ping对端Loopback地址，如果不通，查OSPF邻居状态
• 第二层：NVE隧道状态。show nve vni看VNI是否Up，show nve peers看对端VTEP是否在线
• 第三层：二层表项。show mac address-table看远端MAC是否从nve1口学到
• 第四层：三层路由。show ip route看远端VNI网段的路由是否存在
• 第五层：终端侧。查VM的IP配置、ARP缓存和默认网关

这套顺序很像盖楼从地基往上查，每一步依赖上一步。大多数VXLAN问题，只要Underlay正常、NVE状态Up、路由表也正确，最终都能定位到某个配置细节上。

5. 实验做完之后的进阶方向和几点真话

如果你已经成功复现了上面的实验，说明你已经掌握了VXLAN分布式网关的核心逻辑。接下来有几个方向可以继续深挖，每个都值得单独开篇写文章，我先简单提一下。

5.1 从静态配置走向BGP EVPN

我实验里用的是ingress-replication协议静态指定对端VTEP，这种方式配置简单，但不具备自动发现和自动学习能力。生产环境里，VXLAN通常搭配BGP EVPN（Ethernet Virtual Private Network）使用。EVPN通过BGP协议在VTEP之间通告MAC地址和路由信息，取代了数据平面泛洪学习的方式，收敛速度更快，还支持多活网关、水平分割等高级特性。把这两者结合起来，才是数据中心里真正的主流方案。

从实验角度，你可以在现有拓扑上把OSPF Underlay换成BGP，再增加EVPN地址族配置，看看MAC地址表从"动态学习"变成"通过BGP邻居学习"的过程，理解为什么EVPN被称为"控制平面"而VXLAN被称为"数据平面"。

5.2 数据库式对比：集中式网关和分布式网关

我把两种方案的关键特性做了个对比表，方便你记住差异：

做实验的时候，你完全可以人为把集中式网关设备关机，对比一下两种方案的故障表现。我敢说，体验过分布式网关的恢复速度之后，你绝不会再想回到集中式时代。

5.3 最后说几句实在话

这个实验看似只是几条命令，但背后涉及的几个概念——Overlay与Underlay的区分、控制平面与数据平面的关系、Anycast Gateway的作用——都是网络虚拟化领域的基石。我建议你做完实验后，把每个命令都问一遍"为什么"。比如为什么VNI要用24位而不是16位？为什么Underlay要跑OSPF或BGP？为什么网关MAC必须一致？能把这几个问题用自己的话讲清楚，你才算真正吃透了VXLAN分布式网关。

另外提一句操作上的小经验：所有配置命令建议先在文本编辑器里写好，再批量粘贴到设备上，尽量避免逐条手敲。Nexus的配置一旦敲错，比如VNI没匹配、接口没no shutdown，排查起来特别耗时间。我第二次做这个实验时，全程半小时搞定，就是吃了预习命令的亏。

希望这篇实验笔记能帮你推开通往VXLAN的大门。做完实验再回头去看BGP EVPN、VPC、多租户这些内容，你会发现所有知识点都能串成一条线，那种感觉，比单纯背命令痛快多了。