成人免费xxxxx在线视频软件_久久精品久久久_亚洲国产精品久久久_天天色天天色_亚洲人成一区_欧美一级欧美三级在线观看

CCNP:OSPF NSSA區域默認路由發布引發的問題

企業動態
CCNP中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 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一致。

【編輯推薦】

  1. CCNP工程課程:售前綜合測試案例
  2. CCNP-MPLS(多協議標簽交換)技術研究及應用
  3. CCNP:主機備份路由協議(HSRP)的配置
責任編輯:夏雨 來源: www.56cto.com
相關推薦

2014-09-05 09:26:27

路由報錯

2013-05-15 10:56:19

靜態路由器路由器設備配置

2011-04-08 17:24:34

OSPF路由

2010-08-09 14:36:12

華為stub nssa

2013-08-08 09:38:34

OSPF協議OSPF

2015-04-21 13:28:47

OSPF

2009-07-14 10:11:59

華為OSPF區域路由

2010-08-17 10:48:36

2009-12-23 13:49:50

路由器接口配置

2009-11-24 14:55:00

OSPF

2009-10-20 13:58:00

CCIE學習筆記

2009-11-26 15:51:00

CCNP路由

2015-04-16 09:20:02

動態路由協議RIP

2011-03-04 15:19:19

Vsftpd路徑

2009-05-13 10:50:59

CCNPHSRP路由

2009-11-24 15:00:00

路由選擇

2011-04-08 17:34:06

LSAOSPF

2010-04-14 16:08:06

2013-06-20 09:59:12

Javascriptvar

2010-07-20 10:55:39

CCNPOSPF
點贊
收藏

51CTO技術棧公眾號

主站蜘蛛池模板: 久久久久香蕉视频 | 成人1区2区 | 国产精品久久久久久久久久久久冷 | 日韩视频中文字幕 | 一区二区三区中文字幕 | 免费观看一级特黄欧美大片 | 麻豆久久| 91在线观看免费视频 | 日韩不卡一区二区 | 亚洲传媒在线 | 亚洲成人一区二区三区 | 婷婷成人在线 | 毛片的网址 | 在线免费观看a级片 | 国产伦精品一区二区三区四区视频 | 免费在线观看一级毛片 | av黄色国产| 亚洲欧洲日韩精品 中文字幕 | 欧美一级欧美三级在线观看 | 国产九九精品视频 | 精品一区二区三区电影 | av网址在线 | 欧美精品乱码99久久影院 | 日日摸夜夜添夜夜添特色大片 | 狠狠爱免费视频 | 精品国产视频在线观看 | 国产精品一区久久久 | 精品亚洲91 | 羞羞的视频免费在线观看 | 国产日韩欧美一区二区 | 日日日日日日bbbbb视频 | 成人午夜高清 | 亚洲精品乱码久久久久久蜜桃91 | 久久精品一区 | 99精品国产一区二区三区 | 亚洲精品一区二区 | 激情欧美日韩一区二区 | 91精品久久久久久久久中文字幕 | 日本五月婷婷 | 久久久亚洲一区 | 久久88 |