《RRPP未知單播抑制值過低導致環(huán)震蕩》由會員分享，可在線閱讀，更多相關《RRPP未知單播抑制值過低導致環(huán)震蕩（6頁珍藏版）》請在裝配圖網上搜索。

1、S９３ RRPP環(huán)未知單播抑制值過低導致環(huán)震蕩處理案例 故障現(xiàn)象： ＸＸX國XＸ運營商承載網兩臺相鄰的CＸ600下掛的RRPP環(huán)中，有兩臺S93節(jié)點出現(xiàn)RRPＰ告警，繼而出現(xiàn)震蕩，導致業(yè)務中斷.跟客戶詢問得知并未對現(xiàn)網做操作。故障發(fā)生無規(guī)律,復現(xiàn)難度大. 原因分析： 拓撲圖: 分析判斷可能原因： 1、設備CPU占用率過高導致RRＰP環(huán)的Ｈelｌo報文超時被丟棄,進而導致RRPP環(huán)失效 2、鏈路原因導致流量無法正常傳達目的地 原因排查: RＲPＰ報文被丟棄 1） 在復現(xiàn)之前在S９300—2設備上配置RRPP的ｈellｏ報文出入方向的統(tǒng)計，復現(xiàn)問題后發(fā)現(xiàn)ＲＲＰP主節(jié)點S９

2、３00—1上ＲRＰＰ發(fā)送報文比接收要多，部分RＲPP報文被丟棄；在RRＰP傳輸節(jié)點S9300-２設備上出入方向的RRＰP hello報文不一致，從ＣX600—1到Ｓ9３０0-２設備的ｇi１/1/23端口RRPP hello入方向報文比S9300－2設備通過gｉ1/１/22端口轉發(fā)給S9300-1的要多,說明RRＰＰ　heｌlo報文在S9300—2設備上被丟棄。 日志信息: S9３０３-1設備上看RＲPP計數(shù)發(fā)現(xiàn)發(fā)送比接收要多一些RRPP的hｅｌlｏ報文. 〈MSC＿Grodno_S９3０3_１>ｄisｐlay rrpｐ ｓtatistics?。鋙maｉn 14 ＲRPP Ring　　　

3、 : 14 Rｉng　Leveｌ ： 0 Noｄe Modｅ 　 　　: Ｍａster Is Actiｖｅ : Yes Priｍary　poｒｔ :　GigabｉtＥｔhernet１/1／22 　Paｃkｅｔ 　　　 LＩNK 　　 COMMON COMＰＬETE　 EDGE 　 MＡＪOＲ 　 Ｐackeｔ 　　　 Diｒect HEAＬTＨ DOWN 　 ＦDＢ 　FDB 　 HELLO　 　 FAＵLＴ 　Tｏtaｌ 　 　 -——---——---—－-——－—-———－-－

4、－—--—-—--—-----—-－—————-—————－-——--—－-———---－—-—－-－——— 　Seｎd 429 　 0　 　 1　 　 ２ 　 　0　 　 　0 　　 432 　　 Rcv 　 0 　 0　　　　 1　　　 　　 0　 　 0 　 　 　 ０　　 　　　　 １ 　　 Ｓecondaｒｙ pｏrｔ： ＧiｇａbｉtEtherneｔ1／1/２3 Packｅｔ 　　 　　 ＬINK　 　 CＯMMＯN 　COMＰ

5、LETE　 ＥDGE 　 　MAJOＲ 　 　Packet 　 Diｒect HＥALTH 　　DOＷＮ 　 FDB　 FDB HELＬO 　 FAＵLT 　Total 　　　 　 —－——----－—－-----—－--—－——－—---——----—---—－-—－—-—-－——--—-－—－——-—--—－－－—--—－-—-－—- Sｅnd 　 ０ 　　　 0　 　 　　 １ 　 　　 　0　 　 　 0　　 　0 　 　 １ 　　 Ｒcv 　 ４23

6、 ０　　 １ 　 　 0　 　 0 　 　 　0 　 　 ４24 查看日志信息可以看到在環(huán)恢復后大概7分鐘后出現(xiàn)一次RRPP　failed信息。 Maｒ 27?。?12　01:5２:1１ ＭＳC＿Grodno_S93０3_1 ％％01RRPP／３/ＦAIＬ（l)：　Dｏmain　14　ring　1４ fａiled。 Mar 2７　2012 01：4５：2３　ＭSC_Grｏdno_S9303_1?。?01IFNET/4／IF_STATＥ（ｌ): Ｉnｔerface GigaｂｉtＥｔhｅrnｅt1/1/22 haｓ turn

7、ｅd　intｏ UP?。螅鬭ｔe. 根據dｅbug信息報文當時出問題前是正常發(fā)送，但是有3秒沒有收到RRＰP ｈeｌｌo報文導致出現(xiàn)RRPＰ超時情況。 ＊Mar 27 ０1：５2:０9 20１2　MSC_Ｇrodｎo＿S93０3＿1　RＲＰP/７/RRPＰＰKT: Domａin１４　Vlan　2028 rinｇ14 poｒt GｉgabｉtEtheｒnet1/1/2２ Ｓend　Packｅt。（Length: 6４, tyｐe: Ｈｅａlth—chｅcｋ Ｐaｃket.） RRPP PDU　Length：　6４ RRPP Version: １　 RRＰP PDU Ｔyp

8、ｅ： 5　 　RRPP Domain IＤ： １4 　RRPP VLAN ID: 20２8 RRPP Ring?。蒁： １４ Hｅllo Timeｒ：　1 　Fail　Timｅr: 3 RRPP Riｎｇ Level: ０ ＊Ｍar 2７　01：5２：10 ２012 MSＣ_Ｇroｄｎo_Ｓ９3０3_1 RRPP/７／RRPＰPKT： Ｄｏmａｉn14 Vlan　2028 riｎg1４ porｔ ＧigabitEtｈｅｒnet1／1/２2　Send Packet.(Length: 6４,　type：　Heａlth—cheｃｋ　Packet.） 　RRＰP

9、 ＰDＵ　Lｅngth：　64 RRPＰ Version: 1　 　RRPP?。蠨Ｕ Ｔype： 5　 RRＰＰ Dｏｍａｉn ID: 14 ＲRPＰ ＶLＡN ID: 202８ RRPP Rinｇ?。蒁: 14　 Ｈｅｌlo　Timer： 1 　Faiｌ Timer： 3　 RＲPＰ Rｉnｇ Level：　0 *Ｍａr ２7 ０1:52:１1 2012 ＭSC_Groｄno_S9303_１ RRＰＰ／７/RRＰPＰKT： 　//出問題前３秒只有發(fā)送沒有接收。 Ｄoｍain14 Vｌan ２028 rinｇ14 pｏrt GｉgaｂitEｔheｒｎｅ

10、ｔ１／1／２２　Send　Pacｋｅt.（Ｌeｎgtｈ： 64, type:　Ｈealtｈ—check Pａｃｋet．) 　 ＲＲＰP ＰDU Ｌｅｎgｔh: 64 RRPP Version: １ ＲＲPP PDＵ Typｅ： 5 RRPＰ Dｏmaiｎ ＩD: １4　 RRＰP VLＡN ID：?。?２８ RＲPP Rｉng IＤ：　14　 　Helｌo Tｉｍeｒ： 1 Fail Ｔimer： 3 RRPP Ring　Leｖel: 0 *Mａr 27　01：52：11 2012 MSC＿Groｄｎo＿S9303_1 ＲRPP／７/RRＰPP

11、KT: Domain1４ Vｌan 2028　ring14 port GigabiｔＥtｈernｅｔ1/１／22 Send Paｃket.(Leｎgｔh: 64，　tｙpe： Cｏmmon-FDＢ Packet。) 　RRPP PDＵ Ｌeｎｇtｈ： 64 RRPP Verｓｉon： 1 ＲRＰP PDU　Typｅ： 7　 RＲPP Dｏｍａin ID: 14 ＲRPP　VLAN IＤ： 2028　 ＲＲPP Ring IＤ： 14 Hello Ｔｉmeｒ: 1 Fａil　Timer：?。? ＲRPP Ring Level： 0 *Ｍar 2

12、7 01:52:11 20１2 MSC_Groｄno_S930３_1　RRPP／7/ＲＲPＰPKT: Ｄoｍaｉn14 Vlaｎ 202８　ring14　poｒt ＧigabｉtEthernｅt1／1/2３　Send Ｐacｋet．（Lengｔｈ: ６4， typｅ： Cｏmｍｏn-FＤB Ｐackｅｔ.） RRPP PDＵ Lｅngtｈ:　64 ＲRPＰ　Versiｏn:　1 ＲＲＰＰ ＰDＵ　Type: 7 RRPP Domaiｎ ID:　14 ＲＲPP VＬAN ＩD:　202８ RRPＰ　Riｎg ID: 14 Hello Timeｒ：?。?/p>

13、 　Faｉl Timeｒ：　3　 ＲＲPP Rｉng Leｖel:?。? #Maｒ 27 01：52：11 ２０12 MSC＿Grｏdｎo_S９303_1 RＲPP／4/RNＧDN：OIＤ 1。3。6.１.4.１.2０１１．5．25．113.4.２ Domain　14 rｉｎｇ 1４ ｉs failed。 #Ｍar 27?。?:５2:１１ 2012 ＭSC_Grodｎo_S9３03_１　RＲＰＰ/６/RNＧＵＰ:OID 1。3．6.１.４.1．2011.５。2５。１１3。４。1 Domaiｎ?。? riｎｇ 1４ is　restorｅｄ。 Maｒ　27　2012 01:52:1１

14、?。蚐Ｃ_Gｒoｄnｏ_S9303_1 %％01RRPP/3/FＡＩＬ(l）： Doｍaiｎ　14 ｒing 14　faｉleｄ。 ＊Mar ２７　01：５２：11 201２ ＭSC_Grｏｄnｏ_S９３0３_１ RＲPP/7/ＲRPＰPKT: 　 從S9303—２設備上RRＰP流量統(tǒng)計信息來看,先收集Ｓ9303—2的g1/1/23的入方向的RＲPP heｌlｏ報文，再立刻顯示S９３03-２的gi1/1／22的出方向,發(fā)現(xiàn)RRPP報文經過Ｓ9３03－２設備時有部分RRPP ｈello報文被丟棄。 　 Inｔerfａcｅ： GiｇabｉtEtｈernｅt１/1/2３ Traffｉc

15、 policy inｂoｕnd： teｓt Rule numbeｒ: 1 　Cｕrｒent staｔus: OK! Boarｄ : 1 Itｅm 　 　 　 　 　 　 　Pａｃkｅtｓ　 　 　 　 　Bytes -－－－－——－————－－--—--－-－－－－-－---————－-—-—--－－---—-—-———－--—---—－－—————— Matched 　 　 　 　 　 　 ４72 　 　 　 ?。?,3６8 　 ＋-—Passed

16、 　 　 　 ４７２ 　 　 　 　 　 44，368 +—－Ｄｒoppｅｄ 　 　 　 　 　 0　 　 　 　 　 　 　 ０ +-—Ｆｉlter 　 　 　 0　 　 　 　　 　 　 　 ０ 　 +-－URPF 　 　 　　 － 　　 　 　 　　　　　　 　 　　- +－—CAR 　　

17、 　　　0 　 　 　　　 　 0 Interfaｃe： GiｇａbiｔEtheｒnet1/1/22 Ｔraｆｆiｃ poliｃy ｏｕtbouｎd： teｓt Ruｌe nuｍbeｒ： 1 Cuｒrent ｓtaｔuｓ： OK! Board?。?1 Item　　 　　 　 Packｅts 　 　 　 　　 　Bytes —－—-—-———－——-－—－———－--—-———--—-－——-－-－--—－—－—－－--—-———－-—-—--—--————－ Mat

18、ｃhed 　 　 　 　 　 　　　　 　 468 　 　 　 ４3，992 　　+—-Ｐassed　　 　 　 　　　　 　 　 ４68 　 　 ?。?,99２ 　+—-Ｄroｐped　 　 　 　　 　　 　 　０ 　 　 　 　 　 　 0 +－－Fｉｌter 　　　　 　 　 　　 　?。啊? 　　 　 0 +——ＵＲPF 　 　

19、 　 　　 　　　 　　 　　　— 　 　 　 　　 　- 　　　+——CAR　 　 　 　 　 　　 0 　 　　 　 0 2） 在問題復現(xiàn)時,查看CX600－1設備出方向的未知單播計數(shù)，發(fā)現(xiàn)vsｉ ｎoｄeb_ｓｅｒvices_2０上存在大量的未知單播(出現(xiàn)過最高８0０多個每秒，根據復制后的情況,當時最多會有400０多每秒報文到達S9３03—2設備）,并且vsi ｎodｅｂ_seｒvicｅs_20綁定在8/1/1９.2420－－－８／1/19。24２4五個子接口上,此時報

20、文被復制5份,進入S9３0０-2后，由于S9３03-２設備上和CX60０－2對接的gi１／１/23端口上配置了未知單播抑制，抑制個數(shù)是2000,超過２00０后會隨機丟棄報文；ＲＲPP的dmac比較特殊，在轉發(fā)的過程中都是以未知單播轉發(fā),根據前面的統(tǒng)計信息來看RＲPP的hello報文是被未知單播抑制丟棄.把S9303—2的gi１/１/23端口上的未知單播抑制調小為1０0后，再次復現(xiàn)過程中出現(xiàn)多次RRPＰ的ｆaｉled情況，說明這個值調小后同時有大量未知單播會加大RRPP發(fā)生的概率以及頻率。 S93０３—2設備的入方向gi１／１/23端口上配置了未知單播抑制，CX６00—2設備過來大量未知單播超

21、過2000后會出現(xiàn)隨機丟棄未知單播報文，RＲPP的hello報文可能會被丟棄. ＃ ｉnｔerface ＧigａbiｔEｔheｒnet1／1/23 description　To MＳC_2_Ｇrodno_CX600-X8 ＧE8/１/19 port ｌiｎk—type　trｕｎｋ undｏ port ｔrunk allow－ｐasｓ vlａn １ 　poｒｔ ｔｒunk allｏw—ｐass vlａn 2028 tｏ 20２9?。玻玻?　to　2212　２21４ 2311 tｏ?。?12　2320 to 2324 2４1１ ｔｏ　2４1２?。?２0　ｔo 2424 4094

22、 　stｐ disable ｔrusｔ　upｓtream deｆａｕlt qｏs ｐｑ 5 to 7　drr ０ tｏ 4 qoｓ queuｅ 0 ｄrr weiｇhｔ 10 qoｓ ｑueue 1 drｒ?。鱡ｉght　10 qｏs ｑueue 2 drr　weｉgｈt 10 qoｓ ｑueｕe　３ drr weiｇｈt 15 qos qｕeue 4 ｄrr weight 15 　uｎicasｔ-suppreｓsiｏn packeｔs　20０0 　muｌtiｃasｔ—sｕpｐreｓsion pａckets?。?００ 　broadcast-sｕppressio

23、n ｐａckets 20００ ＃ 調整gi１／1／23端口上配置了未知單播抑制減小后,RRＰＰ出現(xiàn)問題后頻率變多。 Mａr 27 2０１2　03:32:05 ＭSＣ＿Groｄｎo_S9303_1 ％％01ＲRPP/3/FAＩL（l):　Dｏmaｉn 14 ring　14 failed． Ｍar　27　2012 ０３：32：00 MＳC_Ｇrodno＿S9303_１ %％0１ＲＲPP/３／FＡIL(l)： Domain 14 rinｇ 14　faileｄ。 Mar 27 2０１２ 0３：31：54 ＭSＣ_Gｒodｎo_S９3０3_1 ％％０１RＲPP／３／FAIL（l): Doｍai

24、n 14　ring 14 ｆａiｌｅd。 Mar 27 2０1２ 03:３１:49 MＳC_Gｒｏdｎｏ_S9303＿1?。ィ?１ＲRPP/3/FAIL(l)：　Domaiｎ 14 riｎｇ 14?。鎍iled。 Mar　27 ２01２ 0３：31:4５　MＳＣ＿Gｒodno_S930３_1 ％％01ＲRPP／3/FAＩＬ(l)： Domａin　14 ring １４ failed。 Mar 27 201２ 03:26：32 MSC＿Grｏdnｏ_S9303_１?。?0１RRPP/３/FAＩL(l）: Dｏｍａｉn 14　ring 14 ｆailｅｄ． Ｍar　2７ 20１２ 03:26

25、：2６ MSC_Grｏdnｏ_S９303_１ ％％01RRＰＰ/３／FAIＬ(l）： Ｄｏmａin 14 ｒiｎg 14 faｉled。 Maｒ ２7 ２01２　03：26：2２　MSC_Groｄnｏ_S9303_１ %％01ＲRPP／3/ＦＡIL（l）:　Domain 14?。颍椋頶?。? failed. Mａr 27 20１２ 0３：2６:1９ MSC_Grｏdno_S93０3_1 %%01ＲRＰP/３／FAIL（l): Dｏmaｉn １4 riｎg 14 faileｄ． 結論: 由于在傳輸節(jié)點的下行接口S93-2的G１／1／２3設置的未知單播過濾值偏低,導致一旦未知單播報文增多會

26、導致RＲPＰ的hellｏ報文會被隨機丟棄，一旦Heｌｌo報文被隨機丟棄超過三次即發(fā)生RＲPP環(huán)震蕩。brｏａdcaｓt－suｐpression pacｋets 2000 ＃ iｎｔｅrfａce GigabitEthｅrnet1/１/２３ deｓcription　To MSC＿Grodno_S9303_2 GＥ1/1/２2 　poｒｔ linｋ—tｙpe ｔｒｕnk 　undo poｒt trunｋ allow-pass vｌan 1 ｐｏｒｔ　tｒuｎk　allow-pass ｖｌan　2028 to　2029 2211　to 2212　22１４ 23１1 to 2312 23

27、20 tｏ 2３２4 2411 tｏ 2412 2420?。簦?２424 4０9４ ｓtp disａble 　efm ｅｎable efｍ　error－fｒaｍe noｔificａt(yī)ｉoｎ　enａble efm ｅrror-ｃｏdｅ　notiｆiｃａt(yī)ion enａble efm triｇger　iｆ-ｄowｎ 　efｍ holdｕp－ｔｉmeｒ　１0 ｅfm threshｏld—evenｔ trigger error-dowｎ truｓt uｐｓtreａm ｄefault qos　pｑ ５ ｔo 7　drr　0 to　4 　qos qｕeue 0 dｒｒ

28、ｗeight 10 　qｏs　qｕeuｅ 1 dｒr weighｔ 1０ 　qos quｅｕe 2?。鋜r weigｈt　10 qoｓ qｕeue　3 ｄrr ｗeｉｇｈt 1５ qoｓ　quｅｕe 4　drr weiｇｈt 15 ?。鮪icast-sｕpｐression paｃｋets 400０ mｕlｔｉcａｓｔ—sｕpｐression ｐackets ２00０ broadｃasｔ-sｕppression packets 20０0 # 解決措施： 去使能未知單播抑制功能 經驗總結: 本次的故障源自現(xiàn)網已有配置.隨著客戶網絡業(yè)務規(guī)模的增加，原有配置的設置門限值已無法適應正常業(yè)務運行需要。對于現(xiàn)網業(yè)務來講，應適當提高整網巡查力度和深度,及時針對業(yè)務增長點較為迅速的設置做出預警，避免發(fā)生故障，影響業(yè)務。 不足之處，敬請諒解 6 / 6