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

会计考友

一、关键术语
OSPF，NSSA，METRIC类型
3 f( p# T) t2 P/ ~1 S; w二、设备类型和版本
# ]9 I6 H! V+ _" y设备类型 版本 备注
" P8 K4 x7 e/ _. CZXR10 T128 与版本无关
ZXR10 T64G 与版本无关
. T; ?4 G  t, v4 W三、网络拓扑
% o3 W% E" n' A7 g498)this.style.width=498;" border=0> 组网介绍：
4 r0 D- }+ G7 i6 u
某省的NE80或T128都属于OSPF骨干区域，每个地市都有一个独立的NSSA区域，由该地市NE80或T128充当该区域的ABR．按照规划：核心NE80向整个OSPF域下发缺省路由；各地市ABR向所在NSSA区域下发缺省路由；另外，各地市的T64G由于特殊的原因也需要通告一条默认路由（需要在ABR失效时候给其他设备通告默认路由，做为备份，图中没有表示）；

会计考友

</p>四、故障现象描述
8 O& p- h' B/ ~: ]! ^" \7 B运营商反映：A市，B市和D市的流量全部中断，但C地市的业务都没有问题；问题出现时，出现故障的地市T128的缺省路由都指向了本市的核心交换机T64G。通过在三台ABR上添加默认路由指到骨干区域，故障得以恢复；经检查，C地市之所以没有出现故障是因为T128上配置了静态的默认路由；
4 n& ]8 F6 F: I, S8 @8 @1 H2 `五、处理方法
2 Q: X3 H5 R% }4 |1 r为什么出现问题时，作为ABR的NE80和T128，其默认路由会指到T64G？让我们先看一下做为ABR的T128以及T64G的配置是怎样的：
T64G：

router ospf 1
router-id 222.49.10.254
+ k! k! J. {, h3 F/ F% w4 o: ?network 222.49.10.132 0.0.0.3 area 0.0.3.28
- y( b! q: S! hnetwork 222.49.10.148 0.0.0.3 area 0.0.3.28
network 222.49.10.152 0.0.0.3 area 0.0.3.28
$ ]$ c& g* ~/ F- G5 A( b- Gnetwork 222.49.10.156 0.0.0.3 area 0.0.3.28
network 222.49.10.254 0.0.0.0 area 0.0.3.28
area 0.0.3.28 authentication message-digest
! z' Q) v8 j7 n* k5 Oarea 0.0.3.28 nssa default-information-originate no-summary　
/ X) Z* N( [6 I0 b, \//因特殊需要发布的缺省路由
! h% H) o; @0 C/ Wredistribute connected
redistribute static注：OSPF协议并没有规定NSSA内部路由器不能发布缺省路由
T128：

2 I7 s) c8 Z9 q/ X) ~
; G1 S/ }5 A: ?8 o/ nT128-R1#sh run | be router ospf
Building configuration...
router ospf 1
router-id 222.49.10.250
network 222.49.10.128 0.0.0.3 area 0.0.0.0
+ h0 }5 v  W/ u7 znetwork 222.49.10.132 0.0.0.3 area 0.0.3.28
network 222.49.10.136 0.0.0.3 area 0.0.3.28
! \. ?4 Z3 @+ V" Anetwork 222.49.10.250 0.0.0.0 area 0.0.0.0
area 0.0.3.28 authentication message-digest
area 0.0.3.28 nssa default-information-originate no-summary
2 Y" F/ ?( [" Y8 ^3 [　//做为ABR向NSSA内部发布的缺省路由正常情况下，T128会学习骨干NE80发布的缺省路由，而不会学习T64G发布的缺省路由，那么故障发生时，最大的可能性就是NE80的缺省路由失效了：
在故障恢复后，我们查看T128的database，发现了两条默认路由的LSA：
1 h; @) n" @6 ^
Type-5 AS External Link States
$ e3 T' X; q7 Y. y* |LS age: 1493
8 i* ], X; C" U# X+ mOptions: (No TOS-capability, No DC)
. K2 b% c: v+ Z! t9 P) O8 [# PLS Type: AS External Link
Link State ID: 0.0.0.0 (External Network Number)
Advertising Router: 211.98.46.230 //经查证是核心NE80的loopback
LS Seq Number: 0x80007154
Checksum: 0x1abd
Length: 36
6 _! f( }% T" l  U7 r3 M5 T9 uNetwork Mask: /0
Metric Type: 2 (Larger than any link state path)
  a) R- M8 {. R, @$ Y! U2 ?TOS: 0
, h) K4 m9 l- z3 q5 oMetric: 1000
; T, u: i. F' x- J8 qForward Address: 0.0.0.0
7 q0 e% w# o2 e! C. r) z
7 w" z! z' N: o3 bType-7 AS External Link States (Area 0.0.3.28)
LS age: 968
Options: (No TOS-capability, No Type 7/5 translation, No DC)
  _# d# ~3 X6 W, q! V  rLS Type: AS External Link
7 o- x# y) k- x( V% |7 YLink State ID: 0.0.0.0 (External Network Number)
: _# a3 I# G, i0 V. B3 wAdvertising Router: 222.49.10.254//是NSSA内部的T64G
) M  M, e2 R8 ?- ]( ]  vLS Seq Number: 0x80002373
Checksum: 0x881a
8 ~" {' K5 y* C  P. YLength: 36
5 F0 L" R7 ]6 z( F7 V% V  INetwork Mask: /0
Metric Type: 2 (Larger than any link state path)
TOS: 0
Metric: 1
( w/ c6 O  Y3 g1 Z3 ZForward Address: 0.0.0.0

会计考友

从上面的结果来看，核心NE80所发布的默认路由LSA并没有丢失，那为什么在故障发生时，T128却将默认路由指向了T64G呢？经过仔细比对两条LSA，见上面红色标注部分：
核心NE80发布 T64G发布
LSA类型 LSA 5 LSA 7
Metric Type 类型2 类型2
' N. _  j  ]! s6 ~7 g0 v& f4 iMetric 1000 1
发现，两个LSA的类型不同，那个更优先呢？经过咨询研发，答案是没有差别，优先级一样！那Metric Type又一样，只有Metric不同，T64G发布的默认路由的Metric更低；这就解释了为什么T128的默认路由指向了T64G！
2 \/ O' S2 {7 |7 P但另外一个问题随之而来，之前业务一切正常时候，T128的默认为什么会指向骨干域呢？难道是核心NE80在故障发生时修改了配置？又或者核心NE80通告的默认路由Metric发生了变化？根据已知的信息和局方沟通，局方排查网络后，问题原来另有原因：
实际上，在之前网络一切正常的时候，T128上面应该能看到三条LSA，除了上述两条之外，还有一条：
( e/ b3 t/ @9 p1 `: [

Type-5 AS External Link States
Routing Bit Set on this LSA
LS age: 1295
Options: (No TOS-capability, No DC)
( _3 J% x7 ]5 cLS Type: AS External Link
Link State ID: 0.0.0.0 (External Network Number)
Advertising Router: 211.98.46.234//A地市NE80的loopback
. ~8 Y' f* D% F3 u9 KLS Seq Number: 0x80000053
- k5 _2 Y1 k6 ]; z! v  XChecksum: 0xd4f1
" Y* X  v# i& _- p0 J$ O; dLength: 36
Network Mask: /0
+ f" h: f& |$ ^, l3 l7 \2 a- b9 G9 x# wMetric Type: 1 (Comparable directly to link state metric)
TOS: 0
3 B+ K/ Y5 Y9 Q+ N6 D% t5 U) VMetric: 1000
Forward Address: 0.0.0.0

会计考友

原来，作为A地市ABR的NE80之前也一直在通告默认路由，我们不妨再将三条默认路由的LSA做一下比较：
. C" F2 ^& B+ }1 {. u& I' X核心NE80发布 T64G发布 A地市NE80发布
LSA类型 LSA 5 LSA 7 LSA 5
. A+ t5 Z# E: _9 c* a' QMetric Type 类型2 类型2 类型1
( t1 d7 @7 L2 C- E4 v7 SMetric 1000 1 1000
经过咨询研发，由于OSPF 外部路由引入类型1要比类型2优先，因此之前各地市的默认路由实际上是由A地市的NE80通告产生的，那为什么流量没有因为送到A地市NE80通告的默认路由而继续将数据发送到A地市的NE80呢？这是由现场的组网环境所决定的，由于其他地市ABR到达A地市NE80都要经过省核心NE80，流量一旦到了核心NE80就直接走静态默认路由出去了，而不会送到宜春NE80；
当天出现故障的时候，由于宜春NE80发生了异常，导致其宣告的默认路由失效，因此才会导致故障的出现；可见，原先表面上看起来是正常工作的网络实际上暗藏许多问题。
% K$ k- c: W7 y+ j; T! m0 ^目前，局方已经将T64G上通告的默认路由取消，NSSA区域内部的冗余性改由其他方式提供；
当然，也可以通过修改T64G上通告默认路由的Metric值来规避故障（改大），但还是建议取消其通告的默认路由
( O# D7 u. j( E1 A5 C六、故障处理总结
1、用户业务正常不代表网络运行正常；
2、合理的路由规划非常重要；
; D' N1 f+ F3 K+ D8 f9 q$ \3、故障出现时，第一是恢复用户业务，其次才是查找故障原因；
0 [3 }2 h6 x0 ]' i七、备注
! ^9 Z$ g. d3 L: O* [9 m  k! s8 e介绍下默认路由的比较规则：
; u- ]# V1 \# G8 e0 z& J3型 > ext1 5/7 >ext2 5/7
如果ext-type 相同
! q! G1 a6 r7 Ymetric 小的优先
如果还区分不开
) g/ E+ l) Y1 p' O6 Lnssa +p（7型） > ase（5型） >nssa no p（7型）
p是NSSA LSA上的是否翻译的选项
关于ext-type（就是metric type），1型是骨干网上最经常使用的，因为他还能计算出OSPF区域内部的cost值，为路由的灵活控制和优化提供了可能；
另外，当一个OSPF区域有两个ASBR的时候，他们通告的默认路由一定要保持ext-type一致。