VxLAN网络虚拟化详解：从VLAN困境到EVPN控制平面与排障实践

第一次接触VxLAN的时候我是有点懵的。查到的资料几乎都写着“VxLAN是一种网络虚拟化技术一种基于IP网络之上的二层虚拟网络”字都认识拼起来就是不清楚它到底解决什么问题。后来在某数据中心改造项目里我一边被业务催着上线一边把VxLAN的报文抓下来逐字节看才把它彻底弄明白。这篇文章不按教科书来我按自己实际理解过的顺序讲为什么网络非要搞出个VxLAN、它的封装原理是什么、报文到底怎么走、控制平面为什么要靠EVPN、部署时会踩哪些坑、出故障从哪下手查。适合刚接触网络虚拟化的运维也适合被4096个VLAN逼到挠头的网络工程师看完能理解隧道封装机制也能建立一套自己的排障思路这篇就算达到目的了。1. 为什么传统VLAN不够用了VxLAN诞生前夜1.1 4096个VLAN ID在云面前只是零头先说最直接的痛点。VLAN ID字段是12位所以整个标准体系里可用VLAN只有1到4094也就是4094个逻辑隔离网络。十几年前一个企业园区网可能用几十个VLAN就够了确实没问题。可现在光一个机房里虚拟机数量多的时候一个物理网口上就可能要承载几十个租户每个租户又分成不同安全域、不同业务网段。往少了算100个租户各分10个VLAN就已经破千了。云平台场景下物理网络中会轻易出现VLAN ID不够分、只能在多个地方复用VLAN导致配置混乱的情况。这还没提到VLAN本身的转发机制。VLAN依赖生成树协议STP做环路防护为了防止广播风暴STP会把冗余链路直接阻塞掉。结果是二层网络越大被堵住的端口越多链路利用率越低收敛时间也越长。几千台服务器的数据中心如果想用传统VLAN做一个大二层光STP的收敛和广播域爆炸问题就够运维喝一壶。所以VxLAN的出发点就是VLAN不够用而且二层跨不过三层设备。这句话基本把VxLAN起源的80%逻辑说完了。1.2 虚拟机搬家不能换门牌号大二层需求再说一个在云平台、虚拟化环境里极其现实的需求虚拟机热迁移。虚拟机从物理机A迁到物理机B时IP地址和MAC地址必须保持不变否则正在跑的连接会瞬间断开。这就意味着A和B必须位于同一个二层网络里。传统园区网里两台物理机如果跨了三层路由虚拟机迁过去就失效。过去很多虚拟化项目只能把几千台物理机强行塞进一个大二层用堆叠、M-LAG这类技术硬撑但堆叠也有边界跨机房、跨地市堆叠根本拉不过去。二层网络本来理解起来很简单但一旦要跨三层运行“广播域”就成了一个个孤岛。你要么在每个孤岛之间做个透传的二层隧道要么干脆定义一种新的封装让二层的帧可以被三层的网络当作普通IP报文一路送到远方。VxLAN走的就是后一条路。大二层需求不只在虚拟化迁移里出现很多分布式数据库、存储集群也要求所有节点二层可达。过去只能用VLAN硬切、用STP硬撑现在VxLAN把二层广播域从物理位置和STP限制里解放了出来。1.3 多租户隔离的钥匙VNI的野心VLAN是12位那VxLAN把隔离标识设计成多少位24位。2的24次方大约是1677万个也就是VxLAN网络最多可以有约1600万个独立虚拟网络。就算一个超大型云平台上挂了上万个租户每个租户再拉出几百个子网VNI也完全够用。这其实是“网络虚拟化”的精髓物理设施是共享的逻辑隔离是彻底的。每个VxLAN网络用一个VNI标识自成一个广播域租户A的网络不会感知到租户B的存在哪怕它们的虚拟机邻居就插在同一台TOR交换机上。给不熟悉的读者翻译一下VLAN是给交换机端口上的二层报文贴一张号码牌告诉大家它在哪个房间VxLAN的VNI相当于在每个报文的“信封”上写一个房间号而且这个信封可以在三层网络上寄到任何地方。房间号从几千个变成了千万级这就是VxLAN一出生就面向云时代的底气。2. VxLAN核心设计把二层报文装进三层信封2.1 MAC-in-UDP封装的四个层次VxLAN的正式名字是Virtual eXtensible Local Area NetworkRFC 7348里定义了它。理解VxLAN最关键的一步是看明白它的封装格式。一个普通以太网帧从里到外大概是目的MAC、源MAC、类型、IP头、四层头、数据。VxLAN封装后变成外层以太网头源/目的MAC 外层IP头源/目的VTEP IP UDP头 VXLAN头VNI 内层原始以太网帧业务真正的MAC/IP/报文“MAC-in-UDP”这个说法指的就是把业务原始的内层以太网帧整个当作数据载荷包进一层新的UDP报文里。对底层网络来说它看到的只是一个普通的IP报文什么MAC地址、VLAN标签它一概不关心。为什么加这么多头外层IP头负责把报文从源VTEP路由到目的VTEPUDP头负责标识这是VxLAN流量并且携带端口号VXLAN头里最关键的就是24位的VNI。整段额外开销加一起是50字节左右这也是后面MTU问题频繁出现的根源。这里要特别强调的是内层报文里仍然保留着完整的业务VLAN和MAC地址。VxLAN不会替代VLAN它更像把VLAN这颗“糖豆”装进一个更大的“糖纸”里糖豆本身没变糖纸决定了它要被寄到哪里。2.2 四个必须记住的名词VTEP、VNI、Underlay、OverlayVTEPVxLAN Tunnel End Point隧道端点干封装/解封装的活。可以是网络交换机上的一个逻辑接口也可以是服务器里的虚拟交换机。每个VTEP都有一个唯一的IP地址作为隧道的源和目的。VNIVxLAN Network Identifier虚拟网络标识类似VLAN ID但是24位值范围0到1677万。VNI相同的VTEP之间才算同一个Overlay二层网络。Underlay承载VxLAN封包的底层IP网络要求是IP路由可达可以是OSPF、BGP跑起来的任何三层网络。Overlay由VNI定义的逻辑二层网络跑在Underlay上面业务看到的就是这个虚拟网络。这四个词很容易记混。我的理解方法是Underlay是路网Overlay是车上的导航地图VTEP是上下高速的收费站VNI是导航地图上画的每一条“路线编号”。路网本身不关心车里拉的货是什么它只管把封装好的集装箱车送到收费站。2.3 为什么外层选UDP而不是TCP如果用TCP做VxLAN封装TCP要维护连接状态、做重传和拥塞控制一旦底层网络抖动TCP重传会让整个隧道吞吐骤降。而且TCP重传的报文本身又是封装过的重传成本直接翻倍。VxLAN的本意是承载在任意三层网络之上的尽力而为隧道所以选择无连接的UDP最合适。另外UDP有一个很巧妙的设计源UDP端口号由内层报文的五元组做哈希生成。这样每个业务连接对应的VxLAN隧道在经过Underlay交换机做负载均衡时ECMP会把不同连接的UDP流分到不同物理链路上实现较细粒度的负载均衡。如果用一个固定源端口所有VxLAN流量在Underlay里只会走同一条ECMP路径链路利用会很不均衡。VxLAN默认使用的UDP目的端口是4789这个值在抓包时经常见到。如果你在自己抓包软件里看到UDP 4789别怀疑那就是VxLAN隧道报文。3. 一台云主机发出的报文在VxLAN里经历了什么3.1 同VNI内互通从VM到VM的完整链路假设VM A在Leaf1下面VM B在Leaf2下面两个VM属于同一个VxLAN网络VNI 1001叶子交换机上配置了分布式网关Underlay路由协议已经让Leaf1和Leaf2能通过loopback地址互达。第一步VM A要发数据给VM B先发ARP请求问“谁有VM B的IP对应的MAC”。这个ARP广播在VNI 1001这个广播域里泛洪VTEP收到BUM流量后要么通过组播或者头端复制发给所有属于VNI 1001的远端VTEP要么在EVPN环境下利用控制平面已经把MAC信息同步好的优势做ARP代理直接把VM B的MAC回给VM A。第二步VM A知道自己该把帧发到VM B的MAC后把普通以太网帧发出。Leaf1收到之后查看自己的转发表内层目的MAC对应的远端VTEP IP是Leaf2于是把整个帧封进VxLAN头加新IP头源IP写Leaf1的VTEP地址目的IP写Leaf2的VTEP地址发往Underlay。第三步Underlay网络只根据外层目的IP做路由转发它看不到内层的VM MAC。报文到达Leaf2后Leaf2根据VNI去掉外层封装还原出原始的二层帧转发给VM B。对于VM A和VM B来说它们感觉不到中间的隧道以为是同一台交换机上的两台设备在直接通信。这个过程最反直觉的地方就在这里中间所有路由器都在转发“外层信封”只有隧道两端的VTEP才拆开信封看“内容”。3.2 BUM流量广播、未知单播、组播的宿命二层网络里广播是免不了的VxLAN延续了这一点。同一个VNI下的所有VTEP天然是一个广播域所以当某台VM发出广播帧这个帧必须被复制发送到所有在同一个VNI下的远端VTEP。实现方式有两种常见路径。一是依赖Underlay组播给每个VNI映射一个组播组VTEP加入对应组BUM只发给组成员。这种模式高效但前提是Underlay网络支持并配置了组播路由协议很多传统网络根本没有开组播的能力部署链路长、排障难。二是头端复制源VTEP自己把BUM帧复制N份分别单播封装给每个远端VTEP。这样Underlay不需要组播但源VTEP的CPU和带宽压力很高VTEP一多就容易成为瓶颈。EVPN之下BUM通常通过Type-3路由自动构建泛洪域把“谁该收到广播”这个事交给控制平面泛洪范围收敛得很干净。很多新建数据中心直接用EVPN加头端复制因为Underlay只需要普通IP可达组播组和PIM的复杂度直接被绕开了。但要注意如果VNI下的VTEP数量很大头端复制的复制份数同样会很大BUM流量本身还是要控制住该做ARP抑制的一定要做。3.3 跨VNI通信网关该放在哪里同一VNI内VTEP做个封装就能通。不同VNI之间也就是不同子网之间需要三层网关。VxLAN的网关设计和传统园区完全不同。集中式网关把所有VNI的三层网关放在一对核心设备上所有跨子网流量全部绕到核心再回来。好处是配置清楚排障简单坏处是大二层边缘设备会复用核心设备的链路流量路径会走很多冤枉路核心链路带宽压力大。小规模组网或者早期VxLAN项目里很常见。分布式网关把网关下沉到每个Leaf也就是每个VTEP同时兼任网关。为了实现终端网关配置不区分物理位置设备会启用Anycast网关所有Leaf上的相同VNI网关IP一样网关MAC也一致不管VM连在哪台Leaf上它的默认网关都是同一个“逻辑地址”。报文到达本机Leaf就能完成三层转发不用绕路去核心。选型上没有绝对好坏。几十台服务器的小环境用集中式完全够几百台往上的云平台、多机房互联分布式网关基本是标准选择。分布式网关还有个额外的好处流量从VM到Leaf就能直接三层终结East-West流量不再需要经过核心转发时延和路径都干净很多。4. 控制平面EVPN才是VxLAN真正好用的原因4.1 手工静态VxLANMAC表靠泛洪喂VxLAN刚出来那会儿控制平面很简单VTEP之间手动配置VNI的映射也就是静态VxLAN。这种模式下VTEP怎么知道哪个远端VTEP下有哪个MAC办法很粗暴只要收到VNI相同的BUM流量就把MAC学进转发表来回多交流几轮MAC表也就慢慢“喂”出来了。听起来好像也能跑但问题很现实。新的VTEP加进来所有老VTEP都要手工加配置一台远端VTEP下线MAC老化、收敛速度慢丢包就在所难免。规模一上去配置量按VTEP数量的平方增长。上百台设备时排障就已经靠人肉核对更不用提自动化。所以静态VxLAN只适合两条VTEP、一个实验网的小规模验证场景。生产环境想上规模控制平面必须交给协议自己玩。4.2 BGP EVPN控制平面核心Type-2和Type-3路由EVPN全称Ethernet VPN本质上是用BGP在VTEP之间交换MAC地址、IP地址和VNI归属信息。BGP本来就是在海量路由之间做选路和通告的专家借它当控制平面VxLAN的自动化程度一下就上来了。经常听到的两个概念Type-2路由和Type-3路由。Type-2是MAC/IP通告路由当某个Leaf学习到一个VM的MAC和IP它会生成一条Type-2通过BGP通告给其他Leaf并带上VNI和下一跳信息下一跳就是该Leaf的VTEP地址。这样所有Leaf都能预先知道“这个MAC在哪台VTEP下面”不需要靠泛洪去现学。Type-3是Inclusive Multicast路由作用是把同一个VNI下所有VTEP的“泛洪域成员”信息同步掉。当Leaf要发BUM流量时根据Type-3的邻居列表执行头端复制该发谁发谁不会漏也不会乱发。有了EVPN之后新增一个Leaf接入网络只需要把它加入BGP EVPN邻居配置好VNI它就会自动从邻居学习到所有相关的MAC地址和VNI成员关系。当年静态VxLAN需要手工一台一台指的麻烦在这里变成了一次性建立邻居的过程。4.3 EVPN带来的额外福利多活路径和ARP抑制EVPN还顺手解决了两件传统二层网络最头疼的事环路和收敛。传统大二层用STP防环链路被阻塞流量只能走单条路径。EVPN利用BGP的跨域能力和ECMP能力可以让同一个VNI的多条VTEP转发路径同时生效形成多活路径。广播域还是那一个但转发资源不再被浪费。另外ARP洪泛也被大幅抑制。因为EVPN已经同步了MAC/IP信息Leaf收到VM的ARP请求时可以直接查本机的EVPN表回答不必每次都广播到远端。这对几千台虚拟机规模的集群副作用改善非常明显。如果让我做个类比静态VxLAN像手写通讯录完整但过时EVPN是云端通讯录自动同步新名片到群自动分发。控制平面是不是自动是VxLAN能不能上生产的最重要分界点。5. 写配置前先看这几个坑VxLAN部署避坑实录5.1 MTU不调大包疯狂丢失这是新手部署VxLAN后遇到的第一个奇怪现象小包能通打开网页慢传大文件直接卡死。原因就是VxLAN封装增加了约50字节而Underlay路径上的物理接口MTU往往还停留在1500。隧道报文超过1500就会被丢弃或分片分片后的重组在隧道场景里又容易出问题。两种调整思路要么把Underlay所有物理接口MTU调到1550以上比如1550、1576都有人用让封装后的报文放得下要么把业务侧的MTU调小例如云主机网卡MTU设置成1450留出封装余地。很多云平台在VM里看到网卡MTU是1450原因就在这。判断是不是MTU问题的标准动作在VM里ping对端VM不加分片。能通而默认载荷大小不通基本就是Underlay的MTU小于1550调完再测一遍。注意整条路径上的所有设备都要调一致只调一端没用。5.2 泛洪模式选错组播风暴砸晕Underlay有些设备默认把VxLAN BUM流量映射到Underlay组播如果你跑在一条没有启用组播路由协议的链路上这些组播组根本传递不起来表现为VxLAN网络里ARP总是失败、广播收不到。而一旦配置了组播但组地址选得不好多个VNI挤在同一组里广播风暴会把Underlay的节点全部打满。我的建议是只要能上EVPN控制平面就别依赖组播。用Type-3做头端复制的成员同步泛洪只发生在必要的VTEP集合Underlay继续跑纯路由协议。这让故障域收敛到“哪些VTEP在同一VNI”而不是全网范围的组播问题。5.3 VLAN到VNI映射错乱租户串门VLAN和VNI是两个层面的东西业务接入时才需要把它们绑定。很多部署里有个隐蔽坑同一台Leaf上租户A的VLAN被映射到了租户B的VNI。结果是报文封装时VNI带错租户A的流量在别家租户的网络里出现既不安全也不可查。建议每个VNI编号在运维侧提前规划成可读的形式比如VNI前几位对应租户后几位对应网段并做好绑定映射文档。每次上线新业务时重点核对Leaf上的VLAN/VNI绑定表和VTEP来源地址避免手滑。5.4 网关放错位置流量绕远路集中式网关如果放在核心跨VNI流量全部要绕到核心再回来。在数据和存储流量混合的大环境下这种绕行会放大延迟和故障面。而且一旦网关设备出现故障所有跨VNI通信全断。分布式网关是更稳的选择但也有额外要求所有Leaf上的网关IP、MAC必须完全一致Anycast网关配合EVPN的同步机制才能工作。如果某台Leaf上的网关配置和别人不一样就会形成“漂移”终端流量到了这台Leaf找不到网关出现间歇性不通。我见过排查两天没头绪的案例最后发现就是某台Leaf的网关MAC写错了。6. 排障速查进不去不通大包不通从三件事查起6.1 从Underlay还是Overlay开始VxLAN故障排查看起来吓人实际顺序可以归纳成一个原则先underlay后overlay。先确认VTEP源地址一般是loopback地址在Underlay里是通的ping VTEP源IP、traceroute看路径。不通就先查路由、物理链路、防火墙规则。这里要提醒VTEP源IP最好用loopback别用物理接口IP否则链路抖动会直接影响隧道状态。Underlay通了再查Overlay隧道状态、VNI映射、MAC表。很多VxLAN故障的根子其实在Underlay路由不完整比如缺少一条回程路由表现为“出方向通、回不来”。6.2 大包MTU与转发问题的判断组合拳MTU问题的排查前面已经说了一半这里补一个实用组合拳业务VM之间先ping判断Overlay端到端是否从小包变正常。再到Leaf上做源或目的地址为VTEP IP的ping大包看Underlay是否只到某个中间设备就断了。如果大包能通但业务还是卡就要抓包看是否出现分片、是否丢在特定设备多半是沿途某接口MTU不一致。这个组合拳能区分“是Underlay路由断了”还是“只是MTU挡路”。很多网络值班同事看到VxLAN设备名就头大其实把这两步做完60%的问题都能定位到具体接口。6.3 常见排查动作速查表现象优先检查关键动作常见根因小包通、大包断MTUping大包对比Underlay接口MTU未调封装后超1500某租户互访不通VNI/VLAN映射核对绑定表VLAN映射错VNI或VNI不一致跨VNI不通网关配置查看所有Leaf网关IP/MACAnycast网关不一致、缺网关广播风暴BUM泛洪模式检查Type-3/组播成员组播模式无PIM / 头端复制压力大隧道状态downUnderlay连通ping VTEP源地址路由不全、防火墙、接口down排查命令这块不同品牌差异大但思路一致设备上一定要看三类信息——隧道摘要VTEP邻居状态、VNI表VNI与VLAN映射、学习到的MAC数量、EVPN邻居BGP会话状态、收发的路由条目。先看邻居状态和VNI表再往上追具体MAC基本能按“隧道层—映射层—MAC层”三层定位到问题。回头说点个人感受。VxLAN这个名字乍一听劝退但拆开来的每个部件都是网络里司空见惯的东西MAC地址、IP路由、UDP封装只是把它们组合成了一个新玩法。我在实际项目中踩过的最大一个坑是太早盯着Overlay的封装细节反而忽略了Underlay的路由与MTU结果浪费了整整一个下午在隧道状态上打转。后来养成的习惯是无论问题表现多像VxLAN先确认VTEP之间路由通、MTU够再去看VNI和MAC表。这个排障顺序帮我把VxLAN故障定位时间压缩了不少。如果你正准备在项目里引入VxLAN我的建议是从小规模静态VxLAN开始验证封装和转发逻辑等真正上生产再切EVPN控制平面。把这两步分开走理解会扎实很多踩坑也会少很多。