从某天深夜开始我的工作群里突然炸了锅某个跨机房的业务系统出现间歇性不通虚拟机迁移后全网段丢包底层物理网络看起来一切正常ping网关也通但业务就是像被什么东西掐住了脖子。我第一反应不是重启任何服务而是抓起抓包工具在宿主机上看了一眼问题瞬间清晰——overlay网络里的VXLAN报文长得完全不符合预期内层MAC表也是一团乱麻。这正是VXLAN协议最折磨人的地方它在物理网络上又套了一层虚拟网络数据包在传输时要经历“外层封装内层解封装”两道工序任何一个环节出了偏差外表看可能毫无痕迹内里却早已乾坤颠倒。这篇文章就围绕Wireshark分析VXLAN协议这条主线把虚拟扩展局域网的核心原理、报文结构、过滤技巧、排障思路全部摊开讲。适合三类人看一是刚接触overlay网络、只听过VXLAN但没见过真实抓包的网络工程师二是要在云平台或虚拟化环境里排查“诡异不通”问题的运维老手三是准备面试、想深入理解封装细节的进阶学习者。读完你会知道怎么在Wireshark中迅速定位VXLAN流量怎么一眼看懂外层IP、UDP和八字节VXLAN头怎么通过过滤器缩小排查范围更重要的是掌握一套能直接复制的抓包分析方法论。1. 内容整体设计与思路拆解1.1 为什么要折腾VXLAN而不是直接拉线传统二层网络的设计很简单交换机靠MAC地址表转发帧广播靠广播域扩散一切都在同一个物理局域网内完成。问题在于数据中心一旦大到要跨楼栋、跨园区甚至跨地域二层网络的扩展性就捉襟见肘。STP要砍掉冗余链路VLAN只有4094个编号MAC表规模受限于交换机硬件带宽利用率也因为环路阻断大打折扣。云平台要的是成千上万台虚拟机可以像在同一台交换机上一样自由迁移、随意组网传统VLAN根本扛不住这种规模。VXLAN的解决思路非常巧妙它不直接扩展二层网络而是把二层以太网帧封装进四层UDP报文里再透过底层IP网络传输。通俗点说就是把原来只能在“同一根网线”上跑的以太网帧塞进一辆可以在任意IP网络中行驶的“货车”到了目的地再拆开外包装还原成原始以太网帧。因为UDP报文可以正常跨三层路由VXLAN理论上可以跨越任何IP可达的网络边界同时通过24位的VNI字段提供超过1600万个虚拟网络标识彻底摆脱4094个VLAN的束缚。这个设计既保留了二层的灵活性又借助三层的成熟路由和ECMP能力实现了大范围扩展是当前主流云平台网络虚拟化的基石。1.2 Wireshark看VXLAN的优势和拆解路径Wireshark对VXLAN的支持在近几个版本里已经相当成熟。它不仅能根据UDP目标端口4789自动识别VXLAN流量还支持手动“解码为”强制重解析遇到非标准端口比如某些虚拟化平台默认用8472也能从容应对。更重要的是Wireshark会把外层以太网、外层IP、外层UDP、VXLAN头、内层以太网帧逐层展开像是剥洋葱一样把完整报文结构呈现在面板上。你不需要自己手工去计算偏移量、逐个字节解读十六进制内容一切都在GUI里直观展示。然而工具再强大也替代不了思维方式。分析VXLAN数据包时需要时刻区分“外层”和“内层”外层头属于承载网络解决的是“报文从哪里到哪里”的问题内层帧属于租户网络解决的是“虚拟机/容器之间如何通信”的问题。排查问题首先要判断问题出在哪一层才能决定该盯着外层路由还是内层MAC地址。如果思路不清抓了一堆包也只是看到一堆乱码无法转化为有效判断。2. 核心细节解析与实操要点2.1 VXLAN报文封装结构逐字节拆解拿到一个VXLAN报文Wireshark会从上到下显示四层结构。第一层是外层以太网头依次包含目的MAC、源MAC和可选的802.1Q VLAN标签。这一层主要用于物理网络上相邻设备之间的帧传输目的MAC通常是下一跳网关或者远端VTEP的MAC。第二层是外层IP头源IP是本地VTEP的IP地址目的IP是远端VTEP的IP地址它决定了这个报文在底层网络里怎么路由。第三层是外层UDP头其中源端口不是随机分配的而是通过对内层以太网帧做哈希计算得出的范围通常在49152到65535之间。这个设计意图很实用底层网络做等价多路径负载均衡时需要依据哈希因子来分流如果所有VXLAN报文的源端口都固定不变那么所有流量都会挤在同一条链路上。第四层就是VXLAN头本身一共8个字节。第一个字节是Flags标志位一般取0x08表示I位VNI有效标志置1其余位保留为0。接下来的24位是保留字段必须全0。再接下来是24位的VNI也就是VXLAN网络标识符取值范围从0到16777215。最后一个字节也是保留字段。Wireshark在Packet Details面板里会细致地把这些字段展开标示比如“VXLAN Network Identifier (VNI): 100”一眼就能知道报文属于哪个虚拟网络。报文最里层是完整的内层原始以太网帧。它包含源MAC、目的MAC也可能是VLAN标签以及上层的IP报文、甚至TCP/UDP载荷。接收端VTEP收到外层报文后会检查VNI和目的MAC做相应的VXLAN解封装再把原始二层帧从对应的虚拟网络中转发出去。2.2 Wireshark识别VXLAN的端口逻辑与手动解码技巧Wireshark判断一个UDP报文是不是VXLAN主要依据是UDP目标端口。IANA分配的VXLAN标准端口是4789Linux内核VXLAN模块默认也监听这个端口。但实际环境里并不总是这么标准某些虚拟化平台为了避免与现有网络服务冲突会把默认端口改成8472有些交换机的VXLAN硬件网关也会用其他端口。遇到这类非标准端口Wireshark默认不会主动解析把它当成普通UDP数据对待内层内容就完全看不到了。解决办法有两种。第一种是一劳永逸地修改Wireshark的配置在“Preferences” - “Protocols” - “VXLAN”里把默认端口改为实际使用的UDP端口可以填多个端口用逗号分隔。第二种是只针对单个捕获文件临时处理选中任意一条UDP报文右键选择“Decode As”在弹出窗口里把该UDP端口的协议强制指定为“VXLAN”改动会立刻生效当前打开文件的全部流量都会按新规则重新解析。这个方法在排查别人提供的pcap文件时特别有用不需要动全局配置就能快速验证推测。一个小提醒如果设备使用的是VXLAN-GPEGeneric Protocol Extension也就是IETF定义的VXLAN头扩展版本需要把解析协议改成“VXLAN-GPE”而不是标准VXLAN。VXLAN-GPE在头部的Flags字段里追加了Next Protocol字段用于指示内层载荷类型是IP、以太网还是其他协议。用错解析器会导致内层信息被完全误读这个坑我在现场踩过排查了半天才发现是解析协议选错了。2.3 核心过滤器与显示列配置抓包只是第一步面对成千上万条数据包纯粹靠肉眼滚动翻找的效率极低。Wireshark的显示过滤器能精准锁定VXLAN流量以及特定虚拟网络内的报文以下是我日常使用频率最高的几条过滤表达式vxlan显示所有被识别为VXLAN的报文。这条过滤器也可以写作udp.port 4789但如果端口被手动改过建议优先使用vxlan这个协议名它会覆盖所有当前被解析为VXLAN的UDP报文。vxlan.vni 100只看VNI等于100的虚拟网络流量。这个条件在定位“某个租户网络异常而其他网络正常”的场景中极其好用一条命令就能把目标流量从海量数据包里拎出来。vxlan ip.addr 192.0.2.10同时匹配VXLAN报文和外层或内层IP地址。注意ip.addr是包含条件它在Wireshark的匹配逻辑里会同时检查外层IP和内层IP只要任意一个匹配就算命中。如果你只想匹配外层源IP必须写成ip.src 192.0.2.10只想匹配内层目的IP需要写成ip.dst 192.0.2.10。这个细节很多人忽略排查时容易把不属于目标链路的数据包误纳入范围。vxlan eth.addr 00:16:3e:05:03:01按内层MAC地址过滤。用于追踪某一台虚拟机发出的流量尤其是在多租户共享同一VTEP的场景中这个过滤器能很快定位到单一虚拟机的通信行为。除了过滤器我还会自定义Wireshark的显示列。默认的Protocol列对VXLAN报文一律显示为“VXLAN”但如果想知道这个报文具体属于哪个虚拟网络需要额外添加一列显示VNI。操作步骤是右键点击Packet Details面板中的VNI字段选择“Apply as Column”该字段就会成为表格中的独立一列。再把外层源IP、外层目的IP、内层源MAC、内层目的MAC也分别作为列展示一张完整的VXLAN流量视图就出来了。按照外层源目IP、VNI、内层MAC的顺序去审视流量特征很多问题不看载荷就能猜个八九不离十。3. 实操过程与核心环节实现3.1 抓包点选择与抓包准备VXLAN报文通常不是直接出现在业务虚拟机里的它的封装和解封装都发生在VTEP上。VTEP的形态可能是物理交换机、虚拟交换机也可能是宿主机内核里的VXLAN模块。因此抓包点选择直接影响能否抓到有意义的数据。如果VXLAN终端是宿主机最直接的抓包方式是在宿主机的物理网卡上抓取这样能看到完整的外层封装报文如果在虚拟机内部直接抓包一般只能看到内层原始以太网帧因为虚拟交换机已经把外衣脱掉了。排查“VXLAN隧道建立正常、但内层通信异常”的问题时两边的包都必须抓宿主机物理口看外层封装的完整过程虚拟机内部确认内层业务报文是否正常到达两相对照才能定位脱节环节。抓包时要开启promiscuous混杂模式以免网卡过滤掉目标MAC不是本机的数据包。尤其是抓VXLAN报文时外层目的MAC可能是远端网关而非本机MAC如果没开混杂模式很可能一条VXLAN包都抓不到。命令行抓包可以用tcpdump指定端口和特定主机tcpdump -i eth0 -nn host 192.0.2.10 and udp port 4789 -s 0 -w vxlan_capture.pcap-s 0表示抓取完整包长避免截断导致内层信息不完整。抓包文件事后用Wireshark打开分析即可这样既能在现场快速定位又能在工位上慢慢复盘。3.2 完整分析流程从外层到内层追踪一次跨节点通信为了讲清楚完整分析思路我构造一个典型场景虚拟机A在计算节点1上虚拟机B在计算节点2上两个节点都配置了VXLAN网络VNI为100两个节点之间的物理网络为三层可达。现在虚拟机A ping虚拟机B我们在节点1的物理网卡上抓包通过Wireshark观察完整数据流。抓到数据后第一步先用过滤器vxlan.vni 100锁定目标流量。这时Packet List里应该能看到大量UDP报文颜色通常会被标记成浅紫色Wireshark默认的UDP颜色。点击任意一条报文Packet Details面板从上到下依次是外层的Ethernet II部分显示宿主机的MAC地址到对端物理IP网关的MAC地址。这里要确认外层目的MAC是否是下一跳设备的MAC。如果这是一个跨网段环境目的MAC应该是路由器或网关的MAC而不是远端VTEP的MAC。若目的MAC填了远端VTEP的MAC但两台主机不在同一个二层网络这个报文会在转发途中被丢弃非常典型的错误。外层IP部分确认源IP是本地VTEP目的IP是远端VTEP。很多配置问题都出在这一段源IP填了管理IP而不是隧道IP或者目的IP是虚拟机的“虚拟IP”而不是VTEP地址。一个快速判断方法是看这条UDP流量的源和目的地是否为物理网络中真实存在的三层接口地址。如果出现192.168.x.x这种明显属于内层规划的地址出现在外层说明隧道封装配置错了。外层UDP的源端口会是一个高位随机端口。把多条同一条流的报文展开对比可以发现源端口通常是固定值源端口是同一个值是因为同一虚拟机到同一目的虚拟机的内层五元组没变哈希结果自然稳定。如果不固定说明哈希计算输入里包含随机因素这可能影响底层网络的负载均衡效果。VXLAN头里重点看两个字段Flags是否为0x08以及VNI是否为100。如果Flags的I位没置1接收端可能不识别VNI报文视为无效丢弃如果VNI不是100可能抓到了别的租户的流量。接下来的内层以太网帧部分检查源MAC是否为虚拟机A的MAC目的MAC是否为虚拟机B的MAC或网关MAC。然后看内层IP源IP是虚拟机A的IP目的IP是虚拟机B的IP。到了这一步整个路径的通断判断就清晰了只要封装正确、外层路由可达、内层目标地址明确报文理应被远端VTEP解封装后转发给目标虚拟机。在真实环境中常用方法是通过“跟随TCP流”或“显示IP对话”来把一次完整交互的所有报文聚合在一起。比如ping测试选择ICMP协议的报文数一下有没有请求和响应成对出现。如果只看到请求没有响应说明响应报文要么在远端丢了要么在返回路径上封装出错。此时必须再抓远端VTEP的出入口数据形成对照后才能下结论。3.3 多VTEP组网场景中的抓包对照检查另一种高频场景是多VTEP组成的大二层网络配合头端复制Head-end Replication或组播实现广播域。此时一个广播帧到达VTEP后会被复制发送给多个远端VTEP抓包时会看到源IP是本地VTEP目的IP是多个不同的远端VTEP但内层帧完全相同。这个现象是正常的。排查组播或头端复制异常时重点检查复制报文的完整性。比如源VTEP是否把VXLAN头正确填充、每个复制报文的VNI是否一致、目的IP列表是否完整。如果某个远端VTEP一直收不到复制报文而其他VTEP都正常就去核对那个VTEP的IP是否在组播成员列表或头端复制列表里。抓包时最好把本地宿主机和对端宿主机同时抓下来对比序列号和时间戳确认报文是否真的发出、是否真的收到、是否在中间环节被策略丢弃。时间戳对齐很关键我的习惯是把所有抓包机的时间先同步再使用Wireshark的“Time Reference”功能让对比更直观。4. 常见问题与排查技巧实录4.1 VNI配置不一致导致流量“隐形丢失”现象是虚拟机A能ping通同节点虚拟机但跨节点不通抓包时看到外层VXLAN报文源源不断发出远端也确认收到了报文但内层就是不通。进一步检查发现发送端VNI配置为100接收端VTEP对应的网桥里配置的VNI却是200。接收端收到VNI100的报文后无法映射到任何本地虚拟网络直接丢弃但抓包时它确实曾经收到过这个报文从物理网络层面看报文“已经到达”。这种问题在Wireshark里很容易识别发出端抓包看到报文的vxlan.vni是100接收端抓包如果能看到同一条消息可以确认外层传输没问题。如果接收端打开报文后发现VNI与本地网络不匹配那基本可以断言是VNI配置漂移了。排查时先列出两边VTEP实际使用的VNI清单再在抓包里提取所有VNI的值做对比很快就能找到不一致。4.2 MTU引发的“能通但慢”异常VXLAN封装会额外增加50字节左右开销外层以太网14字节IP 20字节UDP 8字节VXLAN头8字节。如果物理网络MTU是1500参与VXLAN通信的虚拟机看到的内层接口MTU是1450才能保证外层报文不超过1500。很多虚拟化平台会自动配置好内层接口MTU但一旦虚拟机内部手动设置了1500就会产生“报文过大需要分片”的场景。这种问题在抓包里表现得很典型看到大量内层IP标志带“Fragment Offset”的报文或者看到ICMP报文里出现“Fragmentation needed”的错误消息。检查方法是在Wireshark里启用IP分片过滤输入ip.flags 0x01查看DF位置位的报文。如果报文DF置位且被丢弃往往会出现“ping大包不通、ping小包通”的现象。解决方向很明确要么把虚拟机网卡MTU调整为1450或更低要么把物理网络MTU提升到1550以上承载封装开销。抓包在这里的价值是确认丢包发生在封装路径的哪一段从而决定调整哪一侧的MTU。4.3 内层MAC表与VXLAN隧道学习混乱VXLAN的数据平面通常采用“内层MAC学习外层VTEP映射”的方式建立转发条目。简单说VTEP看到内层源MAC后会记录“某个MAC地址来自某个远端VTEP”后续发往该MAC的报文就通过对应的隧道转发。这种动态学习机制一旦出现异常就会出现流量“左右横跳”或大规模乒乓。比较常见的原因是不同租户的网络使用相同的MAC地址。由于VXLAN VNI不同理论上MAC可以在不同VNI里重复但如果VTEP的学习表没有把VNI纳入索引维度新学到的MAC就可能覆盖旧条目导致发往这个MAC的报文被送到错误的VTEP。抓包时看到的现象是同一个内层MAC在一段时间内先通过VTEP-X的隧道收到报文然后又通过VTEP-Y的隧道收到同MAC的报文期间伴随着网络震荡。排查时结合vxlan.vni过滤和MAC地址统计看看同一个MAC是否存在跨VNI的重复出现。若存在就需要检查VTEP的学习机制是否关闭了“多VNI隔离”或者考虑配置静态MAC-VNI映射来规避。4.4 非标准UDP端口与UDP端口重复冲突有些环境里管理员为了“以防万一”给VXLAN改了端口结果和上层某个业务端口撞在一起。比如把VXLAN监听端口配置成8472恰好内部某个应用也用这个端口传数据Wireshark会把所有该端口的UDP都解析成VXLAN让协议识别假象满天飞。解决办法是在过滤时加上外层IP条件加以区分。例如只关心两台VTEP之间的VXLAN流量可以写成udp.port 8472 ip.addr 10.10.1.1 ip.addr 10.10.1.2把所有非这两台设备之间的8472端口报文排除在外。另外用Wireshark的“Protocol Hierarchy”统计菜单查看各种协议占比可以快速发现某个端口流量被大量解成VXLAN但实际内层不是以太网的异常辅助识别端口冲突。4.5 隧道两端各说各话外层IP和内层IP容易被混淆分析VXLAN时最容易犯的错误是把外层IP当成内层IP或者反过来。VXLAN中存在两套IP地址体系一套属于物理网络一套属于虚拟网络。很多刚接触VXLAN的同事会拿着“虚拟机IP”在抓包里搜结果搜半天搜不到因为虚拟机IP作为内层IP被藏在VXLAN头的后面Wireshark默认不会把它显示在外层IP的单独列中。强行过滤ip.addr 虚拟机IP时显示的是深层协议字段但主列里不会自动展示导致误判“流量不存在”。解决办法就是前面说的把内层IP字段添加为独立列通过自定义显示列展示内层源IP、内层目的IP并配合vxlan过滤器使用。这样可以同时看到两套IP脑子里也能时刻记住“外层代表隧道走向内层代表业务走向”定位问题时就不会被表象带偏。4.6 无回应问题的标准排查顺序如果VXLAN流量在抓包里看起来一片正常但业务就是不通我通常按这个顺序排查先检查外层封装是否满足物理网络的转发要求目的MAC是否下一跳外层IP是否可路由再检查VNI是否在接收端有对应虚拟网络然后看内层目的MAC是否在接收端VTEP的转发表里最后还需要核对安全策略包括防火墙、安全组、ACL是否拦截了相关流量。Wireshark的“Expert Info”窗口可以汇总异常报文如checksum验证失败、断包、重传优先处理这些红色警告信息。很多“正常中的不正常”就藏在checksum错误或者TCP乱序里这些细节比单纯看某个IP通不通更敏锐。5. 常用工具配合与生产环境的操作建议5.1 命令行工具与Wireshark形成互补抓包不只是图形界面Wireshark的事生产环境往往没有图形界面这时候tcpdump是主力。配合-c参数限制抓包数量配合-w落盘保存文件再用Wireshark离线分析是标准做法。抓VXLAN时tcpdump指定udp port 4789或8472都可以如果端口不确定可以先用“udp portrange 4780-8500”这种宽范围抓一小段时间再离线分析。另一个常用命令是ethtool查看网卡队列数。如果物理网卡开启多队列而VXLAN封装后的UDP源端口做哈希时未考虑网卡RSSReceive Side Scaling配置可能出现部分队列过载、其他队列闲置的现象导致抓包时某些队列的报文丢失。这种情况下抓包容易漏掉关键报文需要把网卡队列收敛或开启flow-steering的匹配规则才能确保抓包完整。5.2 大流量环境下降低抓包开销VXLAN报文包含双层头报文整体变大抓包带来的CPU和磁盘开销也相应增大。在高流量生产环境里建议使用BPF过滤器限定范围而不是全量抓包。常见策略是先按外层IP过滤只抓本机到特定远端VTEP的流量或者只抓带特定VNI的流量通过过滤二进制偏移实现很困难一般还是靠端口加IP做初筛。如果流量实在太猛还可以用snaplen截断抓包只保留头部长度比如-s 128字节足够看到外层IP、UDP和VXLAN头的大半内容但会丢失内层IP关键信息需要根据问题类型权衡。我见过很多人抓包不加任何过滤直接在核心节点上抓了几分钟一个pcap文件几个GB导入Wireshark后流畅度大打折扣过滤响应也慢。与其事后后悔不如在抓包前多花一分钟想清楚当前要验证什么、目标流量从哪个端口来、外层源目的IP是什么然后用一个精确的BPF表达式去抓效率和准确性都会高很多。6. 最后一个值得铭记的实战心得从我处理过的故障看VXLAN模式的排障难点从不在于协议字段本身有多深奥而在于它在物理网络和虚拟网络之间架了一座桥你必须能够同时游走两端且随时清楚自己此刻在哪一端。Wireshark的强项正是把这种“双重身份”透明化只要你会读它的层级展开你就同时拥有物理网络和虚拟网络的两个视图。我建议每个做数据中心网络或云平台运维的人都找一个VXLAN抓包文件按照外层IP、UDP、VXLAN头、内层帧的顺序逐字段拆开看几遍直到能够闭着眼睛画出封装结构为止。最后再分享一个不算技巧但很重要的经验永远不要只看单点抓包。VXLAN是点对点隧道技术问题往往出在两端配置的匹配度上。无论Wireshark给出的单侧分析多么完美只要没有另一侧的抓包做比对就得对结论保持余量。正确做法是至少在两台VTEP上同时抓包用pcap文件里的相对时间戳互相对齐把报文的来龙去脉完整拼出来。只有完整地把路径拆开、对照、再拼起来才算真正把VXLAN排查透了。
