核心路由器 OSPF 邻居为何频繁 Flap?一次全网路由震荡的排查记录

核心三层交换机 OSPF 邻居频繁 Flap 导致全网路由表震荡,BGP 也受影响;根因是相邻设备 Hello/Dead timer 不一致 + passive-interface 误配 + 区域类型漂移,三层配置失配在 90 秒内触发雪崩。

问题背景

生产网络核心层由两台华为 CE12800 核心三层交换机(CR1/CR2)通过 OSPF Area 0 互联,承载全网 200+ VLAN 的三层路由。2026 年 8 月 3 日 14:20 起,监控系统连续告警「OSPF Neighbor Down/Up」,同时全网出现间歇性丢包、部分业务系统数据库连接超时。BGP(与上游 ISP 做 eBGP)也受影响,出现大量路由撤回与重新注入。初步判断为 OSPF 协议层面的路由震荡。

故障现象

  1. OSPF 邻居反复 Flap:CR1 与 CR2 的 OSPF 邻居状态在 Full ↔ Init/2-Way 之间切换,平均每 90 秒一次,持续约 40 分钟。
  2. 路由表震荡:全网路由表(含静态 + OSPF + BGP)出现大规模撤回与重新学习,RIB/FIB 频繁更新。
  3. 业务影响:核心业务数据库(MySQL 主从)出现大量「Lost connection to MySQL server during query」,部分应用接口返回 504。
  4. BGP 受波及:上游 eBGP 会话因大量路由撤回而触发 damping,部分公网路由暂时不可达。

排查过程

第一步:确认 OSPF 邻居状态与日志

在 CR1 上执行:

1
2
3
display ospf peer
display ospf interface
display ospf error

发现 CR1 与 CR2 的邻居关系频繁在 Full → Init 切换,错误日志提示:

1
OSPF/3/IFSM: OSPF 1.1.1.1 Neighbor 10.0.0.2(GE1/0/1) from Full to Init, reason: 1-WayHelloReceived

同时发现两台设备上同一个接口的 Hello timer / Dead timer 配置不一致:

  • CR1: Hello 10s, Dead 40s
  • CR2: Hello 5s, Dead 20s

第二步:检查 passive-interface 配置

继续检查接口配置:

1
display current-configuration interface GE1/0/1

发现 CR2 的上联接口意外配置了 ospf silent-interface,导致 CR2 不再发送 Hello,但仍接收 CR1 的 Hello,形成单向邻居。

第三步:检查区域类型与认证

进一步对比两台设备的 OSPF Area 配置:

  • CR1 Area 0 配置为 nssa no-import-route
  • CR2 Area 0 配置为 stub no-summary

区域类型不一致导致 LSA 类型不匹配,邻居关系无法稳定建立。

第四步:全网路由震荡原因

OSPF 邻居 Flap 直接导致:

  • 全网路由表大规模撤回(因为 OSPF 是 IGP,BGP 依赖 IGP 下一跳可达性)
  • BGP 收到大量路由撤回后触发 damping
  • 业务系统因路由瞬断而出现连接超时

解决方案

  1. 统一 Hello/Dead timer:在 CR1 与 CR2 的所有 OSPF 接口上统一配置 ospf timer hello 10 dead 40
  2. 清理 passive-interface:删除 CR2 上误配置的 ospf silent-interface,恢复双向 Hello 发送。
  3. 统一区域类型:将 CR1/CR2 Area 0 统一改为 nssa no-import-route,并在边界路由器上配置 import-route direct route-policy 精确控制路由注入。
  4. 增加认证与 BFD:开启 OSPF MD5 认证 + BFD(双向转发检测),将故障收敛时间从秒级降到毫秒级。
  5. 监控与告警:增加 OSPF 邻居状态监控 + 路由表变化速率告警,提前发现配置漂移。

根因分析

根本原因是三层配置漂移

  • 不同维护窗口由不同团队操作,Hello/Dead timer、passive-interface、区域类型三项关键参数未做版本化管理。
  • 90 秒的 Flap 周期刚好是 Dead timer 的 2 倍,属于典型的 timer 不一致导致的单向邻居。
  • passive-interface 误配 + 区域类型不匹配形成「三重失配」,任何一项修复都只能短暂缓解,最终必须三者同时统一才能根治。

预防措施

  1. 配置版本化与 Review:所有网络设备配置变更必须走 Git + Review,关键参数(timer、area type、passive)做 diff 检查。
  2. 自动化一致性巡检:每周运行一次脚本对比全网 OSPF/BGP 配置,检测 timer、area、认证差异。
  3. BFD + 快速收敛:核心链路必须开启 BFD,把协议收敛时间控制在 50ms 以内。
  4. 变更窗口隔离:网络变更必须在业务低峰期执行,变更后立即执行「配置漂移检查清单」。
  5. 监控分层告警:OSPF 邻居 Flap 告警 → 路由表变化速率告警 → 业务连接超时告警,形成三级响应。

总结

一次看似普通的 OSPF 邻居 Flap,根源是三层配置漂移累积到临界点后引发的全网级雪崩。通过统一 timer、清理 passive、统一区域类型、开启 BFD + 认证,最终将故障收敛时间从分钟级降到毫秒级。网络排障永远是「配置一致性 > 协议特性」,任何参数漂移都可能成为压垮全网的最后一根稻草。

使用 Hugo 构建
主题 StackJimmy 设计