1、3528G交換機因和C廠家SXXXX交換機的STP協商失敗導致下掛業務全阻序號SC0000316261資料類別案例庫更新時間2006-12-25 11:19:33作者：熊俊宏產品：低端交換機產品族：以太網交換機故障類別：生成樹協議關鍵字：3528G C廠家SXXXX交換機Stp協商現象描述：3528G作為匯聚交換機割接上線（替換一臺C廠家交換機），下掛多臺交換機，下掛 某段地址業務出現中斷。告警信息：CPU占用率達50%，某網段地址業務不通，設備出現STP協議告警。原因分析： 查找該段地址，發現都是一臺C廠家SXXXX交換機下掛的業務，而3528G上出現大 量的STP告警，初步判斷其和SXXX

2、X交換機的STP協商存在問題。但3528G并未 啟動STP協議，C廠家SXXXX交換機默認開啟Stp協議。處理過程： 將c廠家SXXXX交換機關閉Stp，3528G的CPU占用率降至8%，業務恢復正常。3528G并未啟動STP協議但C廠家SXXXX交換機屬C廠家早期產品，STP協議不是 按照標準實現，其3528G無法識別C廠家SXXXX交換機上送的STP協議報文，而C 廠家SXXXX交換機又不停重傳，導致Cpu占用率高漲；C廠家SXXXX交換機的STP協議狀態頻繁切換也導致其下掛業務異常。建議與總結：無題:由于在trunk端口中取消了透傳vlanl導致華為和C公司交換機二層對接時生成樹異 常序

3、號SC0000316610資料類別案例庫更新時間2006-12-11 11:59:07作者：楊和宇產品： Quidway S8500產品族：以太網交換機故障類別：生成樹協議關鍵字：生成樹協議PVST對接現象描述： 設備：S8505，C廠商設備6509版本：S8500-VRP310-R1278P01-SI組網：兩臺S8505和一臺C廠商6509組成單鏈路環狀網絡，其中C廠商6509與S8505-A對接的端口為F4/1,與S8505-B對接的端口為F4/2S8505運行STP協議，C廠商6509 運行PVST協議，將S8505-A的優先級設為0，其余設備使用默認值。在3臺設備中 均創建vlan2和

4、vlan3，對接的各端口設為trunk，并取消透傳vlanl。組網圖： S8505-AS8505-B/C廠商6509故障現象：配置完成后，C廠商6509的f4/2端口阻塞，其他所有端口均處于轉發狀 態，看上去很正常，但查看生成樹信息后，發現華為設備和C廠商設備對根橋的認識 不一致。華為設備認為S8505-A是根橋，而C廠商6509設備認為自己是根橋。如果 2臺S8505之間的鏈路斷開，將各自認為自己是根橋。告警信息：無原因分析：PVST（每VLAN生成樹協議）是C廠商的私有協議。它在Vlanl上運行普通STP協議， 在其他Vlan上運行PVST協議。PVST可以與STP互通，在Vlanl上生成

5、樹狀態按照 STP協議計算。在其他Vlan上，華為交換機只會把PVST bpdu當作普通多播報文按 照默認Vlan或者Tag頭進行轉發，而C廠商設備收到普通STP bpdu將會丟棄。但這 并不影響環路的消除，只是有可能Vlanl和其他Vlan的根橋選取可能不一致。總之，在其他Vlan中華為和C廠商設備將互不知道對方的存在，華為設備可以透傳C 廠商的PVST bpdu報文，而C廠商將丟棄STP bpdu報文。因此，在鏈路斷開以前，2臺S8505之間通過直連鏈路傳遞bpdu，并一致認為S8505-A 為根橋，同時它們不知道C廠商設備的存在。由于C廠商設備丟棄S8505的bpdu， 因此S8505與

6、C廠商設備對接的端口均處于轉發狀態。C廠商設備不知道S8505的存 在，但能夠收到自己的bpdu，因此認為出現了環路，而阻塞端口號較大的F4/2端口。 鏈路斷開以后，由于S8505之間無法傳遞bpdu，因此各自認為自己是根橋。處理過程： 在c廠商6509的各端口上允許vlanl，華為設備即可與C廠商設備在vlanl上一致認 為S8505-A為根；在其他vlan上雖然不能在根橋的選擇方面達成一致，但至少S8505 的bpdu可以通過C廠商設備傳遞。建議與總結：l、華為設備可以與C廠商設備進行二層對接，即使根橋選取不一致，各端口狀態仍 然正常，能夠避免環路。2、在華為設備與C廠商設備進行二層對接時

7、不要取消透傳vlanl，尤其是不要在C廠 商設備上取消透傳vlanl。3、如果各端口類型為access，則對接沒有任何問題。4、華為設備與C廠商設備最好不要在二層進行對接。各設備生成樹協議狀態（鏈路斷開前）.txt附件：各設備生成樹協議狀態（鏈路斷開后）.txt各設備生成樹協議狀態（在C廠商6509的各端口上允許vlanl）.txtS8016與C公司設備組網時RSTP互通的注意事項序號：SC0000179145資料類別：案例庫質量等級：或0更新時間：2005-12-26 08:55:28作者：韓志華94795產品族：以太網交換機產品：Quidway S8016故障類別：生成樹協議關鍵字：S80

8、16 RSTP現象描述：由于c公司設備運行的是其私有的生成樹協議PVST+，S8016在與其對接時可能存 在的某些問題，需要在組網的時候認真對待，注意避免。處理過程：c公司支持的STP協議有三種：PVST+,MISTP,MSTP。這三個協議都具備不同程度 的VLAN認知能力，這一點是RSTP不具備的；其中，只有PVST+與MSTP才能與 RSTP互通。以C65xx為例，在S8016與其互通會遇到如下一些問題：1、STP進行拓撲計算，發生拓撲變化后，應該進行TCN處理，刪除相關端口的MAC 表項，還應該老化相應的ARP表項，否則，會造成三層轉發的中斷。這一點，S8016 已經實現了，但C6509

9、在拓撲變化后會連續30秒發送1718個TC置位的 STP BPDU，這對網絡的穩定會有一定的影響。2、PVST+協議在VLAN 1上運行的是普通STP協議（不帶vlan tag，和RSTP報文 內容完全相同），在其他VLAN上運行PVST+協議（報文會帶上vlan tag，這些報文 對于S8016來說就是普通的數據報文，進行透明轉發處理）。如果在C6509的端口上 不TRUNK 1，則普通STP協議報文不能發出，兩邊都會以為自己是根橋。3、S8016是不區分VLAN進行STP計算，進行鏈路的阻斷；而C6509則區分VLAN 進行鏈路的阻斷。這在某些組網情況下，會造成某些VLAN不通，需要針對網

10、絡的 具體配置情況，進行分析，看看有沒有可能出現這樣的結果。4、C65xx提供了這樣一種機制：為了防止單生成樹阻塞Trunk鏈路，在C6509的非 Trunk端口上一旦收到帶Trunk標記的PVST+ BPDU就優先阻斷非Trunk端口。這 種情況下，該端口被設為type-inconsis狀態，阻斷該鏈路。但實際上，這樣的機制 很糟糕，引入了更多的問題，比如不正確的阻斷某些鏈路，甚至出現網絡環路。建議與總結：無S8016 VRP3.10-23XX與C廠家交換機互連不通序號：SC0000177788資料類別：案例庫質量等級：備0更新時間：2005-12-21 15:06:21作者：韓志華9479

11、5產品族：以太網交換機產品：Quidway S8016故障類別：生成樹協議關鍵字：S8016現象某局一臺S8016啟用STP，某日通過GE向上掛接一臺C廠家L2，發現業務不通，S8016端口 up，描C廠家L2端口 down。述：告警信息：原因1、物理連接故障。分2、端口故障。析：3、端口協商問題。處理1、經過檢查物理連接良好，端口無故障，查看S8016及C廠家L2，端口協商正常。過2、登錄C廠家L2,發現系統打印如下日志：程： 1y9w: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet0/1, changed s

12、tate to dow n可知C廠家L2設備在G0/1發現環路，down掉了該端口。3、由于C廠家L2缺省啟用其私有生成樹協議，BPDU從G0/1發出后又從該端口收回，導致設備 認為該端口存在環路，down掉了該端口。關閉該設備生成樹協議后，端口互連正常。建議由于C廠家運行的是私有的生成樹協議，在與我司設備對接時建議盡量三層互連，避免統一運行生 與總成樹。此例也可將S8016升級到2321版本解決，在B03版本中，存在隨機出現的情況，在VLAN 結：口，將從對端收到的STP報文又從該端口轉發回去。對端設備判斷自己收到自己發出去的報文，認 為環路，把端口 Block導致。標題：S5516交換機的

13、MSTP與C廠商交換機的PVST無法對接序號：SC0000174185資料類別：案例庫質量等級：酸0更新時間：2005-12-29 15:59:45作者：熊榮產品族：以太網交換機產品：Quidway S5500/6500故障類別：生成樹協議關鍵字：S5516 STP生成樹PVST現象描述：S5516交換機和一 C廠商交換機對接，需要啟用生成樹協議，在S5516上配置了 MSTP，C廠商交換機上也啟用了生成樹協議，但兩端配置后發現生成樹并不生效。告警信息：無原因分析：檢查C廠商交換機上的配置發現其使用的是PVST的模式。由于PVST是C廠商的私有協議，而MSTP是公有協議，這樣兩邊使用的協議標準

14、不一致，兩者的協商也 就不能成功，從而導致配置的MSTP無法生效。而C廠商交換機遵循MSTP標準的 是MST的模式。處理過程：將c廠商交換機的PVST模式修改為MST模式后與S5516生成樹有效的啟用了。建議與總結：在不同廠家的設備對接的時候，在開一些特殊的業務時，一定要明確兩邊使用的標 準是一致的，當兩邊的標準不一致時，在對接是就會出現問題C廠商交換機開啟私有協議與S3026E對接導致業務中斷序號：SC0000191845資料類別：案例庫質量等級： 備0更新時間：2006-03-13 15:14:24作者：李春祥產品族：以太網交換機產品：低端交換機故障類別：生成樹協議關鍵字：STP PVST

15、現象組網為：C3xxx-S3026E-C2xxx描C3xxx是匯聚交換機，通過trunk端口與S3026E相連。述：S3026E是接入層交換機，上行通過trunk端口與C3xxx相連，透傳多個vlan。S3026E下行通過ACCESS端口接C2xxx交換機，屬于VLAN50，C2xxx沒有配置數據，作為HUB 使用，并通過FA0/17端口接入S3026E。故障現象：C2xxx用戶不能正常訪問網絡。告C2xxx交換機上出現下列告警：警信 00:58:04: %SPANTREE-7-RECV_1Q_NON_TRUNK: Received 802.1Q BPDU on non trunk FastE

16、thernet 息：0/17 VLAN100:58:04: %SPANTREE-7-BLOCK_PORT_TYPE: Blocking FastEthernet0/17 on VLAN0001. Inconsistent port type原C3xxx與S3026E對接的端口是TRUNK端口。默認情況下，C3xxx開啟了 PVST協議（PVST協議 因分是c廠商的私有協議，即per vlan span tree協議），C3xxx會定時向S3026E的VLAN 1發標準stp報 析：文，其它VLAN發PVST的報文，該報文的目的mac為01-00-0c-cc-cc-cd。S3026E無法識別ci

17、sco的私有協議，收到PVST報文后，當作普通報文轉發，而C2xxx收到PVST報文的是ACCESS端口， 它會認為這個網絡異常，存在環路，于是將這個端口阻塞。處通過在S3026E上過濾PVST報文，即通過ACL的功能拒絕目的mac地址為01-00-0c-cc-cc-cd的數理過據報文通過，問題解決。程：建議與無總結：序號 資料類別 更新時間作者產品族 故障類別 關鍵字 現象描述告警信息:原因分析:處理過程:建議與總結:關于C公司交換機與華為S3552對接起生成樹的問題SC0000384292案例庫質量等級：急C2007-10-08 10:31:00chenyuji以太網交換機產品：低端交換機

18、生成樹協議C公司MSTP拓撲為兩臺C公司交換機與兩臺S3552成全網狀連接。C公司交換機配置MSTP兩個 實例分別為實例0和實例1。實例0包含VLAN1-500，實例1包含VLAN500-1000O 兩臺S3552配置了實例1。實例1包含VLAN500-1000。S3552與C公司交換機互連的端口配置access vlan 502，兩臺S3552互連端口配置 trunk vlan 502，兩臺C公司交換機互連端口配置trunk vlan all。C公司交換機上配置：實例0內以交換機-1為主根，實例1內以交換機-2為主根.。 對接后發現S3552以交換機-1為主根，而不以交換機-2為主根。無詳細查閱資料發現，C公司交換機和華為的交換機對接，因雙方的MSTP機制不一致， 導致雙方的BPDU的交互實際上只是在實例0內進行交互，不能進行其他實例的交互。 為此，我們的交換機有專門的命令用于忽略與其它廠家對接時忽略MSTP BPDU報文 中的域信息（即實例信息），因此