混合云已经打通还慢：回程路径该怎么查

最近一次排查是从一个很普通的报障开始的：自建机房和公有云之间的跨网互联早就调通了，ping 是通的，业务端口也是通的，日常请求都能跑，但每隔一阵就会有一批请求超时，重试一次又能过。运维在其中一端上抓包，看到的现象非常整齐——只有发出去的请求，回来的应答一个都抓不到。第一反应自然是"对端挂了"，于是去找对端；对端查了一圈，说自己这边服务一直是正常的，而且确实能看到请求进来、应答也发出去了。两边各执一词，报文是在中间的某个环节消失的。这种"能通但不稳"的情况，比彻底不通难查得多，因为彻底不通至少有明确的边界可以二分定位，而间歇性失败往往没有一个稳定的复现点。

ping 通只能证明存在一条可达路径，证明不了这条路径好不好

很多人把 ICMP 通当成互联可用性的全部证据，这是排查走偏的起点。一次成功的 ping 说明的是：在刚才那个时刻、那一对地址之间、那个特定大小和协议的报文，曾经走通过一次。它不说明以下几件事：不说明这条路径和你业务流量走的是同一条路径；不说明去程和回程对称；不说明有效载荷空间足够大报文通过；不说明路径上的状态化设备两个方向都看得到；也不说明这条路径就是你以为的那一条。ICMP 报文与业务报文的五元组不同，在多出口做哈希分流的环境里，五元组不同就完全可能落到不同的链路上；ICMP 与 TCP 在安全策略上又经常被区别对待，ICMP 通不代表业务端口通，业务端口通也不代表 ICMP 通。所以 ping 只能作为"存在一条可达路径"的最低限度证据，它能排除一部分问题，但不能作为结论。

偶发失败和全量失败指向的不是同一层问题

区分这两类现象能省掉大量无效动作。全量失败通常意味着配置缺失或者链路中断：路由根本没学到、访问控制整体拒绝、物理链路或互联通道不可用、地址完全不可达。这一类问题的特征是"稳定"，任何时间、任何源地址都失败，用二分法顺着路径逐段验证很快就能收敛，因为失败是可复现的。偶发失败则完全不同，它的根因通常藏在"部分流量被区别对待"里：哈希分流把一部分流送到了有问题的链路；状态化设备只看到单向流量，会话超时后被清理；路径 MTU 限制只影响超过某个大小的报文；对端做过局部策略调整，只改变了部分前缀的回程。偶发问题几乎都是有规律的，只是规律不明显——它跟源端口有关、跟报文大小有关、跟某些目的网段有关、跟某些时间段有关。排查偶发问题的第一步不是换设备、不是加带宽，而是把"偶发"变成"可复现"：确定到底是哪一类流量受影响，哪一类完全不受影响，两者的差别在哪里。

一侧的路由设备只能决定自己的出向，回程由对端说了算

这是整个问题里最关键、也最容易被忽略的一条事实。路由决策是逐台设备独立进行的，每台设备只根据自己收到的路由信息和本地配置的策略，决定报文从自己的哪个接口发出去。这意味着：你只能决定报文从你的网络出去时走哪条路，一旦报文到了对端网络，回程怎么走，由对端网络的路由设备按它自己的最优选择决定，你在自己这一侧配置不了它。于是"我这边选了最优"和"往返都最优"是两件完全不同的事。更麻烦的是，两侧判断"最优"的依据并不共享：你看到的路由属性、路径长度、优先级，与对端看到的可能是完全不同的值，对端完全可以认为另一条路更优。结果就是去程走甲链路、回程走乙链路，两边各自看都合理，合在一起就出问题。

多出口与等价多路径会把这种双向差异放大

单出口时双向不对称还可能只是理论上的可能，多出口环境下它几乎必然发生。出向通常会做等价多路径负载分担：多条开销相同的路径同时生效，设备按五元组（源地址、目的地址、源端口、目的端口、协议）或更粗的三元组做哈希，把不同的流分到不同的链路上。哈希的作用是让同一条连接的报文保持在同一条链路上，避免乱序，这一点它做到了；但哈希是在单台设备上、针对单向流量做的，去程在 A 设备哈希、回程在 B 设备哈希，两个哈希域互不知情，同一条连接的两个方向完全可以落在不同链路上。另外要注意链路成员数量变化带来的影响：一条链路抖动、被维护下线、或者新链路加入，等价路径的集合就变了，哈希会被重算，正在运行的连接可能被换到另一条链路。如果这条链路上有状态化设备，或者这条链路的有效载荷空间与原来那条不同，业务就会在链路变化的那一刻出现一批失败。

不对称本身不是故障，但它和状态化设备天然冲突

必须先说清楚：去程和回程走不同路径，在网络互联里是常见且正常的现象，互联网本身就是去中心决策的，要求所有网络都对称既不现实也无必要。真正出问题的是"不对称"和某些机制相遇。第一个相遇对象就是状态化设备——网络地址转换、状态防火墙、负载均衡、各类会话级网关。这类设备的工作方式是：看到流的首包后建立会话表项，后续报文靠查会话表快速转发，同时刷新老化计时器。它隐含的要求是双向流量都要经过自己。如果回程绕开了它，设备的会话表项迟迟得不到反向流量刷新，老化时间一到就被删除，此后到达的报文找不到会话，只能按首包规则处理或者直接丢弃。表现就是连接建立后跑一段时间就断，或者新请求能过、后续报文不通。判断方法很直接：在这台设备上看会话表，找一条具体的流，看它的双向计数是不是只有一边在增长。只有单向计数，基本就可以确定问题在这一层。

隧道封装挤压有效载荷空间，路径 MTU 探测被过滤时的表现很特别

第二个相遇对象是报文大小。只要做了封装——隧道、加密通道、Overlay 网络——就会在原报文外面再套一层或多层头部，留给业务数据的空间相应减少。端到端本来有一套路径 MTU 探测机制：发送端把报文标记为不允许分片，中间设备如果放不下就回送一个需要分片的提示，发送端据此调小。问题是这套机制依赖特定类型的 ICMP 报文能够回来，而这些报文在很多网络里出于安全考虑是被过滤掉的。一旦被过滤，发送端得不到反馈，就只能一直按原大小发，报文在中间被静默丢弃。这种现象的表现非常有辨识度：不是全面失败，而是握手正常、传大数据卡住；小请求正常、大请求超时；某些接口正常、某些接口永远加载不完。它之所以容易被误判成"带宽不够"或"对端处理慢"，恰恰是因为小流量全都是好的。

只在一端看，观测数据和容量统计都会失真

第三个相遇对象是观测与计费。如果不对称存在，而你的抓包点、流量统计点、监控采样点只覆盖了一个方向或者只覆盖了一条链路，看到的数据就是残缺的：一边是有去无回，一边是流量忽大忽小，或者是甲链路看起来很闲、乙链路看起来接近饱和。基于这种数据做的容量判断和扩容决策必然是错的。所以在做任何容量结论之前，先确认三件事：统计口径是单向还是双向；是一条链路的计数还是多条链路的聚合；采样点位于路径的哪一段。这三项不明确，就没有可用性可言。同理，故障定位时也不要只在一端抓包就下结论，"我这边没看到回包"和"对方没发回包"是两个完全不同的结论，前者可能是回程走了另一条路。

地址重叠时，最长匹配会先命中本地路由

排查顺序上，地址规划应该排在路由之前查，因为它的问题最基础、也最容易被误诊。最常见的问题是两侧网段重叠：一端要访问的目的地址，恰好落在自己本地已有的某个网段范围内。路由查找遵循最长匹配原则，掩码更长的本地路由会优先于指向互联通道的那条路由被选中，于是报文被送去了本地接口，根本没有进入互联链路。表现很有规律：去往某些目的地址通、去往另一些不通，而不通的那些恰好都落在与本地某段重叠的范围内。这里有两个坑：一是做了地址转换之后，你看到的地址可能已经是转换后的，排查时必须先确认自己看到的是转换前还是转换后的地址，两侧的视角不一样；二是必须双向都查，A 侧要拿 B 侧的地址段比对本地路由表，B 侧也要拿 A 侧的地址段比对，只查一侧会漏掉一半。

汇总路由、黑洞路由与找不到正确下一跳

第二类是路由条目本身的问题。汇总路由把一段连续地址收拢成一条发布或配置，好处是路由表规模可控，代价是具体到某一个真实存在的子网时，如果没有更具体的条目，就会命中那条汇总路由，被送到一个并非预期的出口；而这个出口后面如果没有真实可达的路径，流量就进了黑洞。黑洞路由有时是刻意配置的，用来防止路由环路或者防止不该透传的地址被意外放行，但如果不记得它存在，排查时就会遇到"路由表里明明有这条路由，流量却凭空消失"的怪现象，而且在这条路由上做再多调整也没有任何效果。第三类是下一跳不可达：回程路由指向的下一跳地址不在任何直连网段内，需要递归查找才能解析，而递归查找失败，这条路由实际上不生效。这类问题在路由表里看起来完全正常，只有查转发表或者看出接口计数才能发现。

为什么地址规划这一层的问题，调路由解决不了

理论上你可以用更具体的路由条目去盖掉重叠或者黑洞造成的影响，这也是很多人最先尝试的做法。短期看有效，长期看是负债：每发现一个重叠段就加一条例外，例外越加越多，最后没有人能说清某条流到底会走哪条路；更关键的是，例外只对"已经知道的重叠段"生效，而地址是持续分配的——新接入的业务、新开的区域、容器平台自动分配的网段、临时开的测试环境，随时会引入新的重叠。你不可能对未知的重叠段提前加例外。所以判断原则是这样的：如果只是个别历史遗留段，且不再增长，加例外并记录清楚是可以接受的；如果重叠是结构性的——两个环境各自独立做过地址规划、都在持续扩容、未来还要继续接入新的互联方——那就应该重做地址规划。重规划是一次性的根治，代价是要连带改动访问控制列表、监控项、白名单、绑定关系、日志与审计规则里所有引用了旧地址的地方，因此它需要被当成一个项目来做，而不是一次配置变更。

从互联链路学到的路由，有没有被再发布到内部

边界设备学到了路由，不等于全网都学到了。这是"部分网段通、部分网段不通"的另一大来源。要沿着发布链条逐项确认：边界设备上从互联通道学到的路由有多少条；这些路由有没有被再发布进内部的路由进程；再发布时有没有附加过滤条件，只放行了一部分前缀；有没有在再发布时改写了属性，导致内部设备把它优选到了别的出口。典型现象是：在边界设备上探测一切正常，从内部业务服务器上探测就不通；或者核心设备上看到的路由条数明显少于边界设备。排查方法就是逐跳对比路由条数和具体条目，在链条上找到数量开始减少、或者条目开始变化的那一台设备，问题就在它的再发布策略里。

传播到哪些区域，动态与静态混用的边界要画清楚

多区域或者多机房的架构里，路由的传播范围必须显式定义：一条从互联通道学到的路由，是只在本区域生效，还是要跨区域传播。跨区域传播往往要经过另一层汇聚，属性可能被重写，也可能被区域间的过滤策略拦掉，于是出现"本区域通、跨区域不通"。另一类高频问题是动态路由与静态路由混用时的边界。两者由优先级（管理距离）决定谁生效：静态条目通常更"硬"，动态路由已经随链路状态变化了，静态条目还死死指向老出口；反过来，动态路由也可能覆盖掉精心配置的静态条目。结果是两类典型故障——"链路已经切了，路由没切"和"路由切了，但我这条静态还在走老路"。建议把"哪一段地址由谁发布、发布到哪些区域、中间有没有过滤、有没有静态条目覆盖"整理成一张清单并持续维护，这比记住任何一条具体命令都重要。

两端各自发起探测，再比较路径差异

验证路径的第一原则：不要只从一端测。正确做法是在 A 端向 B 端发起探测，同时在 B 端向 A 端发起探测，把两次得到的中间跳序列并排列出来对比。两个方向的跳序列不一致，就是不对称的直接证据；如果不一致的同时业务也不稳，这条线索的优先级应该排到最前面。这里有两个细节决定成败：一是探测要尽量贴近真实业务，用业务实际的源地址、目的地址、协议和端口方向来做，因为五元组不同的报文可能被哈希到不同的链路，用一个无关紧要的探测地址得到的结果未必代表业务流量；二是要在不同时间点多次采样，路径可能随链路状态、对端时段策略而变化，只测一次容易得到"那一刻恰好正常"的假象。把多次采样的结果记下来，出现的不同路径各占多少比例，本身就是很有价值的诊断信息。

核对出口是否符合预期，然后检查策略路由与哈希

第二步是核对出口。先明确写下"我认为这个方向的流量应该从哪个出口出去"，再去验证实际是不是。验证可以在出口链路上做计数或者抓包，看报文到底有没有出现；也可以在出口设备上查转发表，看这条流具体选了哪个下一跳。如果实际与预期不符，去看两类配置：一是策略路由，它按源地址、目的地址、协议、端口或入接口来选路，通常优先于普通路由表的查找结果，很多"明明路由表是对的，流量却不按路由表走"的情况都出在这里；二是本地优先级与路由属性设置，它会改变最优路径的判定。如果出口符合预期但表现仍然不稳定，就去看等价多路径的哈希：同一条流的五元组是否稳定不变；不同流被分配到了哪些链路，分布是否异常集中；近期链路成员数量有没有发生过变化。哈希相关的不稳定有一个显著特征——它跟"哪些流"有关，而不是跟"什么时候"有关，换了源端口可能就好了。

用不同包大小验证，把 MTU 问题单独隔离出来

第三步是专门验证报文大小。做法是：从两端分别发送设置了"不允许分片"标志、载荷逐步增大的探测报文，记录能够通过的最大载荷值，再拿它与"接口 MTU 减去封装开销"的理论值做对比。如果实际测出能通过的最大值明显小于理论值，说明路径中间某处的有效空间更小，或者某台设备对分片的处理有问题。对比时要区分三种表现：所有大小的报文都失败——这不是 MTU 问题，是可达性或者策略问题；只有大报文失败——MTU 或者分片处理问题；大报文间歇性失败——很可能是哈希把大报文分到了某条存在 MTU 问题的链路上。处理上有两个方向：一是在隧道侧把接口 MTU 调小，或者在 TCP 握手阶段调整协商的 MSS，让发送端从一开始就发出合适大小的报文，这通常比逐台设备改 MTU 更省事；二是确认路径上需要的 ICMP 类型没有被过滤，让路径 MTU 探测机制能够正常工作。这两个方向可以同时做，前者是缓解，后者是根治。

出向可以自己控制，入向只能间接影响

这是能力边界，必须先讲清楚，否则会浪费大量时间去做做不到的事。出向上你拥有完整的控制权：策略路由、路由优先级、出口选择、地址转换、流量工程，全部可以在本地决定并立即生效。入向则不同——报文从对端网络回来时走哪条路，由对端网络的路由设备决定，你在自己这一侧没有任何直接的配置手段。能够影响入向的都是间接手段：你向外公告哪些地址段、公告时携带什么属性、是否用更具体的前缀做精细引导、是否做路径预置、在地址规划上把不同业务放到不同段以便分别引导。这些手段能不能生效，取决于对端是否接受你的公告、对端是否配置了更优先的策略覆盖你。因此涉及回程的调整，通常需要与对端网络的管理方或者链路服务商协调推进，单方面改不出来。一万网络深耕 IDC 行业 19 年（成立于 2007 年），在华南、华东、华北及中国香港、海外多地整合自营节点与 BGP 多线资源，提供服务器租用、机柜托管与带宽接入的一体化交付；具体机型、带宽与报价以官网实时信息或咨询确认为准——多线接入环境的路径判断通常需要结合本地策略与上游公告一起看，不能只凭某一侧的路由表就下结论。

状态化设备：让流量双向经过、旁路、还是做会话同步

遇到状态化设备因单向可见而丢包，可选的处理方向有三条，选择依据是这台设备在这条路径上是否不可替代。第一条是改变路径，让双向流量都经过它——如果它承担网络地址转换，这是唯一正确的选择，因为回程流量不经过它就无法完成反向转换。第二条是旁路，让它不再依赖看到双向流量，改为无状态处理或者只承担不需要会话的功能——前提是访问控制策略在旁路之后仍然覆盖得住，不能因为解决一个问题而打开一个口子。第三条是会话同步，多台设备之间同步会话表，任意一台看到连接建立就同步给其他台，回程走哪台都能处理——代价是设备之间增加了同步开销，且只对参与同步的设备有效，超出范围的仍然会出问题。做选择之前先确认一件事：这台设备是不是这条路径上不可替代的环节。是，就改路径或者做同步；不是，才考虑旁路。

什么时候应该下决心重做地址规划

明确该做的情形：重叠是结构性的，两个环境各自独立规划过地址且都在持续扩容；例外路由已经多到影响理解成本和变更安全，没人敢动；准备新增互联方或新区域，而现有地址空间已经拿不出不重叠的段可分配；准备收敛地址转换规则，但现有规划导致转换规则复杂到无法维护；业务要做分区分级管控，而现有地址段划分支撑不了按段施策。明确不该急着做的情形：只是个别历史遗留段且已经稳定；业务处在不能动的窗口期；例外已经有文档且被验证过。真要做的话，工程代价主要不在地址本身，而在依赖地址的一切：访问控制列表、监控与告警项、白名单、证书或服务绑定关系、日志与审计规则、以及所有硬编码了地址的配置。正确顺序是先盘依赖清单，再排变更窗口，按业务优先级分批切换，每批切换后立刻用本文前面说的双向探测方法验证一次。

把路径假设写进文档，并且定期复核

要写下来的不是"网络已打通"这句废话，而是可以被验证的具体假设：去程期望从哪个出口出，回程期望从哪条链路回，路径上经过哪些状态化设备，有效载荷空间是多少，哪些网段存在例外以及例外的原因，哪些地址段由谁发布到哪些区域。写成假设的好处是它天然带有验证方法——每一条假设都可以用一次探测或者一次抓包来确认成立还是不成立。定期复核是必要的，因为上游链路、对端策略、内部地址分配都在变化，今天成立的假设半年后未必成立；很多"莫名其妙突然出问题"的故障，翻出来一查都是某个假设在无声中被打破了。文档里还应当写清"谁负责哪一段"：本地段、互联段、对端段各自的负责方和联系渠道。有了这张归属表，故障时可以并行排查而不是串行推诿，这一点对缩短定位时间的效果，往往比任何技术手段都明显。

变更前后对比，以及告警应该盯哪些指标

变更前必须留基线，没有基线就无法判断变更是否引入了问题。需要留的基线包括：双向路径的跳序列、关键网段的实际出口、状态化设备上关键流的会话状态、有效载荷空间、各条链路的双向流量计数。变更后用完全相同的方法再采一次，逐项对比，任何差异都要解释清楚，解释不了的就当作潜在问题继续跟。告警指标方面，建议盯这几类：互联链路双向流量是否出现明显不均衡（去得多回得少，或者反过来）；会话表中单向会话数量的变化趋势；路径跳数或出口发生变化的次数；接口上分片报文与被丢弃报文的计数；关键网段的周期性可达性探测结果变化。这里的原则是盯"变化"而不是盯"绝对值"——先记录正常状态长什么样，再看偏离了多少。绝对值阈值在没有基线的情况下没有任何意义。一万网络深耕 IDC 行业 19 年（成立于 2007 年），在华南、华东、华北及中国香港、海外多地整合自营节点与 BGP 多线资源，提供服务器租用、机柜托管与带宽接入的一体化交付：具体机型、带宽与报价以官网实时信息或咨询确认为准，互联方式需按实际条件确认。

混合云打通之后怎么确认路径是对的：落地前的排查清单

从两端各自发起探测并比对：不要只从一端验证。两个方向各采多次，记录中间跳序列，不一致就是不对称的直接证据，需要确认这种不对称是否被业务接受。

核对实际出口是否与预期一致：先写下预期出口，再在出口链路上计数或抓包验证。不一致时优先查策略路由和本地优先级，而不是先怀疑对端。

确认状态化设备双向可见：在 NAT、状态防火墙、负载均衡等设备上查具体流的会话表，看双向计数是否都在增长。只有单向计数，说明回程没有经过这台设备。

用递增载荷验证有效空间：带不分片标志、从小到大逐步增大载荷，两端各测一遍，与"接口 MTU 减封装开销"的理论值对比，找出偏差。

双向比对地址规划：拿对端的地址段逐段比对本地路由表，找重叠、找被汇总覆盖、找命中黑洞的段。两侧都要做，不能只查一侧。

逐跳核对路由传播范围：比对边界设备与内部设备上看到的路由条数和条目差异，找到数量开始变化的那一跳，检查再发布策略的过滤条件和静态条目覆盖情况。

固定五元组做稳定性观察：用与业务一致的五元组反复探测，观察是否时好时坏；同时记录近期链路成员数量是否变动过，哈希重算会造成一批连接受影响。

什么情况下该先改地址规划而不是调路由：几种明确的情形

重叠是结构性的：两个环境各自独立做过地址规划，且都在持续扩容。这种情况下每加一次例外就多一份负债，加例外的速度永远赶不上新增重叠的速度。

例外已经多到没人敢动：路由表里堆积了大量特例条目，变更评审时没有人能说清某条流走哪条路。这意味着变更风险已经失控，继续叠加只会更糟。

地址空间已经不够分配：准备新增互联方或新区域，却拿不出不重叠的地址段。这是硬约束，加路由解决不了物理上的空间不足。

转换规则复杂到无法维护：因为地址重叠，不得不叠加多层地址转换来绕过冲突，转换规则本身已经成为故障来源。这时应该回到源头解决。

业务要求按段管控：需要做分区分级、按地址段施策，而现有划分支撑不了。地址规划是策略落地的底座，底座不对，上层策略只能靠例外堆出来。

反面情形也要记住：只是个别历史遗留段、已经稳定且文档清晰、业务处在不能动的窗口期——这三种情况下维持现状并加好例外记录，比贸然重规划更合理。

ping 通但业务慢，是不是互联带宽不够

先别急着加带宽。带宽不足的表现通常是持续性的、与流量规模正相关、且在双向都可见；而"打通了还慢"更常见的成因是路径不对称、单向不可见导致的状态化设备丢包、或者大报文被静默丢弃。判断方法是从两端各自探测并比对路径，同时在链路上确认双向流量计数是否均衡。如果双向计数确实都接近上限，再考虑容量；如果一边高一边低，或者路径两侧不一致，问题在路径和设备上，加带宽不会有任何改善。

双向路径不一样，是正常的还是配置错了

现象本身是正常的。路由决策由各网络独立做出，要求所有互联场景都严格对称既不现实也无必要。需要判断的是它是否与你的架构冲突：路径上有没有状态化设备要求双向可见；两条路的有效载荷空间是否一致；两条路的策略与过滤是否一致；观测与计费是否因为单向可见而失真。都不冲突，不对称可以放着不管；有冲突，才需要处理——处理的目标也不是强行改成对称，而是消除冲突点。

回程能不能自己控制从哪条链路回来

不能直接控制。你只能决定出向，回程由对端网络按它自己的最优选择决定。能做的是间接影响：向外公告哪些地址段、公告时携带什么属性、是否用更具体的前缀做精细引导、是否做路径预置。这些手段是否生效取决于对端是否接受以及是否有更优先的策略覆盖。所以涉及回程的调整基本都需要与对端网络管理方或链路服务商协调，这一点在制定方案时就要算进去，不要承诺单方面可以改。

网段重叠是不是一定要改地址

不一定，取决于重叠的性质。个别历史遗留段、稳定不再增长、已有清晰的例外记录，维持现状加例外是合理的。但如果重叠是结构性的——两侧各自独立规划过、都在持续扩容——就该改，因为例外只对已知的段生效，新增业务随时会带来新的重叠，你无法为未知提前布防。判断时还要算清代价：改地址会连带访问控制列表、监控项、白名单、绑定关系、日志审计规则，需要按项目推进而不是当成一次配置变更。

等价多路径会不会导致正在跑的连接中断

会，而且这是它最容易被忽略的副作用。等价多路径按五元组哈希分流，同一条连接正常会固定在同一条链路；但一旦链路成员集合发生变化——某条链路抖动、下线维护、新链路加入——哈希就会被重算，原本跑在老链路上的连接可能被换到新链路。如果链路上有状态化设备，或者新链路的 MTU 不同，这批连接就会在链路变化的那一刻出现失败。所以做任何涉及链路成员的变更，都要当作有业务影响来对待，先在低峰期做，变更前留好基线。

怎么快速确认是不是 MTU 的问题

最直接的判据是"按大小分层"：小请求全过、大请求卡住，或者握手正常但传输大数据时停滞，基本就可以锁定在报文大小这一层。确认方法是发送带不分片标志、载荷逐步增大的探测报文，找出能通过的最大值，与"接口 MTU 减封装开销"的理论值对比。三种表现要分清：所有大小都失败是可达性或策略问题；只有大报文失败是 MTU 或分片处理问题；大报文间歇失败，很可能是哈希把大报文分到了某条有 MTU 问题的链路。

变更前应该留下哪些基线数据

至少五类：一是双向路径的跳序列，两端各采一次；二是关键网段的实际出口，写清楚预期值再核对实际值；三是状态化设备上关键流的会话状态，确认双向计数正常；四是有效载荷空间，用递增载荷探测得出；五是各条链路的双向流量计数，确认是单向口径还是聚合口径。变更后用完全相同的方法再采一次逐项对比。没有基线，事后任何判断都只是猜测。此外还要记录当前链路成员集合，因为它的变化会触发哈希重算。