当OSPF遇到ISIS：一次双点双向重发布引发的‘路由风暴’与我的排错实录
当OSPF遇到ISIS：一次双点双向重发布引发的‘路由风暴’与我的排错实录
凌晨2点15分，监控大屏突然跳出红色告警——核心业务网段的延迟从3ms飙升到800ms。作为当晚的值班工程师，我立刻意识到这不是普通的网络抖动。登录核心路由器查看BGP邻居状态，意外发现OSPF和IS-IS的路由表正在以每秒数百条的速度刷新。一场由双点双向重发布引发的"路由风暴"正在吞噬整个自治系统。
1. 故障现象：当网络开始"打摆子"
那是我参与过的规模最大的跨协议域网络融合项目。客户需要将原有OSPF骨干网与新建的IS-IS数据中心网络进行互通，按照标准方案在R2和R4两台边界路由器上配置了双点双向重发布。割接后前两小时一切正常，直到突然出现以下异常现象：
- 路由震荡：
show ip route输出以肉眼可见的速度刷新，路由条目不断在OSPF和IS-IS之间切换 - CPU过载：边界路由器的CPU利用率突破90%，
process cpu显示路由计算进程占用了75%资源 - 次优路径：原本应该通过IS-IS直达的/24网段，实际走了OSPF的迂回路径，导致延迟增加20倍
- 部分丢包：持续ping测试中出现5%-10%的丢包率，traceroute显示路径在R2和R4之间来回跳变
抓包分析显示，R2的Gig0/0/1接口每秒收到超过2000条LSA更新，而R4的IS-IS链路状态PDU（LSP）泛洪间隔从正常的30分钟缩短到15秒。这明显是典型的路由环路特征，但奇怪的是，传统的debug ip ospf events并没有显示异常的路由计算。
2. 根因分析：隐藏在Tag机制下的"死亡螺旋"
经过3小时的深度排查，终于定位到问题本质——双向重发布导致的路由反馈环路。具体机制如下：
初始状态：
- R2将OSPF路由（Tag=10）重发布到IS-IS
- R4将IS-IS路由（Tag=20）重发布到OSPF
环路形成：
R2: OSPF(Tag=10) → ISIS → R4: ISIS → OSPF(Tag=30) → R2: OSPF(Tag=30) → ISIS → R4: ISIS → OSPF(Tag=10)...这个循环过程使得同一条路由在协议间不断被重新注入，形成正反馈。
关键缺陷：
- 原配置虽然使用了Tag过滤，但两个边界节点的策略存在逻辑漏洞
- OSPF外部路由的默认优先级（150）高于IS-IS（115），导致次优路径
- 缺少路由度量值（metric）的转换控制，使得重发布路由比原生路由更优
通过show route-map命令发现，R4上配置的route-policy存在规则顺序错误：
route-policy ito deny node 10 if-match tag 20 # 应改为deny tag 10 permit node 20 apply tag 40这个错误导致部分携带Tag=10的路由被错误地再次重发布回IS-IS。
3. 解决方案：四层防御体系的构建
基于上述分析，我们实施了分阶段的解决方案：
3.1 紧急止血措施
- 立即生效的CLI命令：
! 在R2和R4上执行 configure terminal router ospf 1 no redistribute isis subnets router isis no redistribute ospf 1 end clear ip ospf process # 强制OSPF进程重启 - 临时路由过滤：
access-list 100 deny ip any 192.168.0.0 0.0.255.255 access-list 100 permit ip any any route-map FILTER deny 10 match ip address 100 route-map FILTER permit 20
3.2 永久修复方案
我们重新设计了路由策略架构，包含四重防护：
| 防护层 | 实现机制 | 配置示例 |
|---|---|---|
| Tag过滤 | 双向独立Tag标识 | apply tag 100 |
| 路由偏好 | 调整协议优先级 | preference 200 |
| 度量值控制 | 设置基准metric | default-metric 50 |
| 前缀列表 | 精确控制重发布范围 | ip prefix-list |
完整配置示例（以R2为例）：
route-policy OSPF-to-ISIS deny node 10 if-match tag 100 permit node 20 apply tag 200 set metric 50 set preference 200 ! router ospf 1 redistribute isis route-policy ISIS-to-OSPF default-metric 30 ! router isis redistribute ospf 1 route-policy OSPF-to-ISIS metric-style wide3.3 验证方法
为确保方案有效性，我们设计了三级验证体系：
- 基础连通性测试：
ping 192.168.1.1 source 192.168.2.1 repeat 1000 - 路由稳定性监控：
watch -n 1 "show ip route 192.168.1.1 | include via" - 协议分析工具：
ospf.type == 4 || isis.type == 18 # 过滤LSU和LSP报文
4. 经验总结：多协议融合的黄金法则
这次事故让我深刻认识到，双点双向重发布就像网络世界的"核按钮"，必须谨慎操作。以下是沉淀的实战经验：
- 标签策略：确保每个方向的Tag值唯一且互斥，建议采用奇偶分配方案（如OSPF→ISIS用奇数，反向用偶数）
- 度量基准：统一设置
default-metric，建议OSPF外部路由的基准值高于IS-IS Level-2路由 - 防环设计：必须实现"两点一致性原则"——两个重发布点的过滤策略要逻辑对称但参数互补
- 监控要点：
- 重点关注
ospfExternalLsa和isisLspGenInterval计数器 - 设置CPU利用率超过70%时的自动告警
- 定期检查
show route-map counters的匹配情况
- 重点关注
在后续的金融行业SD-WAN项目中，我们开发了自动化检查工具，可以提前发现策略冲突。有次预演环境检测到类似配置错误，避免了生产环境的事故。这套方法后来成为我们团队处理多协议融合的标准流程。