问题背景

机房搬迁、专线扩容、防火墙替换、VPN 重协商这类跨机房链路变更，现场最常见的验收口径是「两边能 ping 通、核心业务打开页面」。看起来很快，晚上却往往出事：A 到 B 正常、B 到 A 超时；小包没事、大文件/数据库同步卡死；白天流量小看不出来，晚高峰回程路径一拥塞就全面抖。

结合近年处置过的非对称路由、PMTUD 黑洞、OSPF 配置漂移、专线抖动等案例，我们把零散经验收成一份跨机房链路变更验收 Checklist，并在一次生产窗口强制落地。目标不是再写一篇事后复盘，而是让值班在变更当晚按清单逐项打勾，把「半通 / 大包不通 / 路径漂移」挡在业务发现之前。

故障现象

变更窗口结束后，监控与值守群一度显示「正常」：

1. ICMP 通：核心交换机、关键服务器双向 ping 延迟稳定，丢包为 0。
2. 页面通：运维从办公网打开对端工单/监控，HTTPS 能打开。
3. 告警静默：链路 up、BGP/OSPF 邻居 Established、专线 SD-WAN 面板全绿。

约 40 分钟后问题陆续冒头：

1. 单向业务失败：A 机房调用 B 机房内部 API 正常，反向回调/Webhook 超时；部分日志同步只见 half-open。
2. 大包业务卡死：跨机房备份、镜像同步、数据库物理复制进度条长时间不动；ping 小包仍正常。
3. 路径不一致：traceroute 去程走新专线，回程仍钻旧 VPN 或策略路由旁路；NAT/状态防火墙开始出现「只见半连接」。
4. 晚高峰放大：业务量上来后抖动与重传激增，一线又会把锅甩给「应用层超时配置」。

若只以「能 ping」结单，这类故障会伪装成应用问题，排查成本成倍上升。

排查过程

1. 停掉「能 ping 就收工」的习惯

窗口负责人没有直接关单，而是拉出验收清单，按业务矩阵 → 双向路径 → 大包/MTU → 协议与冗余 → 回退点五段复核。同时保留变更前配置快照、路由表导出与流量基线，避免「修着修着不知道改过什么」。

2. 第一道关：连通矩阵（比单点 ping 重要）

列出跨机房真实流量，而不是只测运维跳板机：

执行要求：

• 每个格子用源侧真实网段主机测，不拿 NAT 后的跳板机冒充应用源
• 同时测 TCP 端口（nc/Test-NetConnection/curl），不只靠 ICMP
• 关键 conntrack/会话表，确认是 ESTABLISHED，而不是反复 SYN 重试
• 任一方「半通」即判验收失败，禁止用「业务侧可绕行」抵赖

本窗口第一轮就扫出 2 条反向路径缺失：B→A 的回调地址仍指向旧 VIP，A 侧安全策略只放行了新专线网段的入向，出向回包被旧策略路由送进黑洞。

3. 第二道关：回程路由与对称性

「去程通、回程不通」是跨机房变更的高频杀手。清单强制做：

1. 双向 traceroute / 路由查表
   在源、目的各取 2 个真实主机，对打并记录路径哈希（下一跳序列）。去程与回程若不一致，标记为「非对称」，进入高风险清单。
2. 策略路由 / PBR / 默认路由优先级
   核对静态路由、SD-WAN 选路、防火墙 policy-based route 是否与新链路同步；禁止只改一边的下一跳。
3. 状态防火墙与 RPF
   对启用 strict uRPF / 会话严格绑定入接口的设备，非对称几乎必然丢回程。能改 loose 的评估影响；不能改的必须把去程回程收敛到同一逻辑路径。
4. NAT 边界
   跨机房若存在源 NAT/目的 NAT，验收时确认两端看到的五元组一致，避免「A 以为连的是 10.x，B 回的是公网映射地址」。

本窗口发现：新专线只在 A 侧注入了更优 metric，B 侧回程仍偏好旧 IPsec。白天流量小时偶发成功（部分流碰巧对称），高峰则大面积超时——典型「验收假绿」。

4. 第三道关：MTU / MSS / 大包

小包通、大文件卡，优先怀疑隧道封装与 PMTUD：

1. 测路径 MTU
   ping -M do -s <size>（Linux）或等价大包 DF 探测，从 1500 递减找到两端实际可用 MTU；隧道场景常见有效载荷掉到 1400 附近。
2. 禁止只靠「不分片就缩小包」糊弄
   业务 TCP 若 MSS 未钳制，仍会发接近 1500 的包，中间丢 ICMP「需要分片」时即 PMTUD 黑洞。
3. 验收项必须含大包业务
   至少跑一轮：iperf/smb 大文件、数据库逻辑同步、对象存储 multipart；持续 3–5 分钟看重传与吞吐是否达到基线 80% 以上。
4. 设备侧检查
   隧道口 MTU、TCP MSS adjust、是否错误丢弃 ICMP Type3 Code4、是否对 DF 包粗暴 drop。

本窗口第三关直接复现：ICMP 64 字节完美，1420+ DF 包在防火墙被静默丢弃；备份任务卡在初始化后的大块传输。放通必要 ICMP 差错并在网关做 MSS 钳制后恢复。

5. 协议邻居、冗余与回退演练

在三道关都绿后，补协议与运维动作：

• 路由协议：邻居稳定时长、LSA/前缀数量对比变更前、是否出现 flap damping
• 冗余：主断备切、备断主回切各测一次，观察收敛时间与是否双主/黑洞
• DNS/VIP/证书：跨机房域名解析与证书 SAN 是否指向新入口
• 回退点：保留旧链路 admin-down 而非物理拆线，直到观察期结束；回退步骤写成 5 分钟内可执行的命令序
• 观察期：至少覆盖一个业务高峰 + 一次备份窗，监控丢包、时延、会话失败率、专用链路带宽

6. 清单落地时的分工与门禁

门禁规则：任一关未通过 → 不得关闭变更单；可暂时业务放行但必须保持旧链路可秒级回退，并升级为 P1 跟踪。

解决方案

当晚按 Checklist 闭环处理，而不是继续和业务「对现象」：

1. 补齐反向路由与策略：B 侧注入指向新专线的回程明细；回调 VIP 与安全策略源站网段对齐；清理指向已下线地址的残余静态路由。
2. 收敛非对称：短期用策略路由强制关键子网对走同一逻辑隧道；中期把 SD-WAN/动态路由 metric 两端对称发布，取消「只在一端宣告更优」。
3. 修复 MTU 路径：放行路径上 ICMP fragmentation needed；隧道口设置合理 MTU；边界做 tcp adjust-mss；用大包业务回归确认吞吐回基线。
4. 固化验收产出物：每次跨机房变更强制附件三份——连通矩阵结果表、双向 traceroute 文本、大包测试截图/日志；缺一不结单。
5. 观察 48 小时：覆盖一次晚高峰与一次跨机房备份窗，无半通与吞吐塌陷后，再 admin-down 旧链路进入拆除排期。

根因分析

表层是「路由/策略/MTU 各改了一点却没形成闭环」，深层是验收标准错误：

1. 用连通性代替业务性：ping 通 ≠ 业务双向可用，更不等于大包与长连接可用。
2. 用单点代替矩阵：只测运维主机与个别 VIP，漏掉回调、备份、监控等反向与旁路流量。
3. 去程思维：变更单习惯写「怎么把包送过去」，很少写「包怎么原路回来」以及防火墙会话是否对称。
4. 忽视封装开销：专线/IPsec/GRE/VXLAN 叠加后有效 MTU 下降，PMTUD 若被安全策略误伤，故障只在大包时出现，白天小流量验收永远绿。
5. 缺少强制门禁：清单若只是「参考」，窗口压力下仍会被跳过；必须与结单流程绑定。

预防措施

A. 变更前（T-1）

• 导出两端路由表、策略路由、NAT、隧道 MTU/MSS、邻居状态
• 画清本次流量矩阵（至少含业务、回调、备份、运维、监控）
• 明确主路径/回退路径与可接受中断窗口
• 预置大包测试账号与 iperf/文件源，不靠临时找业务要包

B. 变更中（执行）

• 配置 diff 双人复核，禁止口播改生产
• 每完成一段切换就跑矩阵对应格子，不做「全部改完再测」
• 旧链路保持可回退，直到三道关通过

C. 变更后（验收三道关，缺一不可）

• 关 1 连通矩阵：双向 TCP/业务端口全绿，无半开连接
• 关 2 回程对称：双向 traceroute 路径符合设计，无意外旁路
• 关 3 MTU/大包：DF 大包与真实大流量业务达标
• 冗余切换与回切演练完成
• 观察期与监控基线对比通过

D. 制度化

• 把本 Checklist 嵌入变更管理系统：跨机房/跨专线类别强制模板
• 季度抽检历史变更附件，缺矩阵/缺 traceroute 记流程缺陷
• 与「机房搬迁割接」「PMTUD/黑洞」「路由震荡」类事故单做关联培训，新人上岗先跑一遍模拟矩阵

总结

跨机房链路变更最怕的不是完全不通，而是半通、大包不通、高峰才爆。把验收从「ping 一下」升级为 连通矩阵 + 回程对称 + MTU/大包 三道关，并用结单门禁卡住，是成本最低、收益最稳的防坑手段。

本篇作为网络侧方法论/Checklist，和既有的机房搬迁非对称路由、IPSec 大包/PMTUD、OSPF flap 等排查文互补：那些文章回答「出了什么事」，本清单回答「怎样在当晚就证明没出事」。建议团队直接复制表格进变更单模板，按现场拓扑改端口与代表主机，不必等下一次半夜回填再补课。