ospf配置默认路由指向 ospf 下发默认路由

转载

charlesc 2024-07-30 15:24:03

文章标签 ospf配置默认路由指向网络数据库缺省路由 OSPF 文章分类 云原生云计算

一、关键术语
OSPF ， NSSA ， METRIC 类型

二、设备类型和版本
设备类型版本备注
ZXR10 T128 与版本无关
ZXR10 T<?xml:namespace prefix = st1 ns = "urn:schemas-microsoft-com:office:smarttags" />64G 与版本无关

三、网络拓扑

ospf配置默认路由指向 ospf 下发默认路由_数据库

组网介绍：
某省的 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 1
  router-id 222.49.10.254
  network 222.49.10.132 0.0.0.3 area 0.0.3.28
  network 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
  network 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
  area 0.0.3.28 nssa default-information-originate no-summary 
   　 
   
// 
   因特殊需要发布的缺省路由 
   
  redistribute connected
  redistribute static
 
   注： 
   OSPF 
   协议并没有规定 
   NSSA 
   内部路由器不能发布缺省路由 
   
 
T128 
   ： 
   
T128-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
  network 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
  network 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
 
   　　　　　　　　　　　　　　　　　　　 
   // 
   做为 
   ABR 
   向 
   NSSA 
   内部发布的缺省路由 
   
 
   正常情况下， 
   T128 
   会学习骨干 
   NE80 
   发布的缺省路由，而不会学习 
   T64G 
   发布的缺省路由，那么故障发生时，最大的可能性就是 
   NE80 
   的缺省路由失效了： 
   
 
   在故障恢复后，我们查看 
   T128 
   的 
   database 
   ，发现了两条默认路由的 
   LSA 
   ： 
   
  Type-5 AS External Link States
 
  LS age: 1493
  Options: (No TOS-capability, No DC)
  LS 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
  Network Mask: /0
  Metric Type: 2 (Larger than any link state path)
  TOS: 0
  Metric: 1000
  Forward Address: 0.0.0.0
   
 
  Type-7 AS External Link States (Area 0.0.3.28)
 
  LS age: 968
  Options: (No TOS-capability, No Type 7/5 translation, No DC)
  LS Type: AS External Link
  Link State ID: 0.0.0.0 (External Network Number)
  Advertising Router: 222.49.10.254 
   　　 
   // 
   是 
   NSSA 
   内部的 
   T64G
  LS Seq Number: 0x80002373
  Checksum: 0x881a
  Length: 36
  Network Mask: /0
  Metric Type: 2 (Larger than any link state path)
  TOS: 0
  Metric: 1
  Forward 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 LSA
  LS age: 1295
  Options: (No TOS-capability, No DC)
  LS Type: AS External Link
  Link State ID: 0.0.0.0 (External Network Number)
  Advertising Router: 211.98.46.234 
   　　 
   //A 
   地市 
   NE80 
   的 
   loopback
  LS Seq Number: 0x80000053
  Checksum: 0xd4f1
  Length: 36
  Network Mask: /0
  Metric Type: 1 (Comparable directly to link state metric)
  TOS: 0
  Metric: 1000
  Forward 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 一致；