一次OSPF路由震荡导致跨机房业务间歇性中断的排查实录

发表于 分类于 ， 阅读次数： 本文字数： 3.2k 阅读时长 ≈ 12 分钟

问题背景

周一早晨8:15，IT运维组值班手机开始收到一连串业务投诉——总部办公区（DC-A）用户访问部署在分支机房（DC-B）的ERP系统时，页面每隔5~8分钟就会出现约30秒的”卡死”现象：页面加载超时、报表查询报错、部分用户甚至看到502 Bad Gateway。受影响用户约180人，集中在财务和采购部门，这两个部门对ERP依赖度最高，故障紧急度评级P1。

DC-A与DC-B之间通过10Gbps专线互联，核心交换机之间建立OSPF Area 0邻接关系，各机房内部使用Area 1/2。两机房BGP使用各自AS号（65001/65002），通过OSPF学习对方的互联地址作为BGP下一跳。正常情况下，OSPF邻接稳定，BGP路由下一跳始终可达，跨机房流量畅通无阻。

故障持续时间约2小时，期间ERP服务本身运行正常（DC-B内部用户无任何异常），问题明确指向跨机房网络层面。

故障现象

监控层面：Zabbix采集的ERP前端响应时间曲线呈现明显的周期性尖刺——基线200ms，每5~8分钟突然飙至3000ms以上，持续约30秒后回落。对应时段，Grafana上的跨机房TCP连接数从稳态的120条骤降至0，HTTP 5xx错误率同步跳升。

用户层面：财务部张经理反馈”9:00打开应付账款页面卡了半分钟，刷新后又好了，过几分钟又卡”；采购部多人报告提交采购单时超时报错。

网络层面：在DC-A核心交换机（CE6850-01）上持续观察BGP路由表，发现DC-B侧的172.16.0.0/16网段路由在反复出现和消失：

1
2
3
4
5
6
7
<CE6850-01> display bgp routing-table 172.16.0.0
  Network          NextHop        Med  LocPrf  Pref  Path
*  172.16.0.0/16   10.0.0.2       0    100     255  65002 I
  // 30秒后路由消失
<CE6850-01> display bgp routing-table 172.16.0.0
  // No entry found
  // 再过20秒路由恢复

BGP路由的下一跳10.0.0.2是DC-B核心交换机的互联地址，通过OSPF学习。当OSPF邻接断开时，10.0.0.2的路由消失，BGP判定下一跳不可达，撤销172.16.0.0/16路由；OSPF邻接恢复后，下一跳重新可达，BGP路由重新生效。这正是典型的”OSPF驱动BGP路由震荡”模式。

排查过程

第一步：确认故障范围与定性

第一时间在DC-A核心交换机上Ping DC-B互联地址：

1
2
3
4
5
6
7
8
9
<CE6850-01> ping 10.0.0.2 repeat 100
  Reply from 10.0.0.2: bytes=64 time=1ms TTL=255
  Reply from 10.0.0.2: bytes=64 time=1ms TTL=255
  Request timeout
  Request timeout
  Request timeout
  Request timeout
  Request timeout
  Reply from 10.0.0.2: bytes=64 time=1ms TTL=255

Ping结果呈现周期性超时——连续5~6个包超时后恢复，与业务监控的尖刺周期吻合。用大包测试进一步确认：

1
2
<CE6850-01> ping 10.0.0.2 size 4000 repeat 50
  // 大包丢包率高达40%，小包丢包率仅8%

小包丢包率远低于大包，这提示物理层可能存在误码问题——小包CRC校验通过的几率更高，大包更容易被误码破坏。

第二步：检查OSPF邻接状态

1
2
3
4
5
6
7
8
9
<CE6850-01> display ospf peer
  Area 0.0.0.0
    Neighbor 10.0.0.2, Interface GE1/0/1
      State: Full  -> 正常时
    // 故障时段观察
    Neighbor 10.0.0.2, Interface GE1/0/1
      State: Init  -> 邻接断开
      State: ExStart -> 正在重建
      State: Full  -> 重新建立

开启OSPF事件调试进一步观察邻接变化细节：

1
2
3
4
5
6
7
<CE6850-01> debugging ospf event
  OSPF/Event: Nbr 10.0.0.2 state changed: Full -> Down (Receive bad hello seq)
  OSPF/Event: Nbr 10.0.0.2 state changed: Down -> Init (Hello received)
  OSPF/Event: Nbr 10.0.0.2 state changed: Init -> 2-Way (2-Way received)
  OSPF/Event: Nbr 10.0.0.2 state changed: 2-Way -> ExStart (Negotiation done)
  OSPF/Event: Nbr 10.0.0.2 state changed: ExStart -> Exchange (DB exchange)
  OSPF/Event: Nbr 10.0.2 state changed: Exchange -> Full (Adjacency done)

OSPF邻接从Full断到Down再到恢复Full，整个过程约25~30秒，与业务中断时长一致。关键信息是Receive bad hello seq——收到了错误的Hello报文序列号，说明Hello报文在传输过程中被损坏。

第三步：检查物理接口状态

这是最关键的一步。查看互联端口GE1/0/1的统计信息：

1
2
3
4
5
6
7
8
9
10
11
12
13
<CE6850-01> display interface GE1/0/1
  GE1/0/1 current state: UP
  Last 300 seconds input rate: 854 bits/sec, 3 packets/sec
  Last 300 seconds output rate: 1236 bits/sec, 5 packets/sec
  Input:
    Total packets: 94782
    CRC errors: 3847           <-- 异常！正常应接近0
    Frame errors: 0
    Overrun: 0
  Output:
    Total packets: 94521
    CRC errors: 0
    Collision: 0

CRC错误计数3847，而且每分钟还在增长约50~60个！端口当前状态是UP（没有进入error-disable），但持续增长的CRC误码意味着大量报文在物理层被损坏——OSPF Hello报文、DD报文、LS Update报文都可能被CRC校验失败丢弃，导致邻接关系反复中断。

查看DC-B侧的对应端口，同样有CRC计数增长：

1
2
<CE6850-02> display interface GE1/0/1
  Input CRC errors: 3612       <-- 对端也在涨

双向CRC错误都在增长，基本排除了单端交换机端口硬件故障的可能性，指向中间的物理链路——光纤本身或接头。

第四步：排查光纤链路

DC-A与DC-B之间10G专线通过ODF（光纤配线架）跳接，路径为：CE6850-01 GE1/0/1 → LC光纤 → ODF-A M3/V3 → 室内光缆 → ODF-B M3/V3 → LC光纤 → CE6850-02 GE1/0/1。

先在交换机上开启光功率监测：

1
2
3
4
5
6
7
8
<CE6850-01> display interface GE1/0/1 transceiver
  Rx Power: -14.2 dBm     <-- 偏低！10G LR正常范围 -6~-20dBm，但已接近下限
  Tx Power: -2.1 dBm      <-- 正常
  Rx Loss: 12.1 dB        <-- 光衰偏大

<CE6850-02> display interface GE1/0/1 transceiver
  Rx Power: -13.8 dBm
  Tx Power: -2.3 dBm

两端收光功率均偏低约3dBm，光衰偏大。15km LR模块正常光衰应在6~8dB，实测12dB明显偏高。这说明链路中存在额外的光损耗点。

第五步：定位光损耗点

联系机房驻场同事到ODF架现场检查。同事反馈：ODF-A侧M3/V3端口的LC适配器内积有明显灰尘，尾纤插入时感觉松动。用光纤端面检测仪（Fiber Microscope）观察该适配器：

  • 适配器内芯有黑色颗粒污染物
  • 尾纤端面也有轻微划痕和灰尘

这就是CRC误码的物理根因——适配器污染导致光纤端面之间存在空气间隙和散射，部分光信号在接头处被反射和散射（高回波损耗+高插入损耗），接收端收到的光信号功率偏低且带有失真，导致CRC校验失败。

同事用光纤清洁笔（One-Click Cleaner）清洁适配器内芯和尾纤端面后，重新插接：

1
2
3
<CE6850-01> display interface GE1/0/1 transceiver
  Rx Power: -6.8 dBm       <--恢复正常范围！
  Rx Loss: 6.8 dB           <--光衰恢复正常

同时CRC计数停止增长，Ping大包测试丢包率归零：

1
2
<CE6850-01> ping 10.0.0.2 size 4000 repeat 100
  100 packets transmitted, 100 received, 0% loss

OSPF邻接立即恢复稳定：

1
2
<CE6850-01> display ospf peer
  Neighbor 10.0.0.2, State: Full  (stable for 15 min)

BGP路由恢复稳定，ERP访问恢复正常，故障解除。从发现CRC异常到清洁光纤接头，整个过程约40分钟。

解决方案

紧急止血

  1. 清洁光纤接头：用One-Click Cleaner清洁ODF-A M3/V3适配器内芯和对应尾纤端面，重新插接后光功率恢复正常，CRC误码消失
  2. 重置接口计数器：执行reset counters interface GE1/0/1清零CRC计数，便于后续观察是否复发

根治措施

  1. 更换退化适配器：ODF-A M3/V3的LC适配器因长期插拔和污染，内部陶瓷套管已有轻微磨损，更换为新的LC双芯适配器
  2. 更换受损尾纤：端面有划痕的尾纤更换为新尾纤，旧尾纤端面划痕无法修复
  3. OSPF稳定性增强：调整OSPF Hello间隔和死亡间隔，增加邻接容错能力：
1
2
3
4
interface GE1/0/1
  ospf timer hello 15        // 从默认10秒改为15秒，减少Hello报文频率
  ospf timer dead 60         // 从默认40秒改为60秒，给邻接更多恢复窗口
  ospf authentication-mode md5 1 cipher XXXXXX  // 增加认证防止非法报文干扰
  1. BGP震荡抑制：配置BGP路由衰减（route dampening），防止震荡路由反复注入转发表：
1
2
bgp 65001
  route-dampening half-life-reachable 15 half-life-unreachable 15 reuse 750 suppress 2000 max-suppress-time 60
  1. 物理层监控：在Zabbix添加CRC计数器监控项，设置阈值告警：
1
2
3
监控项: snmp.get[ifInErrors.{#IFINDEX}]  // CRC错误计数
触发器: CRC错误增量 > 50/分钟 → P2告警
触发器: CRC错误增量 > 200/分钟 → P1告警
  1. 光功率监控：通过SNMP采集光模块收发功率，设置偏差告警：
1
2
3
监控项: optical.rxpower[GE1/0/1]
触发器: Rx Power < -10dBm → P2告警（光衰偏高预警）
触发器: Rx Power < -18dBm → P1告警（即将断光）

根因分析

本次故障的根本原因是ODF光纤适配器内芯污染导致的光信号衰减和失真，进而引发CRC误码→OSPF报文丢弃→邻接断建→BGP下一跳可达性波动→路由震荡→业务间歇中断，形成了一条从物理层到应用层的完整故障传导链。

适配器污染的原因有二：

  1. 日常维护不规范：机房ODF架近期有其他业务割接施工（周三新增一条2.5G专线），施工人员在ODF架操作时拔插了相邻M3/V3端口的尾纤用于测试，插回时未清洁端面，将手指油脂和灰尘带入适配器内芯
  2. 缺乏端面清洁SOP：团队光纤操作规范中没有”插接前必须清洁端面”的强制要求，日常巡检也不检查ODF适配器清洁度

光功率从-6.8dBm退化到-14.2dBm（增加了约7dB损耗），恰好是污染适配器造成的额外插入损耗。这个损耗水平尚在光模块接收灵敏度范围内（-20dBm），所以端口没有down，但信号质量已经劣化到足以产生大量CRC错误——这就是”端口UP但业务断”的典型场景。

预防措施

  1. 光纤操作SOP：制定并强制执行《ODF光纤操作规范》——任何拔插光纤操作必须先用One-Click Cleaner清洁端面和适配器，操作前后用端面检测仪确认清洁度。将此规范纳入变更管理流程，割接方案必须包含光纤清洁步骤

  2. ODF适配器防护：空闲端口必须安装防尘帽，施工结束后检查相邻端口防尘帽是否完好。ODF架门保持关闭，减少灰尘侵入

  3. 物理层监控体系：将CRC错误计数和光模块功率纳入核心监控，设置分级告警阈值。CRC错误是物理层故障的”早期信号”——远比端口down更早出现，做到故障预警而非故障后才发现

  4. 光纤巡检制度化：每季度对所有ODF架做一次光功率测试+端面检测，记录光衰基线数据。光衰异常增长>2dB的链路标记为”需维护”，安排清洁或更换

  5. OSPF/BGP震荡防护：核心互联链路OSPF参数适当放宽（Hello 15秒、Dead 60秒），为物理层短暂抖动提供缓冲窗口；BGP开启route dampening，抑制震荡路由对转发表的反复冲击

  6. 跨机房业务连续性增强：评估增加DC-A到DC-B的第二条互联链路（冗余路径），当主链路OSPF震荡时流量自动切换到备用链路，消除单链路故障对业务的影响

总结

这次故障的教训是：物理层的微小退化可以引发网络层的大规模震荡。一个ODF适配器里几粒灰尘，让光衰增加7dB，CRC误码飙升，最终导致180人的ERP服务反复中断2小时。

排查的关键转折点是在接口统计中发现CRC错误计数持续增长——如果只看端口状态（UP），永远找不到根因。这也提醒我们，网络监控不能只盯着”端口UP/DOWN”和”带宽利用率”，CRC错误、光功率这些物理层指标同样是核心监控项，而且往往能提前预警。

OSPF→BGP的震荡传导机制也值得牢记：当BGP下一跳依赖OSPF路由时，OSPF邻接的任何抖动都会直接传导到BGP路由层。在核心互联设计中，要么让BGP下一跳不依赖OSPF（比如用直连地址做下一跳），要么给OSPF足够的容错参数，要么开启BGP dampening抑制震荡——三条防线缺一不可。

最后，光纤端面清洁这个看似琐碎的操作，实际上是机房物理层可靠性的基础。一根未清洁的尾纤，可能就是下一次P1故障的起点。