環(huán)路故障專題案例

DOCPROPERTY"Product&ProjectName"環(huán)路故障專題初稿DOCPROPERTYDocumentName環(huán)路故障專題初稿STYLEREF"1"\n1STYLEREF"1"二層環(huán)路故障定位-文檔版本DOCPROPERTYDocumentVersion01(DOCPROPERTYReleaseDate2015-12-16)DOCPROPERTYProprietaryDeclaration華為專有和**信息所有?華為技術(shù)**PAGE82.z.DOCPROPERTYPartNumber【交換機在江湖】環(huán)路故障專題〔3〕扁鵲問道下篇臨床案例環(huán)路故障紛繁錯雜,難尋其理。愿廣為搜羅現(xiàn)網(wǎng)案例，合覽匯編，以求至簡至約，開卷了如指掌。對接設(shè)備故障其他廠商設(shè)備上出現(xiàn)華為MAC地址漂移故障案例涉及產(chǎn)品和版本S交換機V200R002及先前版本組網(wǎng)情況如REF_d0e2000\r\h圖1-1所示，防火墻設(shè)備上連接了三臺交換機?，F(xiàn)象描述防火墻設(shè)備上能夠看到00e0-fc09-bcf9MAC地址的漂移，對防火墻的業(yè)務(wù)轉(zhuǎn)發(fā)有影響。原因分析華為自研交換機上只有NDP會用00e0-fc09-bcf9作為協(xié)議報文的源MAC，而NDP是默認使能的，所以在這個場景中會導(dǎo)致防火墻設(shè)備報漂移，進而影響防火墻的轉(zhuǎn)發(fā)；這個MAC地址發(fā)生漂移一般情況下對業(yè)務(wù)沒有影響〔如果設(shè)備上對MAC漂移配置了動作則除外〕。NDP協(xié)議報文是BPDU報文，而BPDU報文是不應(yīng)該學(xué)習MAC地址的，交換機最新版本已經(jīng)不會學(xué)習BPDU報文了，防火墻設(shè)備也不應(yīng)該學(xué)習該MAC地址。處理步驟執(zhí)行命令ndpdisable，去使能交換機全局NDP功能?？偨Y(jié)與建議無。ATAE軟件問題導(dǎo)致與交換機MSTP對接失敗的故障案例涉及產(chǎn)品和版本S交換機所有產(chǎn)品和版本組網(wǎng)情況如REF_zh-_topic_0010234486_fig2938826510445\r\h圖1-2所示，新接入的ATAE機框與Switch-1和Switch-2交換機組成口字型環(huán)路?，F(xiàn)象描述在啟用STP后發(fā)現(xiàn)環(huán)路無法正常收斂：Switch-1、ATAE-SW-8均為根橋，Switch互連端口、ATAE互連端口可正常收斂，而Switch-1、Switch-2與連接的其他ATAE機框STP無法正常收斂。原因分析Switch-1配置為根橋，設(shè)備的系統(tǒng)MAC為：4c1f-cc82-d659。新接入的ATAE機框軟件版本為V200R013SPC005，該版本存在一個軟件問題：對于收到的根橋MAC以59結(jié)尾的STP報文不能正常處理。處理步驟檢查各端口的STP收斂情況，發(fā)現(xiàn)存在兩個根橋Switch-1手動配置為STP根橋，ATAE-SW-8也選擇為根橋：檢查ATAE-SW-8GigabitEthernet0/18端口的STP信息和收發(fā)報文情況ATAE-SW-8上沒有部署任何業(yè)務(wù)，GigabitEthernet0/18端口入方向組播報文計數(shù)有增加，但displaystp信息中端口接收的MSTP報文計數(shù)一直為0：對ATAE-SW-8GigabitEthernet0/18配置端口鏡像，確認已經(jīng)收到來自Switch-1的STP報文經(jīng)ATAE研發(fā)確認，出問題的ATAE交換板使用的是V200R013SPC005版本，該版本存在軟件問題：收到根橋MAC以59結(jié)尾的STP報文不能正常處理。V200R013SPC006及以上版本已經(jīng)解決該問題。將根橋切換到Switch-2后，MSTP收斂正常。升級ATAE交換板軟件版本到最新的V200R013SPC007?？偨Y(jié)與建議多設(shè)備形態(tài)的對接問題盡量控制在網(wǎng)絡(luò)部署階段。對于與其他設(shè)備對接的STP問題，首先排查配置是否存在問題、報文收發(fā)是否正常。S交換機和C*600路由器端口UP時間不一致導(dǎo)致RRPP臨時環(huán)路故障案例涉及產(chǎn)品和版本S交換機所有產(chǎn)品和版本組網(wǎng)情況如REF_fig256830154727\r\h圖1-3所示，S5700設(shè)備上配置RRPP協(xié)議，S5700_1和S5700_2分別作為RRPPdomain1和domain2的主結(jié)點，其他中間S5700做為RRPP傳輸結(jié)點，C*600路由器未配置RRPP協(xié)議，它們之間通過不同的VPLSVSI透傳RRPP協(xié)議報文和數(shù)據(jù)業(yè)務(wù)?，F(xiàn)象描述當C*600_1的1號板故障重啟后，發(fā)現(xiàn)C*600_1設(shè)備GE1/1/1端口比S5700_1的GE0/0/1端口UP的時間滯后8s或者最長能到達1分鐘，單板恢復(fù)后會形成幾秒鐘的臨時環(huán)路，可能導(dǎo)致業(yè)務(wù)異常。原因分析C*路由器單板復(fù)位重啟后，不管兩邊端口協(xié)商模式是強制或自協(xié)商，底層端口物理層狀態(tài)都會先UP。單板在配置恢復(fù)過程中，會檢查配置恢復(fù)有沒有完畢，如果沒有完畢的話，就不取物理狀態(tài)向軟件層報UP事件，路由端口UP時間滯后可到達1分多鐘。C*路由器端口比交換機端口UP時間有很明顯的滯后。由于交換機端口先UP，RRPP協(xié)議會在端口UP以后6s放開臨時阻塞，而路由器還沒有向軟件層報UP。等到路由器軟件層上報UP時，有的數(shù)據(jù)VSI已經(jīng)先透傳數(shù)據(jù)報文。路由器的RRPPVSI可能起來得比擬晚，或者起來可能短時間內(nèi)也不能正常透傳。由于C*單板起來比擬繁忙，而RRPP協(xié)議透傳VSI還沒有通，這時候就會形成臨時環(huán)路，根據(jù)C*單板業(yè)務(wù)配置多少及其繁忙程度，可能有時臨時環(huán)路會到達10s左右。如果中間交換機受到嚴重沖擊，環(huán)路恢復(fù)可能需要更長的時間。處理步驟C*路由器優(yōu)化軟件版本，加快UP事件的上報?？偨Y(jié)與建議無。設(shè)備硬件連接問題S9300交換機單板松動導(dǎo)致RRPP未生效故障案例涉及產(chǎn)品和版本框式設(shè)備組網(wǎng)情況如REF_fig43002241203354\r\h圖1-4所示，四臺S9300組成RRPP環(huán)形組網(wǎng)。工程師反應(yīng)客戶組成RRPP環(huán)網(wǎng)后，主節(jié)點上的從端口沒有被阻塞?，F(xiàn)象描述一線工程師反應(yīng)客戶組成RRPP環(huán)網(wǎng)后主節(jié)點上的從端口沒有被阻塞。原因分析設(shè)備上主控板上HG口沒有轉(zhuǎn)發(fā)RRPP報文，原因為單板連接松動。處理步驟組成RRPP環(huán)網(wǎng)后主節(jié)點上的從端口未被阻塞，初步疑心是RRPP協(xié)議功能下發(fā)存在問題。執(zhí)行命令displaydiagnostic-information，收集設(shè)備信息時，發(fā)現(xiàn)HG口未參加相應(yīng)的控制VLAN。推測可能是當時通道不穩(wěn)定丟包導(dǎo)致局部設(shè)置沒有下發(fā)成功。對于通道不穩(wěn)定的情況，進展單板插拔處理，發(fā)現(xiàn)問題不再發(fā)生，確認為單板連接問題。重新插拔后，報文正常轉(zhuǎn)發(fā)，故障解除。總結(jié)與建議協(xié)議下發(fā)失敗，流量不通等問題，可以從光纖、光模塊故障、單板連接不穩(wěn)定等方面來進展排查驗證，在環(huán)境允許的情況下可以進展光模塊替換、單板重新插拔等硬件故障處理方法。設(shè)備連線錯誤導(dǎo)致環(huán)路風暴的故障案例涉及產(chǎn)品和版本S交換機所有產(chǎn)品和版本問題現(xiàn)象描述及組網(wǎng)如REF_d0e2332\r\h圖1-5所示，*運營商工程網(wǎng)絡(luò)部署階段，未合理規(guī)劃，連線非常復(fù)雜，在連線過程中誤連接導(dǎo)致網(wǎng)絡(luò)業(yè)務(wù)受影響。問題根因說明現(xiàn)網(wǎng)中S交換機之間端口連接方式絕大多數(shù)使用Access類型，VLAN沒有很好規(guī)劃和隔離，連線非常復(fù)雜，非常容易誤操作連線，導(dǎo)致環(huán)路后沖擊上層核心設(shè)備。問題判斷方法忽略判斷方法，主要關(guān)注解決或躲避方案。解決方案合理規(guī)劃組網(wǎng)，VLAN合理劃分，進展有效隔離，減少不必要的連線，增加風暴抑制功能。復(fù)雜組網(wǎng)要經(jīng)過正規(guī)流程評審。網(wǎng)絡(luò)開局調(diào)試階段，必須shutdown和現(xiàn)網(wǎng)所有連接端口。恢復(fù)新建和現(xiàn)網(wǎng)網(wǎng)絡(luò)連接端口時，至少觀察20分鐘看端口上是否有異常的播送或組播流量，發(fā)現(xiàn)異常要立即shutdown上行端口。假設(shè)交換機端口燈有高速頻繁閃爍或常亮的現(xiàn)象，可能端口上有大量流量轉(zhuǎn)發(fā)，檢查是否有環(huán)路。經(jīng)歷總結(jié)無。組網(wǎng)及配置變更效勞器組網(wǎng)不合理引發(fā)交換機MAC地址漂移導(dǎo)致業(yè)務(wù)中斷故障案例涉及產(chǎn)品和版本S交換機所有產(chǎn)品和版本組網(wǎng)情況如REF_zh-_topic_0010234559_fig4539629104947\r\h圖1-6所示，兩臺效勞器的兩塊網(wǎng)卡捆綁在一起，按照負載分擔方式進展報文轉(zhuǎn)發(fā)。兩塊網(wǎng)卡對外表達同一個IP、同一個MAC?，F(xiàn)象描述Switch上持續(xù)出現(xiàn)MAC漂移告警。Switch下掛效勞器的ARP同時學(xué)習到交換機不同端口上，造成外網(wǎng)用戶訪問效勞器業(yè)務(wù)時斷時續(xù)，業(yè)務(wù)閃斷。原因分析兩臺Switch連接效勞器的端口一直存在物理UP/DOWN的異常情況，并且效勞器的MAC地址一直存在漂移現(xiàn)象，此時兩臺Switch的互連端口以及下行連接效勞器的端口上都學(xué)習到效勞器的MAC地址。當用戶通過Switch-1訪問效勞器時，Switch-1會根據(jù)MAC地址表項找尋出接口，由于MAC漂移導(dǎo)致出接口有兩個〔下行連接效勞器的接口GE4/0/9y以及交換機互連端口Eth-Trunk1〕。當流量選擇通過交換機之前的互連端口往外轉(zhuǎn)發(fā)時，將被轉(zhuǎn)發(fā)到Switch-2設(shè)備。由于Switch-2學(xué)習到效勞器的MAC也在中間互連端口，根據(jù)二層流量防止環(huán)路機制，此時會丟棄該報文，導(dǎo)致業(yè)務(wù)中斷。處理步驟效勞器采用負載分擔捆綁，而對端是兩臺交換機，組網(wǎng)不對稱。建議將效勞器運行模式從負載分擔修改為主備模式。同時也可以解決MAC漂移的問題。如果有特殊需求必須使用負載分擔方式以及跨設(shè)備組網(wǎng)，建議采用交換機集群，集群上采用鏈路負載分擔方式?？偨Y(jié)與建議組網(wǎng)規(guī)劃前需要考慮環(huán)路風險，并給出躲避措施。設(shè)備誤接入網(wǎng)絡(luò)觸發(fā)根保護導(dǎo)致業(yè)務(wù)中斷的故障案例涉及產(chǎn)品和版本S交換機所有產(chǎn)品和版本組網(wǎng)情況如REF_fig52358921141330\r\h圖1-7所示，兩臺S系列交換機與ATAE交換板組成STP環(huán)。ATAE交換板的兩個slot可以看成兩臺交換機，內(nèi)部通過GE0/15連接。Swtich-1配置為根橋，Switch-2配置為副根橋，Switch-1和Switch-2之間創(chuàng)立Eth-Trunk0。正常時阻塞口在ATAE-slot8GE0/19端口。兩臺S交換機部署VRRP功能，并作為ATAE的網(wǎng)關(guān)?，F(xiàn)象描述網(wǎng)絡(luò)故障時ATAE交換板經(jīng)交換機的業(yè)務(wù)中斷?，F(xiàn)網(wǎng)將Swtich-1下電后暫時業(yè)務(wù)恢復(fù)。原因分析Switch-1連接Switch-2、ATAE交換板的端口均配置根保護，一臺優(yōu)先級更高的O&M交換機錯誤連入該網(wǎng)絡(luò)后，觸發(fā)根保護生效，所有配置根保護的端口都被阻塞，業(yè)務(wù)中斷。處理步驟故障發(fā)生時，在兩臺交換機上查看VRRP狀態(tài)，發(fā)現(xiàn)均為Master，推斷VRRP心跳報文轉(zhuǎn)發(fā)出現(xiàn)問題。VRRP心跳報文正常是通過兩臺交換機間的Eth-Trunk轉(zhuǎn)發(fā)。如果故障時Eth-Trunk協(xié)商失敗、STP重新收斂，心跳報文應(yīng)該可以通過ATAE交換板進展轉(zhuǎn)發(fā)。將Switch-1重新上電，但不連接到網(wǎng)路中。檢查Switch-1的配置文件，發(fā)現(xiàn)Switch-1上所有UP端口都配置了STP根保護：stproot-protection。對于設(shè)置了根保護的端口，一旦收到了優(yōu)先級更高的STP報文，這些端口的狀態(tài)將被設(shè)置為阻塞狀態(tài)，不再轉(zhuǎn)發(fā)報文。由于Switch-1已經(jīng)重啟過，無法確認故障時是否確實收到了更高優(yōu)先級的報文，只能根據(jù)ATAE交換板的STP歷史計算信息進展分析。從ATAE交換板上采集的STP歷史計算信息發(fā)現(xiàn)，slot8上的端口GE0/19收到了來自000f-e2f6-1d18設(shè)備且優(yōu)先級為0的STP報文，并觸發(fā)了STP重新計算：STP協(xié)議根據(jù)橋ID即〔橋優(yōu)先級，系統(tǒng)MAC〕進展根橋選擇，當橋優(yōu)先級一樣時，系統(tǒng)MAC小的設(shè)備橋ID更小，優(yōu)先級更高。故障發(fā)生時，ATAEslot8收到了比原根橋Swtich-1〔0.000f-e2f6-26bf〕優(yōu)先級更高的STP報文(0.000f-e2f6-1d18)，導(dǎo)致Switch-1上配置STP根保護功能的端口被阻塞。兩臺交換機間的VRRP心跳報文無法轉(zhuǎn)發(fā)，出現(xiàn)VRRP雙主、業(yè)務(wù)中斷的現(xiàn)象。經(jīng)排查，000f-e2f6-1d18為GE0/17下掛網(wǎng)絡(luò)的一臺O&M交換機的系統(tǒng)MAC，故障期間被錯誤連入網(wǎng)絡(luò)中。此時，需要將ATAE上不在STP環(huán)中的端口去使能STP?？偨Y(jié)與建議在使用根保護固定根橋位置時，需要考慮到網(wǎng)絡(luò)中如果確實出現(xiàn)高優(yōu)先級報文搶占根橋，在端口配置根保護時對業(yè)務(wù)轉(zhuǎn)發(fā)的可能影響，提前防止這種場景出現(xiàn)。網(wǎng)絡(luò)改造引發(fā)環(huán)路導(dǎo)致業(yè)務(wù)閃斷故障案例涉及產(chǎn)品和版本S9300V100R003C00SPC200組網(wǎng)情況如REF_zh-_topic_0007367885_fig6351992511436\r\h圖1-8所示，在網(wǎng)絡(luò)遷移改造后，將原網(wǎng)中的核心層設(shè)備部署為接入層設(shè)備AS，即從三層變?yōu)槎?。DS_01和DS_02部署VRRP功能。現(xiàn)象描述三層設(shè)備DS向二層設(shè)備AS的管理IP地址發(fā)起Ping測試，發(fā)現(xiàn)時通時不通，并且發(fā)現(xiàn)DS上的VRRP主備狀態(tài)在頻繁的切換。在DS_02上出現(xiàn)如下告警信息：VRRP狀態(tài)在不停的切換，查看VRRP狀態(tài)，都為Backup狀態(tài)正常：原因分析網(wǎng)絡(luò)中存在環(huán)路。處理步驟執(zhí)行命令displaycpu-defendvrrpstatisticsall，查看VRRP協(xié)議報文統(tǒng)計信息，發(fā)現(xiàn)DS_02上有大量丟包。執(zhí)行命令displayinterfacebrief，查看設(shè)備端口帶寬利用率信息。從端口計數(shù)查看連接AS的端口出方向都到達了80%以上，應(yīng)該存在環(huán)路，其中GigabitEthernet4/0/18和GigabitEthernet4/0/19端口的入方向流量統(tǒng)計也到達80%以上，初步判斷是這兩個端口下掛的AS設(shè)備引起環(huán)路導(dǎo)致，手工shutdown這兩個端口，再查看cpu-defend統(tǒng)計和Ping其他AS設(shè)備管理地址，VRRP協(xié)議報文Drop統(tǒng)計數(shù)不再增加，其他AS設(shè)備管理地址可以Ping通。GigabitEthernet4/0/18和GigabitEthernet4/0/19兩個端口分別連接的是AS_03和AS_05，這兩臺交換機都是其他廠商設(shè)備，排查后發(fā)現(xiàn)，由于這兩臺設(shè)備原本都是三層設(shè)備，沒有開啟STP協(xié)議，部署成二層設(shè)備時，未添加開啟STP的命令，導(dǎo)致環(huán)路。開啟STP后，從DS上翻開GigabitEthernet4/0/18和GigabitEthernet4/0/19端口，查看STP狀態(tài)和接口流量，業(yè)務(wù)恢復(fù)正常?？偨Y(jié)與建議在網(wǎng)絡(luò)流量不穩(wěn)定時，可以通過接口流量狀態(tài)查看是否有環(huán)路，并根據(jù)收發(fā)狀態(tài)猜想環(huán)路的源頭，盡快手工Shutdown關(guān)閉端口降臨時解決問題，分析出根因后，再實施解決方案。刪除故障端口的SEP配置導(dǎo)致設(shè)備脫管故障案例涉及產(chǎn)品和版本S交換機所有產(chǎn)品和版本組網(wǎng)情況如圖1-9所示，SwitchA、SwitchB、SwitchC、SwitchG、SwitchF、SwitchE構(gòu)成Segment1，SwitchC、SwitchD和SwitchE構(gòu)成Segment2。現(xiàn)象描述SwitchC和SwitchD之間鏈路發(fā)生故障，將SwitchD故障端口的SEP配置刪除，造成SwitchD脫管。原因分析SwitchC和SwitchD之間的鏈路發(fā)生故障后，SEPSegment2的之前的阻塞口將放開，兩個故障口為Discarding狀態(tài)，當刪除SwitchD故障端口的SEP配置后，SEPSegment2將在SwitchD和SwitchE的兩個端口上選擇一個新的阻塞口，導(dǎo)致SwitchD的上下方向的鏈路都不通，設(shè)備脫管。處理步驟通過命令displayseptopologysegmentsegment-id，查看當前的拓撲信息，確認故障端口。開放環(huán)場景下，在需要刪除SEP配置并重新部署SEP時，建議從開放環(huán)的一端開場刪除配置，剩余最后一個SEP接口時，Shutdown該端口，再刪除該端口的SEP配置?？偨Y(jié)與建議在刪除SEP配置時，需要考慮SEP段上業(yè)務(wù)VLAN的部署情況，防止在操作的過程中，產(chǎn)生多點阻塞造成設(shè)備脫管或業(yè)務(wù)不通。配置錯誤端口未退出VLAN1導(dǎo)致端口流量異常業(yè)務(wù)中斷故障案例涉及產(chǎn)品和版本S交換機所有產(chǎn)品和版本組網(wǎng)情況如REF_zh-_topic_0010234521_fig552308162520\r\h圖1-10所示，Switch雙上行接入路由器，下行接入接入層設(shè)備?，F(xiàn)象描述Switch雙上行業(yè)務(wù)全部中斷，重啟設(shè)備可以短暫恢復(fù)，但是問題會再次出現(xiàn)。原因分析接入層網(wǎng)絡(luò)環(huán)路，發(fā)生網(wǎng)絡(luò)風暴，導(dǎo)致Switch上行端口帶寬被充滿，OSPFpeerdown。Switch設(shè)備重啟后網(wǎng)絡(luò)風暴暫時破除，業(yè)務(wù)正常，再次風暴后故障重現(xiàn)。處理步驟查看日志文件，可以發(fā)現(xiàn)ospfpeerdown以及down的原因：對端設(shè)備沒有及時收到ospfhello報文。查看診斷日志文件，發(fā)現(xiàn)端口流量異常的告警。分析發(fā)現(xiàn)，上行口GE1/0/0、GE1/0/1出方向流量告警，同時發(fā)現(xiàn)GE1/0/3和GE1/0/4入方向流量告警。分析這些流量異常告警的端口的配置，這些端口只有一個共同的VLAN1，由此可以判斷，GE1/0/3和GE1/0/4兩個端口VLAN1內(nèi)進來的流量同時播送到其他幾個端口，導(dǎo)致上行端口出方向流量異常，ospfhello報文被丟棄。由此可見，VLAN1內(nèi)環(huán)路，將GE1/0/3和GE1/0/4退出VLAN1，故障解除。經(jīng)歷總結(jié)VLAN1環(huán)路是比擬常見的環(huán)路之一，發(fā)現(xiàn)端口流量異常，需要比照分析流量異常的端口的配置，是否存在共同的VLAN1，是否端口下播送報文計數(shù)較大。交換機端口未配置bpduenable導(dǎo)致業(yè)務(wù)中斷的故障案例涉及產(chǎn)品和版本S2700&S3700&S5700V100R005組網(wǎng)情況如REF_d0e2896\r\h圖1-11所示，Switch使用V100R005C01SPC100版本，全局使能STP并下掛多臺Cisco交換機，組成多個STP環(huán)?，F(xiàn)象描述業(yè)務(wù)故障時，登陸Switch，發(fā)現(xiàn)端口下有大量播送報文，網(wǎng)絡(luò)中出現(xiàn)環(huán)路。問題根因說明從配置分析，兩臺Switch全局均使能STP，但所有互連端口下均未配置bpduenable：對于兩臺Switch設(shè)備，使能STP、LACP等二層協(xié)議的端口，需要配置bpduenable才能將端口接收到的協(xié)議報文上送到CPU處理，否則協(xié)議報文在端口丟棄，無法實現(xiàn)協(xié)議協(xié)商。處理步驟網(wǎng)絡(luò)中出現(xiàn)環(huán)路，首先排查STP收斂是否正常。當STP環(huán)中沒有阻塞口時，可通過displaystpinterface查看具體端口在生成樹中的角色，確認端口收、發(fā)STP報文是否正常。例如：如果使能STP的互連端口均為DesignatedPort角色，說明STP協(xié)商失敗，檢查端口下是否配置bpduenable。如果未配置，將需要參與STP計算的端口配置bpduenable。經(jīng)歷總結(jié)框式交換機*7系列參與STP計算的端口不需要配置bpduenable〔默認bpdudisable/bpdubridgedisable〕。盒式交換機V100R006版本之前，參與STP計算的端口需要配置bpduenable，否則對于收到的STP報文不處理〔不會影響STP報文發(fā)送〕。盒式交換機V100R006及之后版本，端口默認bpduenable?？蚴浇粨Q機參與STP計算的端口不需要配置bpduenable〔默認bpdudisable/bpdubridgedisable〕。未配置STP邊緣端口導(dǎo)致局部終端從網(wǎng)卡啟動時獲取不到IP地址故障案例涉及產(chǎn)品和版本S交換機所有產(chǎn)品和版本組網(wǎng)情況如REF_fig3486660416391\r\h圖1-12所示，PC終端用戶通過交換機Switch接入網(wǎng)絡(luò)，并通過DHCP方式獲取IP地址?，F(xiàn)象描述*些類型的終端〔如聯(lián)想PC筆記本〕設(shè)備啟動后，無法從DHCP效勞器側(cè)獲取IP地址，導(dǎo)致PC用戶上網(wǎng)失敗。原因分析與終端相連的交換機Switch設(shè)置了STP使能，或者是默認設(shè)置為STP使能，但是其與終端相連的端口沒有配置成STP邊緣端口。終端網(wǎng)卡設(shè)置成以DHCP方式獲取IP地址的時候，會閃斷端口，然后發(fā)送4個請求分配IP的消息。由于交換機相應(yīng)端口沒有設(shè)置成邊緣端口，端口閃斷后，會觸發(fā)STP重新計算網(wǎng)絡(luò)拓撲，網(wǎng)絡(luò)重新收斂需要30s的時間，在收斂期間，端口轉(zhuǎn)發(fā)不通，因此將終端發(fā)送的請求分配IP消息均丟棄。終端只會發(fā)送4個請求分配IP的消息，在發(fā)送4個請求分配IP的消息后沒有收到回應(yīng)，終端就會認為獲取IP失敗，導(dǎo)致PC設(shè)備始終無法獲取IP地址。處理步驟確認交換機已經(jīng)STP使能，并且與終端相連的端口未配置成STP邊緣端口。確認當終端選擇從網(wǎng)卡啟動時，交換機上與之相連的端口會出現(xiàn)閃斷的情況。執(zhí)行命令用stpedged-portenable，將交換機上與各類終端相連的端口配置成邊緣端口?？偨Y(jié)與建議當交換機上使能了STP，其余與終端相連的端口均應(yīng)配置成邊緣端口。V200R001版本以及之后版本連接終端的端口可以自動探測，并將端口的邊緣端口屬性開啟。MSTP域配置不同導(dǎo)致非0實例無法調(diào)整收斂的故障案例涉及產(chǎn)品和版本S7700V100R003/V100R006/V200R001/V200R002/V200R003/V200R005S9700V200R001/V200R002/V200R003/V200R005S12700V200R005S2700&S3700&S5700V100R005/V100R006S3700&S5700&S6700V100R006/V200R001/V200R002/V200R003/V200R005組網(wǎng)情況如REF_d0e3089\r\h圖1-13所示，Switch-1和Switch-2通過3個端口GE0/0/20，GE0/0/23，GE0/0/24對接，其中GE0/0/20同時參加VLAN99、VLAN101，GE0/0/23僅參加VLAN99，GE0/0/24僅參加VLAN101。VLAN99屬于實例1，VLAN101屬于實例2?，F(xiàn)象描述兩臺Switch的STP收斂結(jié)果如下：GE0/0/20在實例1、2中都是Forwarding狀態(tài)，客戶希望該端口在不同的實例中STP狀態(tài)不同。調(diào)整該端口在不同實例中的cost值，收斂狀態(tài)仍然不變。原因分析現(xiàn)網(wǎng)兩臺Switch的MST域配置中域名不同，屬于不同的域。不同域間通過STP/RSTP協(xié)議進展收斂，所有實例都以實例0的結(jié)果為準。處理步驟兩臺Switch配置MSTP多實例，每個實例都能正常收斂，可排除配置問題。實例1、2的收斂結(jié)果與實例0一樣，檢查兩臺Switch是否在同一個域內(nèi)。兩臺Switch的MST域配置如下：Switch-1：Switch-2：上述配置顯示域名配置不同。MST域配置時，只有域名、多生成樹實例和VLAN的映射關(guān)系、Formatselector和Revisionlevel都一樣時，才認為兩臺設(shè)備在同一個域內(nèi)。同一個MST域內(nèi)的多個實例可獨立收斂，將兩臺Switch域配置中的域名配置成一樣的，同時調(diào)整端口GE0/0/20在不同實例中的cost值，使其在實例1和實例2中的STP狀態(tài)不同。經(jīng)歷總結(jié)S系列交換機默認使用系統(tǒng)MAC作為域名〔如：Regionname:00d0d0c7ec77〕。當交換機運行在MSTP模式，且域中配置多個實例時，需要關(guān)注域配置、端口參加的VLAN所屬的實例。兩端設(shè)備配置的MSTP報文的協(xié)議格式不一致導(dǎo)致端口DOWN故障案例涉及產(chǎn)品和版本S交換機所有產(chǎn)品和版本組網(wǎng)情況如REF_d0e3182\r\h圖1-14所示，Switch-1、Switch-2與兩臺H3CS6500組成MSTP環(huán)?，F(xiàn)象描述將Switch-1整機重啟并重新上電后，S6500-1的GE0/0/4端口會自動shutdown，必須手動undoshutdown才能恢復(fù)。且設(shè)備上打印如下告警：原因分析Switch和S6500互連端口均沒有配置MSTP報文的協(xié)議格式，使用默認值。但是默認值不一致，導(dǎo)致S6500接口被Shutdown。Switch端口的MSTP報文的協(xié)議格式stppliance默認為auto并發(fā)送dot1s格式報文，S6500默認發(fā)送legacy格式報文。S6500端口UP后連續(xù)發(fā)送3個legacy報文，Switch端口UP后發(fā)送1個dot1s報文，S6500回復(fù)1個dot1s報文，Switch回復(fù)S6500的legacy報文，后續(xù)兩端交互dot1s報文。S6500在進展報文格式檢查時有特殊的處理機制：10秒內(nèi)收到的legacy和dot1s報文都大于等于3個時，將端口Shutdown。處理步驟在Switch整機啟動端口UP后，在S6500上執(zhí)行命令displaystpinterface，查看直連UP端口的信息，發(fā)現(xiàn)MSTPBPDUformat為legacy：執(zhí)行命令stppliancelegacy，將Switch連接S6500的端口強制配置為legacy模式。經(jīng)歷總結(jié)在與其他廠商設(shè)備對接時，需要關(guān)注對端接口收發(fā)MSTP報文的協(xié)議格式是否默認為auto，是否有特殊的檢查機制。當Switch端口配置為非auto格式，端口收到的報文格式與配置不一致時，打印如下日志：出現(xiàn)該情況后，建議按照如下方法處理：使用獲取報文工具記錄收到的錯誤報文。記錄查詢對端的接口信息，如設(shè)備廠商、版本、配置。如果是華為設(shè)備，使用命令displayversion，displayinterface或displaycurrent-configuration查詢設(shè)備的版本、配置等。如果是其他廠商設(shè)備，則根據(jù)該廠商的設(shè)備命令獲取信息。由于此時MSTP收到非法報文，計算出來的STP狀態(tài)錯誤，有可能導(dǎo)致出現(xiàn)二層環(huán)路(使用displaystpbrief命令查看接口STP狀態(tài)，可確認是否存在環(huán)路)，建議先shutdown接口，防止形成播送風暴。確認不存在環(huán)路后，使用undoshutdown命令恢復(fù)接口。部署RRPP多實例未考慮端口默認參加VLAN1導(dǎo)致RRPP臨時環(huán)路故障案例涉及產(chǎn)品和版本S交換機所有產(chǎn)品和版本組網(wǎng)情況如REF_fig30221113145127\r\h圖1-15所示，SwitchA、SwitchB、SwitchC和SwitchD構(gòu)成RRPP環(huán)。開場規(guī)劃的時候，RRPP環(huán)保護VLAN10和VLAN20的數(shù)據(jù)，將VLAN10和VLAN20參加到實例1，保護VLAN配置引用實例1?，F(xiàn)象描述在上述組網(wǎng)中，VLAN1數(shù)據(jù)成環(huán)。原因分析執(zhí)行命令displaycurrent-configurationinterfaceGigabitEthernet1/0/1查看RRPP環(huán)上的端口下配置，沒有undoporttrunkallow-passvlan1說明端口默認參加了VLAN1。執(zhí)行命令displaystpregion-configuration，查看多實例劃分情況。執(zhí)行命令displaycurrent-configurationconfigurationrrpp-domain-region，查看RRPP的相關(guān)配置，RRPP域保護實例1中的VLAN，VLAN1不在實例1下，RRPP環(huán)不能保護VLAN1的數(shù)據(jù)，導(dǎo)致VLAN1的數(shù)據(jù)在RRPP環(huán)上沒有破環(huán)，造成環(huán)路。處理步驟有以下2種方法解決VLAN1的環(huán)路問題：方法一：在SwitchA、SwitchB、SwitchC和SwitchD上，將VLAN1規(guī)劃到實例1中。以下以SwitchA為例。方法二：如果VLAN1沒有用處，可以將接入RRPP環(huán)的端口下的VLAN1刪除。以下以SwitchA為例?？偨Y(jié)與建議在規(guī)劃RRPP環(huán)保護VLAN的時候，需要關(guān)注端口下默認參加VLAN1的情況，防止沒有將VLAN1規(guī)劃到保護VLAN中，造成環(huán)路。RRPP主節(jié)點模式和其他傳輸節(jié)點模式不一致，導(dǎo)致不能刷新MAC表項故障案例涉及產(chǎn)品和版本S交換機所有產(chǎn)品和版本組網(wǎng)情況如REF_d0e3483\r\h圖1-16所示，SwitchA、SwitchB、SwitchC和SwitchD構(gòu)成RRPP環(huán)，SwitchA是主節(jié)點，SwitchB、SwitchC和SwitchD為傳輸節(jié)點?，F(xiàn)象描述當RRPP傳輸節(jié)點SwitchB、SwitchC和SwitchD之間鏈路故障以及恢復(fù)，其他傳輸節(jié)點的MAC和ARP沒有刷新，流量受到影響。原因分析RRPP主節(jié)點SwitchA上配置的RRPP模式是國標模式，SwitchB、SwitchC和SwitchD上使用的是默認的華為模式。當傳輸節(jié)點出現(xiàn)故障后，RRPP主節(jié)點SwitchA發(fā)送的mon或者plete報文在傳輸節(jié)點上不處理，導(dǎo)致MAC和ARP沒有刷新，流量受到影響。處理步驟判斷RRPP的主節(jié)點為SwitchA：查看RRPP主節(jié)點SwitchA的配置：RRPP其他傳輸節(jié)點配置為：由上述配置可以看出：RRPP主節(jié)點SwitchA全局配置RRPP的工作模式為國標模式〔rrppworking-modeGB〕，其他傳輸節(jié)點是默認的配置〔默認配置為華為模式〕。經(jīng)歷總結(jié)RRPP環(huán)上所有節(jié)點都必須配置一樣的工作模式，要么都為默認的華為工作模式，要么都配置為國標模式。RRPP環(huán)網(wǎng)鏈路切換傳輸節(jié)點無法登錄故障案例涉及產(chǎn)品和版本S交換機所有產(chǎn)品和版本組網(wǎng)情況如REF_zh-_topic_0010234543_fig6020070815515\r\h圖1-17所示，SwitchA作為RRPP環(huán)的主節(jié)點，正常情況下GE1/0/0為Primaryport、GE2/0/0為Secondaryport〔block〕。現(xiàn)象描述當*個傳輸節(jié)點的Primaryportdown了再恢復(fù)后，此傳輸節(jié)點以及環(huán)上后面的節(jié)點會無法登陸，幾分鐘后恢復(fù)。原因分析RRPP主節(jié)點和傳輸節(jié)點RRPP工作模式不一致，主節(jié)點RRPP為GB模式，傳輸節(jié)點RRPP為HW模式，導(dǎo)致傳輸節(jié)點無法正常處理主節(jié)點的FLUSH報文。處理步驟查看設(shè)備的RRPP工作模式是GB還是HW模式：即配置是rrppworking-modegb，還是rrppworking-modehw。執(zhí)行displayrrppbrief命令查看RRPPWorkingMode字段，查看環(huán)上RRPP點該字段是否一致。經(jīng)歷總結(jié)出現(xiàn)該問題時，先查看下設(shè)備的MAC表和ARP表切換前后表項是否正常刷新了，如果沒有則檢查RRPP模式是否一致。未關(guān)注多實例配置部署RRPP環(huán)導(dǎo)致環(huán)路故障案例涉及產(chǎn)品和版本S交換機所有產(chǎn)品和版本組網(wǎng)情況如REF_fig33026303152844\r\h圖1-18所示，SwitchA、SwitchB和SwitchC構(gòu)成RRPP環(huán)，SwitchB是環(huán)上主節(jié)點，SwitchC是環(huán)上的傳輸節(jié)點，SwitchA上的端口GE2/0/4和GE1/0/5允許RRPP環(huán)的控制VLAN2515通過，SwitchB和SwitchC上的保護VLAN保護實例0下的VLAN?，F(xiàn)象描述部署主節(jié)點SwitchB時，未關(guān)注設(shè)備上的多實例配置，導(dǎo)致非0實例下的VLAN數(shù)據(jù)成環(huán)，造成非常多的接入設(shè)備脫管。原因分析檢查SwitchB上RRPP的配置。執(zhí)行命令displaycurrent-configurationconfigurationrrpp-domain-region，查看RRPP域的配置。檢查多實例配置執(zhí)行命令displaystpregion-configuration，查看SwitchB的多實例配置。檢查VLAN配置執(zhí)行命令displayvlan，查看實例1中的VLAN對應(yīng)的接口信息。SwicthB的配置如下：SwitchC的配置如下：SwitchA的配置如下：分析上述回顯信息，發(fā)現(xiàn)環(huán)上的每個接口都允許VLAN2500通過，且有環(huán)外的端口也允許VLAN2500通過，VLAN2500在實例1下，而RRPP協(xié)議保護是實例0下的VLAN，導(dǎo)致VLAN2500的數(shù)據(jù)成環(huán)。處理步驟部署RRPP環(huán)的目的是保護所有VLAN，因此可以將實例1刪除。以SwitchB為例。總結(jié)與建議部署RRPP環(huán)的時候，需要關(guān)注設(shè)備之前的多實例配置是否對部署影響。交換機誤配置loopbackinternal導(dǎo)致環(huán)路故障案例涉及產(chǎn)品和版本S交換機所有產(chǎn)品和版本組網(wǎng)情況如REF_d0e3800\r\h圖1-19所示，Switch通過L2Switch交換機下掛PC用戶，PC用戶希望訪問內(nèi)網(wǎng)效勞器Server?，F(xiàn)象描述當Switch下掛PC用戶訪問效勞器Server時，發(fā)現(xiàn)丟包嚴重，業(yè)務(wù)中斷。原因分析設(shè)備上存在loopbackinternal誤配置，導(dǎo)致MAC漂移，通信異常。處理步驟刪除L2Switch上誤配置的loopbackinternal。在Switch的VLAN視圖下執(zhí)行命令loop-detecteth-loopalarm-only，使能MAC-Flapping檢測機制，執(zhí)行命令displaytrapbuffer，查看告警信息，找尋是否存在MACFlapping以及漂移的端口告警。通過告警得知Switch上接口GE0/0/1下接口存在MAC漂移，可以先排查下游設(shè)備配置。登錄L2Switch設(shè)備，執(zhí)行命令displaycurrent-configuration，查詢L2Switch接口配置，發(fā)現(xiàn)有接口下配置了loopbackinternal，導(dǎo)致Server的MAC地址學(xué)習到Switch與L2Switch相連的端口。總結(jié)與建議對于二層轉(zhuǎn)發(fā)丟包，MAC漂移是較常見的一種原因。當出現(xiàn)此類問題時，可以查看設(shè)備是否發(fā)生了MAC漂移，并排除此故障。配置不合理大量TC報文導(dǎo)致框式交換機ARP學(xué)習異常故障案例涉及產(chǎn)品和版本S交換機所有產(chǎn)品和版本組網(wǎng)情況如REF_d0e3979\r\h圖1-20所示，Switch-A和Switch-B通過Eth-Trunk鏈路直連，起VRRP協(xié)議，Switch-A為VRRP主設(shè)備，Switch-B為VRRP備設(shè)備。Switch-A和Switch-B做三層網(wǎng)關(guān)，下掛多臺接入交換機做二層，均使能了STP協(xié)議進展破環(huán)。二層交換機直接接入用戶?，F(xiàn)象描述Switch-A交換機上ARP學(xué)習異常，有很多Inplete的ARP表項，下面用戶終端的ARP時有時無，業(yè)務(wù)不穩(wěn)定。原因分析Switch下掛的二層交換機上，STP域的邊緣端口均沒有配置stpedged-portenable，這些端口狀態(tài)發(fā)生變化時會發(fā)送TC報文，Switch收到后進展STP收斂處理，立即去除ARP表項或進展老化探測處理Switch上因為ARP數(shù)量比擬多，發(fā)送大量ARP請求報文進展探測，收到用戶的ARP應(yīng)答報文比擬多，超過了cpcar值，局部ARP應(yīng)答報文丟棄，這些ARP將被老化刪除，對應(yīng)用戶業(yè)務(wù)不能使用。Switch頻繁收到這樣的TC報文，業(yè)務(wù)更加不穩(wěn)定。處理步驟登陸設(shè)備進展觀察，查看VLANIF27接口下的ARP。該VLANIF接口接入的是經(jīng)常在線的用戶的效勞器。長時間觀察，發(fā)現(xiàn)接口下的ARP總數(shù)有時在50個左右，有時在20個左右，數(shù)量不穩(wěn)定。同時還有Inplete狀態(tài)的ARP，IP地址也不固定。學(xué)習到的ARP表項的老化時間有時都為0。從現(xiàn)象看，Switch應(yīng)該是收到了TC報文，進展了老化ARP的操作。通過displaystptc命令也可以看到端口收到的TC報文情況：分析日志，日志中也顯示收到TC報文、進展ARP表項老化處理的記錄：同時有arp-reply報文的cpcar丟棄記錄：基于上面的信息，分析得出：Switch頻繁收到TC報文，進展老化ARP表項的操作。設(shè)備需要發(fā)送大量ARP探測報文，用戶終端回應(yīng)arp-reply報文的數(shù)量也很多，超過了cpcar的car值，局部應(yīng)答報文丟棄，ARP表項就會老化刪除，影響到業(yè)務(wù)應(yīng)用。Switch收到的TC報文是下面的接入交換機發(fā)送的。接入交換機直接連接PC，端口使能了STP，但是沒有配置stpedged-portenable。PC在開機和關(guān)機時，很多邊緣端口UP、DOWN，交換機就會反復(fù)發(fā)送TC報文。將這些邊緣端口配置stpedged-portenable后，經(jīng)過幾天的觀察，沒有再出現(xiàn)問題了，用戶的業(yè)務(wù)運行正常?？偨Y(jié)與建議類似的問題出現(xiàn)過很屢次，交換機做網(wǎng)關(guān)，下掛二層交換機接入用戶，網(wǎng)絡(luò)中使用STP協(xié)議破環(huán)。通常，二層交換機上的STP邊緣端口都沒有配置stpedged-portenable。用戶PC上線、下線，端口就會反復(fù)UP/DOWN，設(shè)備向STP根節(jié)點發(fā)送TC報文。網(wǎng)關(guān)設(shè)備頻繁進展STP收斂，去除ARP，導(dǎo)致ARP學(xué)習異常。這種應(yīng)用場景下，推薦配置：交換機上配置stpconvergenormal，這樣交換機收到TC報文，不會立即去除ARP，而是發(fā)起ARP探測，探測失敗才會刪除ARP，對流量轉(zhuǎn)發(fā)不會造成很大的影響；二層交換機的STP邊緣端口上配置stpedged-portenable，這樣邊緣端口的狀態(tài)變化不會引起網(wǎng)絡(luò)反復(fù)進展STP收斂。大量TC報文導(dǎo)致CPU高的故障案例涉及產(chǎn)品和版本S交換機所有產(chǎn)品和版本組網(wǎng)情況無現(xiàn)象描述通過網(wǎng)管監(jiān)控的CPU利用率情況，如REF_d0e4100\r\h圖1-21所示：同時設(shè)備上還出現(xiàn)CPU占用率過高的日志信息。同時設(shè)備上還有大量的ARP報文超過CPCAR后丟棄的日志記錄。采集端口TC〔TopologyChange〕報文收發(fā)情況。如REF_zh-_topic_0010234514_fig6746171213129\r\h圖1-22所示，所有使能STP的端口，接收的TC報文計數(shù)均在增長。問題根因說明通過查看端口的TC報文計數(shù)，發(fā)現(xiàn)端口收到大量的TC報文，且在不斷增長。觸發(fā)MAC刪除、ARP表項刷新，設(shè)備處理大量arp-miss、arp-request和arp-reply報文，導(dǎo)致CPU升高，OSPFHello報文、VRRP心跳報文不能及時處理，出現(xiàn)震蕩。問題判斷方法全局配置stptc-protection。配置此命令后可以保證設(shè)備頻繁收到TC報文時，每2秒周期內(nèi)最多只處理1次表項刷新。從而減少MAC、ARP表項頻繁刷新對設(shè)備造成的CPU處理任務(wù)過多。全局配置arptopology-changedisable及mac-addressupdatearp。當設(shè)備收到TC報文后，默認會去除MAC、老化ARP。當設(shè)備上的ARP表項較多時，ARP的重新學(xué)習會導(dǎo)致網(wǎng)絡(luò)中的ARP報文過多。配置arptopology-changedisable、mac-addressupdatearp后，在網(wǎng)絡(luò)拓撲變化時，可以根據(jù)MAC地址的出接口變化刷新ARP表項出接口。可以減少大量不必要的ARP表項刷新。V100R006版本開場支持mac-addressupdatearp，V200R001版本開場支持arptopology-changedisable命令。經(jīng)歷總結(jié)在部署STP時，建議配置TC保護功能，所有連接終端的接口配置成邊緣端口，這樣可以防止*些端口的狀態(tài)變化引起整個STP網(wǎng)絡(luò)震蕩而重新收斂。在處理CPU高的問題時，多關(guān)注cpcar丟包情況。MSTP環(huán)路導(dǎo)致CPU占用率高的故障案例涉及產(chǎn)品和版本S5700V200R001/V200R002/V200R003組網(wǎng)情況無現(xiàn)象描述MSTP網(wǎng)絡(luò)中出現(xiàn)S5700交換機CPU使用率高。原因分析MSTP環(huán)網(wǎng)中，因各類原因引起拓撲重新計算，網(wǎng)絡(luò)中會發(fā)布大量拓撲改變BPDU報文，使得設(shè)備占用CPU進展計算，從而導(dǎo)致CPU使用率高。處理步驟執(zhí)行命令displayinterfacebrief，查看端口帶寬使用率是否較高。執(zhí)行命令displaystptc-bpdustatistics，查看端口TC/T報文收發(fā)計數(shù)，發(fā)現(xiàn)設(shè)備收到大量的TC報文。由于網(wǎng)絡(luò)中無法確定引起拓撲改變的故障點，為解決本設(shè)備CPU使用率高的問題，可進展如下操作：使能arptopology-changedisable，即當網(wǎng)絡(luò)的拓撲變化的時候，系統(tǒng)的ARP表項不再進展老化或者刪除操作的功能使能mac-addressupdatearp，即當MAC地址的出接口變化時，通知更新ARP表項的出接口。V100R006版本開場支持mac-addressupdatearp，V200R001版本開場支持arptopology-changedisable命令。CPU使用率明顯下降，問題解決?？偨Y(jié)與建議當在MSTP網(wǎng)絡(luò)中發(fā)現(xiàn)設(shè)備使用率高的問題時，應(yīng)首先查看設(shè)備是否收到大量TC報文。假設(shè)收到大量TC報文，可以采用關(guān)閉ARP隨拓撲變化老化刪除功能，啟用MAC地址出接口變化同步更新ARP表項的功能來解決。S9300端口配置處理BPDU報文導(dǎo)致STP收斂異常的故障案例涉及產(chǎn)品和版本框式交換機所有版本問題現(xiàn)象描述及組網(wǎng)如REF_d0e4316\r\h圖1-23所示，S9300〔V100R003C00SPC200〕與S8500組成RRPP環(huán)，其中S9300為RRPP主節(jié)點，紅色標注的為RRPP阻塞口。下掛的S3328、S5624均使能STP，S9300、S8500透傳STP報文。用戶反應(yīng)S3328上STP可以正常收斂〔紅色標注的為STP阻塞口〕，但S5624上的STP一直震蕩。問題根因說明S5624全局、端口默認使能NDP，S9300連接S8500、S5600端口下由于配置了bpdubridgeenable，導(dǎo)致S5624發(fā)送的NDP報文成環(huán)，沖擊S5624的CPU，無法正常處理STP報文。問題判斷方法分析S9300、S8500上連接S5624、S3328的端口配置，除端口下允許通過的VLAN不同外，其他配置都一樣。S9300端口配置如下：實驗室復(fù)現(xiàn)環(huán)境中發(fā)現(xiàn)當S9300、S8500、S5600互連端口均UP后，S5600的CPU利用率很快上升到100％。對S5600端口收到的報文進展分析，發(fā)現(xiàn)端口收到了大量NDP報文〔目的MAC：0180-c200-000a〕。S5600全局和端口默認使能NDP，端口會定期發(fā)送NDP報文。NDP報文到達S9300后，S9300RRPP主、副端口下均配置了bpdubridgeenable，副端口雖然被RRPP阻塞，NDP報文可以正常轉(zhuǎn)發(fā)。從而導(dǎo)致NDP報文在S8500、S9300間成環(huán)，并通過GE1/0/2端口轉(zhuǎn)發(fā)到S5600。大量NDP報文沖擊S5600，STP報文不能正常處理。而S3328全局、端口默認不使能NDP，收到NDP報文后會丟棄，所以STP收斂正常。解決方案刪除S9300連接S8500、S3328、S5600端口下的bpdubridgeenable配置。經(jīng)歷總結(jié)S9300V100R002版本端口下的bpduenable命令，V100R003、V100R006版本端口下的bpdubridgeenable命令用來使能端口轉(zhuǎn)發(fā)BPDU報文，端口對收到的目的MAC屬于BPDUMAC并且沒有上送CPU處理的報文不會丟棄，直接硬件轉(zhuǎn)發(fā)。端口的二層協(xié)議透傳功能不需要借助bpduenable或bpdubridgeenable配置。BPDUMAC可以通過displaybpdumac-address命令查看。盒式交換機V100R006之前的版本使能二層協(xié)議透傳功能的端口，除配置bpdu-tunnelenable或l2protocol-tunnelenable外，S2300全局、S3300&5300端口下需要配置bpduenable，相關(guān)報文才能被上送到CPU處理。ATAE設(shè)備STP超時時間計算不合理導(dǎo)致STP網(wǎng)絡(luò)振蕩的故障案例涉及產(chǎn)品和版本S交換機所有產(chǎn)品和版本組網(wǎng)情況無。現(xiàn)象描述交換機和ATAE老版本使用STP對接，交換機為根橋，交換機上配置stptimerhello為1秒，上游交換機短時間繁忙或網(wǎng)絡(luò)有少量丟包，可能會導(dǎo)致ATAESTP超時振蕩。原因分析ATAE老版本超時時間=HelloTime×3，沒有TimeFactor時間超時因子，所以當根橋配置HelloTime時間為1s時，ATAE超時時間就是3s，當上游設(shè)備繁忙或網(wǎng)絡(luò)有少量丟棄，ATAESTP就容易超時振蕩。ATAE新版本已經(jīng)和S系列交換機一樣，超時時間已經(jīng)修改為HelloTime×TimeFactor×3，HelloTime默認為2s，TimeFactor默認為3，所以默認超時時間為18s。處理步驟ATAE老版本是否配置stptimer-factor時間因子；STP根橋上HelloTime時間是否為1s，即查看配置是否為stptimerhello100〔其中100的單位為厘秒，1s=100厘秒〕；另外還可以在STP振蕩期間，獲取報文確認是否是ATAE超時首先發(fā)出源MAC是00e0-fc09-bc-f9STP報文的。下面有2種解決方案：方案1：ATAE升級到支持TimeFactor時間因子的新版本。方案2：ATAE交換板仍然使用STP，修改主備根交換機的HelloTime時間至少為stptimerhello300，使得ATAE超時時間至少到達9s，延長超時時間。經(jīng)歷總結(jié)如果交換機在配置的超時時間內(nèi)沒有收到上游設(shè)備發(fā)送的BPDU，就認為上游設(shè)備已經(jīng)出現(xiàn)故障，交換時機重新進展生成樹拓撲的計算。但是有時交換機在較長的時間內(nèi)收不到上游設(shè)備發(fā)送的BPDU，是由于上游設(shè)備的繁忙造成的，在這種情況下一般不應(yīng)該重新進展生成樹計算。因此，在穩(wěn)定的網(wǎng)絡(luò)中，應(yīng)將超時時間配置的長一些，以減少網(wǎng)絡(luò)資源的浪費。在穩(wěn)定的網(wǎng)絡(luò)中，建議將TimerFactor的值設(shè)置為5～7。交換機和S6500RSTP互連端口DOWN后重新UP，但RSTP無法快速收斂故障案例涉及產(chǎn)品和版本S交換機所有產(chǎn)品和版本組網(wǎng)情況如圖1-24所示，兩臺S6500和Switch組成RSTP環(huán)，穩(wěn)定狀態(tài)下阻塞點為Switch與S6500-2相連的端口。現(xiàn)象描述通過shutdownS6500-1與Switch相連的端口，再恢復(fù)該端口來檢查RSTP快速收斂機制，發(fā)現(xiàn)S6500-1與Switch之間的鏈路恢復(fù)后，S6500-1與Switch的端口一直為discarding狀態(tài)，30s后才轉(zhuǎn)換為forwarding狀態(tài)。原因分析使用命令debuggingstpall，查看Flags字段是否有Agreement標記，如下只有Proposal：S6500-1與Switch相連的端口UP后，S6500-1發(fā)出的Proposal報文，沒有攜帶Agreement標記，導(dǎo)致接口無法快速遷移，即Proposal/Agreement機制不生效。處理步驟在Switch與S6500相連的接口下配置stpno-agreement-check。總結(jié)與建議當Switch和其他廠商的設(shè)備進展互通時，需要根據(jù)其他廠商設(shè)備的Proposal/Agreement機制，使用stpno-agreement-check命令來選擇接口使用增強的快速遷移機制還是普通的快速遷移機制。配置單播抑制導(dǎo)致RRPP震蕩持續(xù)一個小時故障案例涉及產(chǎn)品和版本S交換機所有產(chǎn)品和版本組網(wǎng)情況如REF_fig43649962205224\r\h圖1-25所示，RRPP主節(jié)點不停被破環(huán)，然后網(wǎng)絡(luò)又成環(huán)?，F(xiàn)象描述RRPP環(huán)協(xié)議震蕩，持續(xù)時間1個多小時，在日志中未見有異?！脖确浇涌谡鹗帯常矝]有發(fā)現(xiàn)在RRPP環(huán)上的接口有出入方向的FCS等異常計數(shù)；原因分析根據(jù)測試的結(jié)果來看,RRPP的HELLO報文在端口的未知單播流量增大的時候會被丟棄。連續(xù)丟棄3個報文后，RRPP的環(huán)狀態(tài)為Failed，待收到下一個HELLO報文時,又恢復(fù)正常。RRPP的環(huán)狀態(tài)就在Failed和plete之間震蕩。處理步驟按照現(xiàn)網(wǎng)的配置搭建測試環(huán)境，S3328上的RRPP狀態(tài)正常。[119-S3328TP-01]displayrrppverbosedomain1DomainInde*:1ControlVLAN:major4091sub4092ProtectedVLAN:ReferenceInstance0HelloTimer:1sec(defaultis1sec)FailTimer:3sec(defaultis6sec)RRPPRing:1RingLevel:0NodeMode:MasterRingState:pleteIsEnabled:EnableIsActived:YesPrimaryport:GigabitEthernet0/0/1Portstatus:UPSecondaryport:GigabitEthernet0/0/2Portstatus:BLOCKED測試儀向S3328發(fā)送攜帶RRPP的control-vlan的未知單播流量。查看設(shè)備的RRPP狀態(tài)，出現(xiàn)協(xié)議震蕩，且恢復(fù)時間間隔為與現(xiàn)網(wǎng)的現(xiàn)象一樣。Jan2200820:02:48119-S3328TP-01%%01RRPP/4/PFWD(l):Domain1Ring1PortGigabitEthernet0/0/2hasbeensettoforwardingstate.#Jan220:02:502008119-S3328TP-01RRPP/4/RNGDN:1.3.6.1.4.1.2011.5.25.113.4.2:Domain1ring1isfailed.Jan2200820:02:50119-S3328TP-01%%01RRPP/3/FAIL(l):Domain1Ring1failed.Jan2200820:02:50119-S3328TP-01%%01RRPP/4/PBLK(l):Domain1Ring1PortGigabitEthernet0/0/2hasbeensettoblockstate.#Jan220:02:532008119-S3328TP-01RRPP/6/RNGUP:1.3.6.1.4.1.2011.5.25.113.4.1:Domain1ring1isrestored.#Jan220:03:082008119-S3328TP-01RRPP/4/RNGDN:1.3.6.1.4.1.2011.5.25.113.4.2:Domain1ring1isfailed.Jan2200820:03:08119-S3328TP-01%%01RRPP/4/PFWD(l):Domain1Ring1PortGigabitEthernet0/0/2hasbeensettoforwardingstate.Jan2200820:03:08119-S3328TP-01%%01RRPP/3/FAIL(l):Domain1Ring1failed.Jan2200820:03:08119-S3328TP-01%%01RRPP/4/PBLK(l):Domain1Ring1PortGigabitEthernet0/0/2hasbeensettoblockstate.由復(fù)現(xiàn)結(jié)果可以斷定，現(xiàn)網(wǎng)中由于配置未知單播抑制引發(fā)協(xié)議震蕩，可執(zhí)行命令undounicast-suppression，刪除未知單播抑制功能。總結(jié)與建議客戶在RRPP環(huán)上的端口不要配置未知單播抑制。否則，未知單播流量增大的時，有可能造成RRPP的HELLO報文丟棄，影響RRPP環(huán)狀態(tài)的穩(wěn)定，造成協(xié)議震蕩。配置未知單播抑制，RRPP環(huán)出現(xiàn)震蕩的故障案例涉及產(chǎn)品和版本S交換機所有產(chǎn)品和版本組網(wǎng)情況如圖1-26所示，SwitchA作為RRPP環(huán)的主節(jié)點，正常情況下GE1/0/0為Primaryport、GE2/0/0為Secondaryport〔block〕。現(xiàn)象描述RRPP環(huán)組網(wǎng)中，主節(jié)點不停被破環(huán)，然后網(wǎng)絡(luò)又成環(huán)。原因分析設(shè)備上配置了未知單播抑制功能，而RRPP的協(xié)議報文的目的MAC為未知單播MAC。在端口未知單播流量較多時，RRPP協(xié)議報文會被抑制掉，從而導(dǎo)致設(shè)備認為RRPP的環(huán)鏈路出現(xiàn)故障，從而放開阻塞，導(dǎo)致成環(huán)。處理步驟通過displayrrppstatistics命令查看到，設(shè)備不時發(fā)送或者接收到LINKDOWN報文，并且設(shè)備上的主端口和負端口的HEALTH報文Send和Rcv計數(shù)不一致；查看配置，設(shè)備上面配置了未知單播抑制命令unicast-suppression。接口視圖下執(zhí)行命令undounicast-suppression，刪除未知單播抑制功能，故障解除?？偨Y(jié)與建議在使用RRPP、SEP、ERPS等協(xié)議，協(xié)議報文目的MAC為單播MAC時，請您不要配置未知單播抑制。C*600和S3300組成的RRPP環(huán)路業(yè)務(wù)中斷故障案例涉及產(chǎn)品和版本S交換機所有產(chǎn)品和版本組網(wǎng)情況如圖1-27所示，C*600和S3300組成的RRPP環(huán)形組網(wǎng)，出現(xiàn)下掛業(yè)務(wù)中斷現(xiàn)象。現(xiàn)象描述RRPP環(huán)形網(wǎng)絡(luò)中C*600出現(xiàn)和S3328相連接口頻繁UP/DOWN的問題，隨后C*600所在RRPP環(huán)出現(xiàn)成環(huán)問題，并且該C*600下掛的其他RRPP環(huán)也出現(xiàn)了環(huán)路，導(dǎo)致了下掛業(yè)務(wù)異常，將出現(xiàn)問題的RRPP環(huán)手動斷開后，業(yè)務(wù)恢復(fù)。原因分析出現(xiàn)問題的原因是由于鏈路質(zhì)量不好，在拔插光纖時C*600和S3328兩邊接口UP出現(xiàn)了時間差，導(dǎo)致RRPP協(xié)議報文喪失，所以報文開場大量復(fù)制并迅速成環(huán)，結(jié)果在很短時間〔1s〕內(nèi)就超過流量調(diào)度芯片能力擠占業(yè)務(wù)報文和協(xié)議報文帶寬，造成RRPP環(huán)不能正?；謴?fù)，從而更加劇環(huán)路，并影響所有連接到同一個數(shù)據(jù)VSI中的所有RRPP環(huán)，導(dǎo)致S3300下掛的業(yè)務(wù)異常。處理步驟登錄C*600設(shè)備，發(fā)現(xiàn)透傳RRPP協(xié)議報文的子接口沒有配置任何提升RRPP協(xié)議報文調(diào)度優(yōu)先級的命令，RRPP協(xié)議報文在C*600上完全按照普通的數(shù)據(jù)報文轉(zhuǎn)發(fā)，一旦出現(xiàn)超帶寬的流量，RRPP協(xié)議報文很可能被隨機丟棄。通過查詢流量調(diào)度芯片TM的計數(shù)發(fā)現(xiàn)，有超時和檢測錯誤出現(xiàn)，說明當時設(shè)備的流量非常大，超過了該芯片能處理的能力，這種情況下報文丟棄嚴重。分析日志發(fā)現(xiàn)C*600上連接RRPP環(huán)的端口變DOWN后，此時RRPP環(huán)的主節(jié)點肯定會放開副端口，但是由于和交換機UP時間不一致，有很大幾率導(dǎo)致1s鐘左右的環(huán)路。如果下一個RRPP協(xié)議報文能夠正常收到都會阻斷副端口，防止成環(huán)，但是現(xiàn)網(wǎng)中RRPP報文被大量丟棄。Loopdetct檢測到環(huán)路，阻斷相關(guān)子接口，上報trap告警。因為loop-detect報文是公司私有協(xié)議報文不帶任何優(yōu)先級信息，該報文很可能被丟棄，所以不是所有的環(huán)都會出現(xiàn)阻斷信息?？偨Y(jié)與建議現(xiàn)網(wǎng)S3328，端口已經(jīng)配置trust802.1p以及qoswrrqueue-inde*7weight0，對于RRPP協(xié)議報文優(yōu)先通過給予了保證。只需要再在C*600端口上配置trustupstreamdefault以及trust8021p，就保證RRPP協(xié)議報文優(yōu)先通過。在C*600上部署防攻擊方案，保證在出現(xiàn)環(huán)路時，C*600上路由協(xié)議正常運行。RTN設(shè)備與S交換機對接ERPS無法工作故障案例涉及產(chǎn)品和版本S交換機所有產(chǎn)品和版本組網(wǎng)情況如REF_fig47797753102430\r\h圖1-28所示，RTN網(wǎng)絡(luò)為了提高網(wǎng)絡(luò)可靠性，添加了兩臺交換機SwitchA和SwitchB，將RTNA和RTB鏈式網(wǎng)絡(luò)改造為環(huán)狀網(wǎng)絡(luò)，同時在交換機和RTN上部署ERPS協(xié)議?，F(xiàn)象描述網(wǎng)絡(luò)中發(fā)現(xiàn)RTN的owner節(jié)點和交換機的ERPS連接點均被阻塞。原