OSPF NSSA区域默认路由发布引发的问题

　　一、关键术语

　　OSPF，NSSA，METRIC类型

　　二、设备类型和版本

　　设备类型 版本 备注

　　ZXR10 T128 与版本无关

　　ZXR10 T64G 与版本无关

　　三、网络拓扑

　　组网介绍：

　　某省的NE80或T128都属于OSPF骨干区域，每个地市都有一个独立的NSSA区域，由该地市NE80或T128充当该区域的ABR.按照规划：核心NE80向整个OSPF域下发缺省路由;各地市ABR向所在NSSA区域下发缺省路由;另外，各地市的T64G由于特殊的原因也需要通告一条默认路由(需要在ABR失效时候给其他设备通告默认路由，做为备份，图中没有表示);

　　四、故障现象描述

　　运营商反映：A市，B市和D市的流量全部中断，但C地市的业务都没有问题;问题出现时，出现故障的地市T128的缺省路由都指向了本市的核心交换机T64G。通过在三台ABR上添加默认路由指到骨干区域，故障得以恢复;经检查，C地市之所以没有出现故障是因为T128上配置了静态的默认路由;

　　五、处理方法

　　为什么出现问题时，作为ABR的NE80和T128，其默认路由会指到T64G?让我们先看一下做为ABR的T128以及T64G的配置是怎样的：

　　T64G：

　　router ospf 1router-id 222.49.10.254network 222.49.10.132 0.0.0.3 area 0.0.3.28network 222.49.10.148 0.0.0.3 area 0.0.3.28network 222.49.10.152 0.0.0.3 area 0.0.3.28network 222.49.10.156 0.0.0.3 area 0.0.3.28network 222.49.10.254 0.0.0.0 area 0.0.3.28area 0.0.3.28 authentication message-digestarea 0.0.3.28 nssa default-information-originate no-summary　//因特殊需要发布的缺省路由redistribute connectedredistribute static

　　注：OSPF协议并没有规定NSSA内部路由器不能发布缺省路由

　　T128：

　　T128-R1#sh run | be router ospfBuilding configuration...router ospf 1router-id 222.49.10.250network 222.49.10.128 0.0.0.3 area 0.0.0.0network 222.49.10.132 0.0.0.3 area 0.0.3.28network 222.49.10.136 0.0.0.3 area 0.0.3.28network 222.49.10.250 0.0.0.0 area 0.0.0.0area 0.0.3.28 authentication message-digestarea 0.0.3.28 nssa default-information-originate no-summary　//做为ABR向NSSA内部发布的缺省路由

　　正常情况下，T128会学习骨干NE80发布的缺省路由，而不会学习T64G发布的缺省路由，那么故障发生时，最大的可能性就是NE80的缺省路由失效了：

　　在故障恢复后，我们查看T128的database，发现了两条默认路由的LSA：

　　Type-5 AS External Link States

　　LS age: 1493Options: (No TOS-capability, No DC)LS Type: AS External LinkLink State ID: 0.0.0.0 (External Network Number)Advertising Router: 211.98.46.230 //经查证是核心NE80的loopbackLS Seq Number: 0x80007154Checksum: 0x1abdLength: 36Network Mask: /0Metric Type: 2 (Larger than any link state path)TOS: 0Metric: 1000Forward Address: 0.0.0.0

　　Type-7 AS External Link States (Area 0.0.3.28)

　　LS age: 968Options: (No TOS-capability, No Type 7/5 translation, No DC)LS Type: AS External LinkLink State ID: 0.0.0.0 (External Network Number)Advertising Router: 222.49.10.254//是NSSA内部的T64GLS Seq Number: 0x80002373Checksum: 0x881aLength: 36Network Mask: /0Metric Type: 2 (Larger than any link state path)TOS: 0Metric: 1Forward Address: 0.0.0.0

　　从上面的结果来看，核心NE80所发布的默认路由LSA并没有丢失，那为什么在故障发生时，T128却将默认路由指向了T64G呢?经过仔细比对两条LSA，见上面红色标注部分：

　　核心NE80发布 T64G发布

　　LSA类型 LSA 5 LSA 7

　　Metric Type 类型2 类型2

　　Metric 1000 1

　　发现，两个LSA的类型不同，那个更优先呢?经过咨询研发，答案是没有差别，优先级一样!那Metric Type又一样，只有Metric不同，T64G发布的默认路由的Metric更低;这就解释了为什么T128的默认路由指向了T64G!

　　但另外一个问题随之而来，之前业务一切正常时候，T128的默认为什么会指向骨干域呢?难道是核心NE80在故障发生时修改了配置?又或者核心NE80通告的默认路由Metric发生了变化?根据已知的信息和局方沟通，局方排查网络后，问题原来另有原因：

　　实际上，在之前网络一切正常的时候，T128上面应该能看到三条LSA，除了上述两条之外，还有一条：

　　Type-5 AS External Link States

　　Routing Bit Set on this LSALS age: 1295Options: (No TOS-capability, No DC)LS Type: AS External LinkLink State ID: 0.0.0.0 (External Network Number)Advertising Router: 211.98.46.234//A地市NE80的loopbackLS Seq Number: 0x80000053Checksum: 0xd4f1Length: 36Network Mask: /0Metric Type: 1 (Comparable directly to link state metric)TOS: 0Metric: 1000Forward Address: 0.0.0.0

　　原来，作为A地市ABR的NE80之前也一直在通告默认路由，我们不妨再将三条默认路由的LSA做一下比较：

　　核心NE80发布 T64G发布 A地市NE80发布

　　LSA类型 LSA 5 LSA 7 LSA 5

　　Metric Type 类型2 类型2 类型1

　　Metric 1000 1 1000

　　经过咨询研发，由于OSPF 外部路由引入类型1要比类型2优先，因此之前各地市的默认路由实际上是由A地市的NE80通告产生的，那为什么流量没有因为送到A地市NE80通告的默认路由而继续将数据发送到A地市的NE80呢?这是由现场的组网环境所决定的，由于其他地市ABR到达A地市NE80都要经过省核心NE80，流量一旦到了核心NE80就直接走静态默认路由出去了，而不会送到宜春NE80;

　　当天出现故障的时候，由于宜春NE80发生了异常，导致其宣告的默认路由失效，因此才会导致故障的出现;可见，原先表面上看起来是正常工作的网络实际上暗藏许多问题。

　　目前，局方已经将T64G上通告的默认路由取消，NSSA区域内部的冗余性改由其他方式提供;

　　当然，也可以通过修改T64G上通告默认路由的Metric值来规避故障(改大)，但还是建议取消其通告的默认路由

　　六、故障处理总结

　　1、用户业务正常不代表网络运行正常;

　　2、合理的路由规划非常重要;

　　3、故障出现时，第一是恢复用户业务，其次才是查找故障原因;

　　七、备注

　　介绍下默认路由的比较规则：

　　3型 > ext1 5/7 >ext2 5/7

　　如果ext-type 相同

　　metric 小的优先

　　如果还区分不开

　　nssa +p(7型) > ase(5型) >nssa no p(7型)

　　p是NSSA LSA上的是否翻译的选项

　　关于ext-type(就是metric type)，1型是骨干网上最经常使用的，因为他还能计算出OSPF区域内部的cost值，为路由的灵活控制和优化提供了可能;

　　另外，当一个OSPF区域有两个ASBR的时候，他们通告的默认路由一定要保持ext-type一致。