分支到总部专线丢包，视频会议为何全程卡顿？

问题背景

上海分公司通过一条 20Mbps MSTP 专线连接到北京总部。专线由电信运营商提供，两端分别接入上海分公司防火墙和北京总部核心交换机。日常业务流量包括 OA 访问、ERP 操作、邮件同步和视频会议。专线合同 SLA 为可用率 99.9%，丢包率 ≤0.1%。

故障现象

8 月 22 日下午 5:00，上海分公司的同事反馈：视频会议画面卡顿严重（人物说话 1 秒后才听到声音），访问北京总部的 OA 系统页面加载超过 30 秒。上海本地网络（访问互联网、上海分公司内部）一切正常。

1
2
3
4


# 上海分公司到北京总部核心交换机
$ ping 10.1.1.1 -c 100
100 packets transmitted, 67 received, 33% packet loss, time 99211ms
rtt min/avg/max/mdev = 38.2/52.3/89.5/12.4 ms

33% 丢包率，远超 SLA 规定的 0.1%。

排查过程

第一步：排除本地设备故障

两端防火墙和交换机的端口统计：

1
2
3
4
5
6


# 上海防火墙
FortiGate-60F # get system performance status
CPU: 12%  Memory: 45%  Sessions: 2304/50000

FortiGate-60F # diagnose sniffer packet wan1 "host 10.1.1.1" 4
# 抓到大量ICMP reply，但间隔极不均匀

1
2
3
4


# 北京核心交换机
[CE12800] display interface GigabitEthernet1/0/24
Input:  0 packets/sec, 0 error, 0 CRC error
Output: 0 packets/sec, 0 error, 0 CRC error

两端设备均无 CRC/Error 计数，排除硬件端口或光纤故障。

第二步：双向 MTR 分析

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


# 上海 → 北京
$ mtr -r -c 100 10.1.1.1
HOST                        Loss%   Snt   Avg   Best  Wrst  StDev
1. 192.168.10.1              0.0%   100   0.5   0.3   1.2   0.2
2. 172.16.100.1              0.0%   100   2.1   1.8   4.3   0.5
3. 100.64.12.1               0.0%   100   5.3   4.1   8.2   1.1
4. 100.64.13.1              28.0%   100  35.2  30.1  45.3   4.2
5. 100.64.14.1              30.0%   100  38.1  32.5  50.2   5.1
6. 100.64.12.1              32.0%   100  40.5  35.2  52.5   4.8  # 回到第3跳！
7. 100.64.13.1              33.0%   100  38.7  33.1  48.9   4.5  # 回到第4跳！
...

路由环路了——数据包在第 3-6 跳之间循环弹跳！

1
2


第3跳(100.64.12.1) → 第4跳(100.64.13.1) → 第5跳(100.64.14.1) → 
第6跳(100.64.12.1) [回到第3跳] → 循环...

数据包的 TTL 在每次路由转发时减 1，环路中弹跳约 30 次后 TTL 耗尽，数据包被丢弃——这就是 30% 丢包率的来源（IP 包默认 TTL=64，环路约 20-30 跳）。

第三步：联系运营商确认

将 MTR 结果发给电信运营商二线工程师。运营商内部排查后回复：

“上海至北京的骨干光缆于今日 15:00 进行割接维护，施工人员误将两芯光纤交叉跳接（A-B 接成了 A-A’），导致路由信息在两个城域网节点之间形成环路。我们正在重新跳接。”

运营商的施工失误导致了物理层的环路。

第四步：临时切换备用线路

上海分公司有一条 50M 互联网 VPN 做备份链路（平时不走），紧急切换：

1
2
3
4
5
6
7
8


# 在 FortiGate 上将北京总部路由的metric调低，流量走VPN备用线路
config router static
    edit 10
        set dst 10.1.1.0/24
        set device "VPN-Backup"
        set distance 5
    next
end

切换后丢包率从 33% 降到 0.5%，业务恢复。

解决方案

运营商修复光纤跳接：运营商在当晚 21:00 完成光纤重新跳接，环路消除
验证专线质量：

1
2


$ ping 10.1.1.1 -c 1000 -i 0.2
1000 packets transmitted, 999 received, 0.1% packet loss

丢包率恢复到 0.1%，符合 SLA 3. 路由切换回专线：确认专线稳定后将路由从 VPN 切回

根因分析

直接原因：运营商机房施工操作失误，光纤交叉跳接导致 IP 数据包在两个城域网节点之间形成环路，TTL 耗尽后丢包。

深层原因：分支机构到总部的专线缺少多条冗余路径（主线路 + 自动故障切换），当主线路出现运营商侧故障时业务受严重影响。虽然备有 VPN 链路，但需要手动切换。

预防措施

双专线冗余：核心分支到总部至少两条不同运营商的专线，自动故障切换
SD-WAN 方案：评估 SD-WAN 在多链路间做智能选路和链路质量监控
运营商变更窗口知会：要求运营商在进行影响本线路的维护时提前 48 小时通知
链路质量持续监控：部署 Smokeping 对专线做 7×24 的丢包率和延迟监控，异常自动告警
故障演练：每季度演练一次专线中断切换到备用链路的流程

总结

当 MTR 中出现同一个 IP 反复出现时，只有一个解释：路由环路了。运营商故障是无法完全避免的，但作为企业 IT，可以通过冗余链路和自动故障切换来降低影响。专线中断不可怕，可怕的是专线中断后业务没有自动切到备用线路——每次依赖人工介入的故障切换都是对业务可用性的赌博。