BGP on Zero Day Notes

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

Sun, 05 Jul 2026 07:00:00 +0000

问题背景

周一早晨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网段路由在反复出现和消失：

<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互联地址：

<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邻接状态

<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事件调试进一步观察邻接变化细节：

<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的统计信息：

<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。

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

<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分钟。

解决方案

紧急止血

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

根治措施

更换退化适配器：ODF-A M3/V3的LC适配器因长期插拔和污染，内部陶瓷套管已有轻微磨损，更换为新的LC双芯适配器
更换受损尾纤：端面有划痕的尾纤更换为新尾纤，旧尾纤端面划痕无法修复
OSPF稳定性增强：调整OSPF Hello间隔和死亡间隔，增加邻接容错能力：

interface GE1/0/1
  ospf timer hello 15        // 从默认10秒改为15秒，减少Hello报文频率
  ospf timer dead 60         // 从默认40秒改为60秒，给邻接更多恢复窗口
  ospf authentication-mode md5 1 cipher XXXXXX  // 增加认证防止非法报文干扰

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

物理层监控：在Zabbix添加CRC计数器监控项，设置阈值告警：

1
2
3

监控项: snmp.get[ifInErrors.{#IFINDEX}]  // CRC错误计数
触发器: CRC错误增量 > 50/分钟 → P2告警
触发器: CRC错误增量 > 200/分钟 → P1告警

光功率监控：通过SNMP采集光模块收发功率，设置偏差告警：

1
2
3

监控项: optical.rxpower[GE1/0/1]
触发器: Rx Power < -10dBm → P2告警（光衰偏高预警）
触发器: Rx Power < -18dBm → P1告警（即将断光）

根因分析

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

适配器污染的原因有二：

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

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

预防措施

光纤操作SOP：制定并强制执行《ODF光纤操作规范》——任何拔插光纤操作必须先用One-Click Cleaner清洁端面和适配器，操作前后用端面检测仪确认清洁度。将此规范纳入变更管理流程，割接方案必须包含光纤清洁步骤
ODF适配器防护：空闲端口必须安装防尘帽，施工结束后检查相邻端口防尘帽是否完好。ODF架门保持关闭，减少灰尘侵入
物理层监控体系：将CRC错误计数和光模块功率纳入核心监控，设置分级告警阈值。CRC错误是物理层故障的"早期信号"——远比端口down更早出现，做到故障预警而非故障后才发现
光纤巡检制度化：每季度对所有ODF架做一次光功率测试+端面检测，记录光衰基线数据。光衰异常增长>2dB的链路标记为"需维护"，安排清洁或更换
OSPF/BGP震荡防护：核心互联链路OSPF参数适当放宽（Hello 15秒、Dead 60秒），为物理层短暂抖动提供缓冲窗口；BGP开启route dampening，抑制震荡路由对转发表的反复冲击
跨机房业务连续性增强：评估增加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故障的起点。

一次BGP双线接入因AS-PATH策略错误导致业务流量全部走错运营商的排查实录

Tue, 23 Jun 2026 06:55:12 +0000

问题背景

总部机房采用"电信+联通"双线BGP接入架构，核心交换机与两家运营商建立eBGP邻居，通过AS-PATH属性和route-map实现流量调度——默认走电信、联通作为备份，特定网段走联通做负载。某周一下午14:30左右，研发同事反映访问部署在阿里云华东节点的多个API接口（用户中心、订单查询、支付回调）出现持续性卡顿，单次请求从正常的80ms飙升到500ms以上，短信网关、第三方支付回调更是出现间歇性超时。客服部门同步反馈多名用户投诉"支付完成但订单状态未更新"。

故障现象

通过Zabbix监控看到关键业务指标异常：

14:32:01  Gateway-IP-Monitor  WARN  核心交换机到阿里云华东(47.110.x.x)延迟 412ms (基线 35ms)
14:32:01  BGP-Session-Monitor  INFO  eBGP 电信邻居 10.10.1.1 Established  (Up 87d 4h)
14:32:01  BGP-Session-Monitor  INFO  eBGP 联通邻居 10.10.2.1 Established  (Up 87d 4h)
14:32:15  Zabbix-Trapper        CRIT  HTTP 业务探测 api.example.com 5xx 告警 (连续3次)
14:32:30  Zabbix-Trapper        CRIT  支付回调响应时间 > 5s (SLA违约)

在核心交换机上查看路由表：

<Switch> display bgp routing-table ipv4 unicast brief
Total Number of Routes: 412,387
Network            NextHop        MED     LocPrf  PrefVal  Path/Ogn

*  47.110.0.0/16     10.10.2.1      0       100     0        4134  ?
*  47.110.0.0/16     10.10.1.1      0       100     0        4134 100 200 ?

诡异的事情出现了：阿里云华东段（47.110.0.0/16）的两条路由都被打上了"无效标记"（问号?），其中电信链路（AS4134 → AS100 → AS200）多了一段莫名其妙的AS-PATH"100 200"，而正常情况下电信学到该网段的AS-PATH应该只显示"4134"或"4134 100"。

排查过程

第一步：确认BGP邻居状态正常

两条eBGP邻居均显示Established，消息收发计数没有异常抖动，说明TCP连接、Keepalive、BGP Open报文一切正常，问题出在路由策略层。

第二步：检查入方向route-map

display current-configuration | include route-map 找到关键策略段：

route-map FROM-TELECOM-IN permit 10
 description Accept legitimate telecom routes
 match as-path 10
!
route-map FROM-TELECOM-IN deny 20
 description Reject transit routes
 match as-path 20
!
ip as-path 10 permit ^(4134_)+$
ip as-path 20 permit _100_200_

看到as-path 20那行瞬间明白问题所在——正则_100_200_会匹配任何包含"100 200"两个相邻AS的路径，包括电信运营商内部传递过来的真实路由。当时我们调度的逻辑是"拒绝任何包含私有AS号100、200的路径"，但忘记了一个事实：电信骨干网在传递某些跨网段路由时，会在AS-PATH中插入"100 200"作为内部标记（这是中国电信AS4134的私有AS号，用于内部选路标记）。

第三步：验证猜想

在核心交换机上抓取近期BGP Update报文，过滤AS-PATH含"100 200"的路由前缀数量：

1
2
3

<Switch> display bgp update-peer-group 10.10.1.1 statistics
...
Prefix count with AS-PATH matched _100_200_: 287,341

近30万条合法路由被这条正则误杀，全部进了BGP RIB-in的"待丢弃"队列，对端却还以为邻居都正常、路由都通告了。

第四步：检查本地注入的BGP路由

为防止出现路由黑洞，运维A同事把核心交换机的LoopBack0（10.255.0.1/32）通过network命令注入BGP，这条命令的下一跳指向10.10.1.1（电信），触发了一段被错误拒绝的AS-PATH。

<Switch> display bgp routing-table 10.255.0.1
BGP local router ID is 10.255.0.1
Status codes: * - valid, > - best, d - damped, h - history,
              s - suppressed, S - stale, i - internal, b - backup
Origin: i - IGP, e - EGP, ? - incomplete

Total Number of Routes: 0

连自己的LoopBack都没被优选——所有从电信学到的路由都被route-map打上"无效"标记，对端联通的路由因为local-preference默认100而进入主表，但很多明细网段联通链路延迟本来就高，导致从核心出去的流量"全跑联通"。

第五步：与运营商侧核对

拨通电信大客户经理电话，对方工程师确认他们在上周末升级了AS4134的出口策略，会在AS-PATH中插入"100 200"作为新引入的BGP选路标记。也就是说不止我们这端，所有走电信BGP接入的企业客户都受到了影响——只是我们这条正则写得太严格。

第六步：临时止血

先把误杀的AS-PATH正则屏蔽掉，恢复路由：

`1`	`no ip as-path 20`

60秒后，路由表刷新，47.110.0.0/16的两条路由恢复正常选路，业务延迟从412ms回到35ms基线。

解决方案

长期方案：改用AS-PATH长度作为判定标准

“100 200"只是运营商内部标记，不能简单粗暴作为业务流的甄别依据。改为基于AS-PATH长度做拒绝：

1
2
3

ip as-path 10 permit ^(4134_)+$
ip as-path 20 permit _(6451[2-9]|6553[0-5])_
ip as-path 30 permit ^[0-9]+$  ! 只允许单一AS的路由（对端直连段）

只拒绝真正属于RFC 6996保留私有AS号的路径，避免误伤。

给route-map加日志计数

route-map FROM-TELECOM-IN deny 20
 description Reject private AS
 match as-path 20
 set traffic-index 99

配合流量监控，一旦被拒绝的路由条目激增立即告警。

增加BGP邻居级监控

在Zabbix上对每个BGP邻居的关键指标做模板化：

指标	告警阈值
收到的BGP路由前缀数	±20% baseline
AS-PATH 拒绝计数	> 0
Update 报文频率	> 1000/分钟
BGP邻居翻动次数	> 0/小时

关键配置变更走代码评审

这条ip as-path 20 permit _100_200_是去年一个临时调试遗留的命令，没有走严格的code review，从那之后就一直在线上跑了——是典型的"运行久了就以为是正确的"陷阱。

根因分析

直接原因：去年临时调试写的ip as-path 20 permit _100_200_正则没有清理，该正则的本意是拒绝经过某些对等AS的路由，但因为AS-PATH正则下划线表示"任意字符串边界”，_100_200_实际匹配的是"含100和200这两个相邻AS号的所有路径"。

深层原因：电信AS4134骨干网升级后，在跨网传递路由时会在AS-PATH中追加"100 200"作为内部标记，这本来是合法的BGP属性，但与我们的策略冲突，导致近30万条路由被误判无效。

运营原因：路由策略类变更缺乏变更评审、回归测试、监控告警机制，“上线即正确"的惯性思维让这条命令在线上跑了8个多月，直到电信骨干网升级才暴露出问题。

预防措施

1. 路由策略变更必须走变更窗口

所有涉及route-map、ip as-path、ip community-list、ip prefix-list的变更，必须在业务低峰期执行，且必须经过至少一名网络架构师评审，并保留前后配置对比。

2. 部署"路由沙盒”

搭建一个隔离的BGP测试环境，使用Bird或FRRouting跑一个真实环境的镜像，配置变更先在沙盒里跑24小时观察，再上生产。

3. 完善BGP监控体系

每分钟采集BGP邻居的Received/Active Routes数量
对AS-PATH regex匹配做计数器
任何route-map的deny规则都应配WELF/Syslog上报

4. 与运营商建立常态化沟通机制

每次运营商侧骨干网升级、AS号调整、出口策略变化，都应在第一时间拿到变更通知单，评估对自有路由策略的影响。

5. 路由策略配置文件纳入Git管理

把核心交换机的配置按以下目录结构纳入Git：

network-config/
├── core-sw-01/
│   ├── bgp.conf
│   ├── route-map.conf
│   └── changelog.md
├── core-sw-02/
└── README.md

每次配置变更都走commit-msg规范，“为什么要这样配"的业务背景要写在commit信息里，避免半年后回看一脸懵。

总结

这次故障给我们最深的教训是：网络策略的"误拒绝"比"误允许"更隐蔽。误允许会立刻有告警（被拒绝的路由完全消失、流量中断），而误拒绝会让路由"看起来还在”（实际被打上无效标记），却悄悄把流量引到错误的路径上，影响业务却难以第一时间定位。

后续我们把"路由策略变更必须配监控"写进了运维SOP：任何新增的deny规则、任何修改的正则表达式、任何调整的local-preference，都必须配套一条监控项，且这条监控的告警接收人是这次变更的提交人本人——谁改的，谁兜底。

BGP是互联网的"神经系统"，容不得半点马虎。