1. 一次校园网络升级引发的速率异常排查前阵子帮某高校网络中心的朋友处理了一个挺典型的问题校园网完成IPv6双栈改造之后部分区域的终端测速数据一直上不去IPv4跑满千兆轻轻松松切到IPv6就掉到两三百兆甚至有些楼层直接卡在两位数。这个问题不是全网性的而是集中在几栋楼、几个品牌的路由器下面排查起来相当折磨人。我前后跟进了差不多两周从终端侧一路查到核心交换最后定位到几个叠加在一起的原因。这篇文章就把整个排查过程、涉及到的IPv6速率关键影响因素、以及可以直接复现的验证方法完整梳理一遍。IPv6速率问题这件事说大不大说小也不小。它不像链路中断那样一眼就能看出来而是表现为能用但慢用户感知就是网速变差了报障描述往往很模糊。对于负责校园网、企业园区网的运维人员来说这类问题最耗时间因为你需要同时排除终端、接入、汇聚、核心、出口、以及IPv6特有的协议机制等多个层面的干扰。适合阅读这篇内容的人包括正在做IPv6改造的网络工程师、负责校园网或园区网运维的技术人员、以及想搞清楚IPv6为什么看起来更慢的终端用户。我会尽量把每个判断背后的逻辑讲清楚而不是只丢结论。需要先说明一点IPv6本身在设计上并不比IPv4慢理论上因为头部结构简化、去掉了NAT、支持更大的MTU端到端性能应该更好。所以当你遇到IPv6速率明显低于IPv4时几乎可以断定是配置、设备能力或路径上的某个环节出了问题而不是协议本身的锅。这个基本认知很重要它决定了排查方向——我们要找的是哪里没配对或者哪里成了瓶颈而不是去怀疑IPv6这个协议。2. IPv6速率问题的整体排查思路与方案选型2.1 为什么不能照搬IPv4的排查套路很多人排查IPv6慢第一反应是拿IPv4那套经验往上套ping一下、traceroute一下、看看丢包。这套方法不是没用但不够。IPv6有几个IPv4没有的机制会直接影响速率表现如果不知道这些机制很容易在错误的方向上浪费时间。第一个是邻居发现协议NDP。IPv6没有ARP地址解析靠NDP而NDP是基于ICMPv6的组播实现的。组播在二层交换机上的处理方式和单播完全不同如果交换机的组播抑制、MLD Snooping配置不当NDP解析就会变慢甚至丢包表现出来就是时通时不通或者首包延迟特别大。第二个是MTU和分片。IPv6规定中间路由器不允许分片分片只能由源端做。这意味着如果路径MTU发现PMTUD没正常工作大包会被直接丢弃而不是像IPv4那样被中间设备分片后继续转发。结果就是小包ping通、大包全丢测速自然上不去。第三个是地址分配方式。SLAAC、DHCPv6、以及两者混合SLAAC拿地址DHCPv6拿DNS在不同设备上的支持程度差异很大配置不当会导致终端拿到地址但路由或DNS有问题间接影响速率体验。所以我的整体思路是先分层定位再逐层深挖。分层指的是把问题域切成终端侧、接入侧、网络侧、出口侧四块用不同的工具和方法分别验证。方案选型上我倾向于用对比法——同一台终端、同一时间、同一目标分别跑IPv4和IPv6用差异来缩小范围。这个方法看起来笨但极其有效因为差异点往往就是问题点。2.2 分层定位法的具体分层逻辑我把整个排查分成四层每层有明确的验证目标和工具层级关注对象核心验证目标常用工具终端侧网卡、驱动、协议栈终端IPv6能力是否正常系统命令、测速客户端接入侧交换机、AP、路由器二层转发与NDP是否正常交换机日志、抓包网络侧汇聚、核心、路由路径MTU与路由是否正常traceroute6、ping6出口侧边界设备、上游出口带宽与策略是否正常流量监控、策略核查这个分层的价值在于每一层都能独立得出结论不会出现查了半天不知道问题在哪一层的情况。比如终端侧验证通过就说明终端没问题把精力放到接入侧接入侧也通过就往网络侧走。逐层排除最后剩下的就是问题所在。提示分层排查时一定要做记录把每层的验证结果、时间点、使用的命令都记下来。IPv6问题有时候是间歇性的没有记录很难复现和对比。2.3 工具选型背后的考量工具这块我没有用太花哨的东西核心就几个ping6、traceroute6、iperf3、抓包工具、以及交换机自带的诊断命令。选它们的理由很直接ping6用来做基础连通性和MTU探测通过指定包大小-s参数可以快速判断是不是MTU问题。traceroute6用来看路径重点看每一跳的延迟和是否有异常节点。iperf3是打流测速的比网页测速准确得多而且可以指定TCP/UDP、单流/多流方便定位是带宽问题还是单流性能问题。抓包工具用来在关键节点看NDP交互和分片情况这是最直接的证据。这里要特别说一下为什么不用网页测速作为主要依据。网页测速受浏览器、服务器、CDN、并发连接数等太多因素影响波动大而且很多测速站点对IPv6的支持本身就不完善。我见过好几次网页测速IPv6很慢但实际用iperf3打流完全正常的情况最后发现是测速站点的问题。所以网页测速只能作为参考不能作为判断依据。3. 核心细节解析与实操要点3.1 MTU问题IPv6速率杀手的第一嫌疑MTU是IPv6速率问题里出现频率最高的原因没有之一。我这次遇到的案例里有一栋楼的问题就是MTU导致的。原理是这样的IPv6的头部固定40字节比IPv4的20字节大。以太网默认MTU是1500那么IPv6实际可用的payload是1500-401460字节。如果路径上某个环节的MTU小于1500比如某些隧道、某些老设备而PMTUD又没正常工作那么大于该MTU的包就会被丢弃。表现出来就是ping小包通ping大包不通TCP连接能建立但传输大文件时卡死或极慢。验证方法很直接用ping6指定包大小逐步测试# 测试1460字节payload对应1500 MTU ping6 -s 1460 -M do 目标IPv6地址 # 如果上面不通逐步减小 ping6 -s 1400 -M do 目标IPv6地址 ping6 -s 1300 -M do 目标IPv6地址-M do表示禁止分片这样能准确测出路径MTU。如果1460不通但1400通说明路径MTU在1440左右需要调整。解决思路有两个一是修复PMTUD确保ICMPv6的Packet Too Big消息能正常传递很多防火墙会拦截这类ICMPv6消息这是常见坑二是调整MTU/MSS在终端或路由器上把MSS钳制到合适值。我一般优先修PMTUD因为这是治本如果上游设备不受控才用MSS钳制兜底。注意很多防火墙默认会拦截所有ICMPv6这会直接破坏PMTUD。排查时一定要确认ICMPv6的Type 2Packet Too Big消息没有被拦。这个坑我踩过不止一次。3.2 NDP与组播二层转发里的隐形瓶颈NDP的问题比MTU更隐蔽因为它不表现为完全不通而是时快时慢或者首包特别慢。IPv6的地址解析靠NS/NANeighbor Solicitation/Advertisement消息这些消息发往 solicited-node 组播地址。二层交换机如果开启了MLD Snooping会监听这些组播加入消息正常情况没问题。但如果MLD Snooping配置有问题或者交换机的组播表项老化时间设置不合理就会导致组播消息被错误泛洪或丢弃NDP解析失败或延迟。我这次遇到的另一栋楼的问题就是这个交换机MLD Snooping的组播组老化时间设得太短默认可能只有几十秒而NDP表项老化时间更长导致组播组被提前删除后续NDP消息只能泛洪泛洪又受限于交换机的泛洪抑制策略结果就是解析慢、丢包。排查方法在交换机上看MLD Snooping表项在终端上抓包看NS/NA的交互时间和是否有重传。如果发现NS发出去很久才收到NA或者有多次重传基本可以确认是二层组播问题。解决上我调整了交换机的MLD Snooping老化时间让它大于NDP表项老化时间同时检查了泛洪抑制策略确保NDP相关的组播不会被抑制。调整后速率立刻恢复正常。3.3 地址分配与DNS容易被忽略的速率影响因素地址分配方式本身不直接决定速率但它会通过DNS解析间接影响体验。很多终端用SLAAC拿地址但DNS需要通过DHCPv6或RDNSSRouter Advertisement里的DNS选项获取。如果RA里没配RDNSS终端又没跑DHCPv6就会出现有IPv6地址但没IPv6 DNS的情况终端在解析域名时会先尝试IPv6 DNS、超时后再回退IPv4这个超时过程就是用户感知的慢。验证方法在终端上看DNS配置确认IPv6 DNS是否正常下发。Windows用ipconfig /allLinux用resolvectl status或看/etc/resolv.conf。# Linux查看DNS配置 resolvectl status | grep -A5 DNS Servers # 测试IPv6 DNS解析 dig AAAA 目标域名 IPv6_DNS地址如果发现DNS没下发需要在RA里配置RDNSS或者启用DHCPv6下发DNS。这个问题的特点是网页打开慢但下载速度正常因为下载用的是IP直连或已缓存的DNS而首次访问新域名时才触发DNS超时。3.4 终端侧网卡驱动与协议栈的坑终端侧的问题占比不高但一旦遇到就很折腾。我遇到过某品牌网卡的驱动对IPv6的校验和卸载Checksum Offload支持有bug导致IPv6大包校验和计算错误被对端丢弃表现为小包正常、大包丢。关掉网卡的IPv6校验和卸载后恢复正常。还有一次是某操作系统的IPv6协议栈默认开启了某些节能特性在特定AP下会导致速率协商异常。这类问题排查起来要靠对比换一台终端、换一个网卡、换一个驱动版本看问题是否复现。终端侧的排查清单我整理成下面这样确认网卡驱动是最新稳定版尤其是较新的网卡检查网卡的IPv6相关卸载功能Checksum Offload、Large Send Offload是否正常确认操作系统IPv6协议栈没有被禁用或限制对比不同终端、不同网卡的表现缩小范围提示终端侧问题最容易被误判为网络问题。我的经验是如果同一位置、同一时间只有某一类终端慢其他终端正常那大概率是终端侧的问题优先查终端。4. 实操过程与核心环节实现4.1 第一步建立基线用对比法锁定问题范围排查的第一步不是急着改配置而是建立基线。我在问题楼栋选了一台终端在同一时间、对同一目标分别跑IPv4和IPv6的iperf3测试记录下基础数据。# IPv4打流测试 iperf3 -c IPv4服务器地址 -t 30 -P 4 # IPv6打流测试 iperf3 -c IPv6服务器地址 -t 30 -P 4-t 30表示测试30秒-P 4表示4条并发流。用多流是因为单流容易受TCP窗口、RTT等因素限制多流更能反映实际带宽。基线数据出来后如果IPv4能跑900Mbps而IPv6只有200Mbps差异就很明显了。接下来要做的就是逐层缩小范围换终端、换端口、换楼层、换目标服务器每换一个变量就测一次看速率是否变化。这一步的关键是控制变量。我见过有人同时换了好几个东西结果数据没法对比白测。一次只改一个变量这是铁律。4.2 第二步MTU探测与PMTUD验证基线建立后我优先验证MTU因为这是最常见的原因。用ping6逐步测试包大小# 从1460开始逐步减小 for size in 1460 1440 1420 1400 1380 1360; do echo -n Size $size: ping6 -c 2 -s $size -M do 目标IPv6地址 /dev/null 21 echo OK || echo FAIL done这个脚本能快速找出路径MTU的临界点。如果1460就OK说明MTU没问题如果1460 FAIL但1400 OK说明路径MTU在1440左右。找到临界点后还要验证PMTUD是否工作。方法是发一个超过路径MTU的包看是否收到ICMPv6的Packet Too Big消息# 发一个明显超大的包看是否收到ICMPv6错误 ping6 -c 1 -s 2000 -M do 目标IPv6地址如果收到Packet too big的回复说明PMTUD工作正常如果直接超时无响应说明ICMPv6被拦了PMTUD失效。我这次在问题楼栋测出来的是1460 FAIL1420 OK说明路径MTU是1440。进一步查发现是某台接入交换机的一个上联口配置了较小的MTU而且上游防火墙拦截了ICMPv6的Packet Too Big消息导致PMTUD完全失效。修复方案是统一MTU配置并在防火墙上放行ICMPv6 Type 2消息。4.3 第三步NDP与二层组播的抓包分析MTU问题解决后还有一栋楼的速率没恢复我转向NDP排查。方法是在终端和网关同时抓包看NS/NA的交互。# 在Linux终端上抓ICMPv6的NDP消息 tcpdump -i eth0 -n icmp6 and \(ip6[40] 135 or ip6[40] 136\)ip6[40] 135是NS136是NA。正常情况下一问一答间隔在毫秒级。如果看到NS发出去后很久才收到NA或者有多次重传就说明NDP有问题。我抓包的结果是NS发出后平均要等300-500ms才收到NA而且有约10%的NS没有响应需要重传。这个延迟直接导致TCP建连慢、首包慢。进一步查交换机发现MLD Snooping的组播组老化时间设成了30秒而NDP表项老化时间是30分钟。组播组30秒就被删了后续NDP消息只能泛洪泛洪又受泛洪抑制限制导致丢包和延迟。调整方案把MLD Snooping组播组老化时间调到大于NDP表项老化时间我设成了1800秒并检查泛洪抑制策略确保NDP相关组播不被抑制。调整后抓包显示NS/NA交互恢复到毫秒级速率也恢复正常。4.4 第四步出口与策略核查前面三层都排查完如果还有问题就要看出口侧了。出口侧主要查两件事出口带宽是否被IPv6流量单独限速以及出口设备对IPv6的处理能力。有些边界设备在IPv4和IPv6上配置了不同的策略比如IPv4不限速但IPv6限速或者IPv6走了不同的出口链路。这些策略如果不仔细看配置很容易漏掉。我这次核查出口时发现出口设备上有一条针对IPv6的QoS策略把IPv6流量限制在了500Mbps而IPv4没有限制。这条策略是改造初期为了保护出口加的后来忘了删。删掉后IPv6速率立刻上去了。出口侧核查清单确认IPv4和IPv6的出口策略一致没有单独的限速确认IPv6走的出口链路带宽足够确认出口设备的IPv6转发性能不是瓶颈老设备可能IPv6性能远低于IPv4确认没有针对IPv6的异常QoS或ACL注意出口设备的IPv6转发性能是个容易被忽略的点。一些较老的设备IPv4转发靠硬件IPv6转发靠软件性能差距可能有数量级。如果出口设备较老一定要确认它的IPv6转发能力。5. 常见问题与排查技巧实录5.1 常见问题速查表现象可能原因快速验证方法解决方向小包通大包丢MTU/PMTUD问题ping6 -s 1460 -M do修PMTUD或钳MSS首包慢、时快时慢NDP/组播问题抓包看NS/NA延迟调MLD Snooping老化网页慢但下载正常DNS问题查IPv6 DNS配置配RDNSS或DHCPv6特定终端慢终端驱动/网卡换终端对比更新驱动/关卸载整体速率上不去出口限速/性能查出口策略删限速/换设备间歇性丢包组播泛洪抑制查交换机泛洪策略放行NDP组播5.2 独家避坑技巧技巧一先测MTU再查其他。我现在的习惯是遇到IPv6速率问题第一件事就是测MTU。因为MTU问题占比最高而且验证最快一条命令的事。先排除这个能省下大量时间。技巧二抓包永远比猜靠谱。很多问题看配置看不出来但抓包一看就明白。NDP延迟、分片丢弃、ICMPv6被拦这些在抓包结果里都是明明白白的。我现在的排查流程里抓包是标配不是可选项。技巧三对比法要控制变量。前面强调过这里再强调一次。一次只改一个变量改完立刻测测完记录。我见过太多人同时改好几个东西结果问题解决了也不知道是哪个改对了下次遇到还是不会。技巧四别忽略ICMPv6。ICMPv6对IPv6的重要性远超ICMP对IPv4。PMTUD、NDP、MLD都依赖ICMPv6。如果防火墙无脑拦ICMPv6IPv6基本没法正常工作。排查时一定要确认ICMPv6的关键类型Type 1/2/3/4/133/134/135/136/143没有被拦。技巧五记录基线数据。排查前先记录正常时的数据速率、延迟、丢包排查过程中每次改动后对比。没有基线你连恢复了没有都判断不了。5.3 几个容易误判的场景场景一网页测速慢但iperf3正常。这大概率是测速站点的问题不是网络问题。换iperf3或换测速站点验证。场景二只有IPv6慢IPv4正常。不要怀疑IPv6协议本身一定是配置或设备问题。按分层法排查。场景三所有终端都慢。这通常是网络侧或出口侧的问题终端侧可以快速排除。场景四只有部分终端慢。优先查终端侧和接入侧网络侧和出口侧大概率没问题。场景五白天慢晚上正常。这通常是带宽拥塞或策略问题查出口带宽利用率和QoS策略。6. 一些实操后的个人体会这次排查下来最大的感受是IPv6速率问题从来不是单一原因往往是多个因素叠加。我这次遇到的案例里MTU、NDP、出口限速三个问题同时存在只解决一个速率还是上不去必须全部解决才行。所以排查时要有耐心一层一层过不要指望一招制敌。另外IPv6的很多机制和IPv4差异很大用IPv4的经验去套IPv6很容易走弯路。比如IPv4里MTU问题相对少见因为中间设备可以分片但IPv6里MTU问题极其常见因为不允许中间分片。再比如IPv4里ARP很健壮但IPv6的NDP对二层组播配置很敏感。这些差异点恰恰是问题的高发区。最后分享一个我自己的排查顺序供参考先测MTU最快→ 再抓NDP最隐蔽→ 然后查DNS最易忽略→ 最后看出口最容易被忘。这个顺序是按问题出现频率和验证速度综合排的实测下来能覆盖大部分场景。当然具体问题还要具体分析这个顺序只是个起点不是万能公式。