如何輕鬆定位STP故障
作為IEEE標準協議，STP具有兼容性好、網絡規劃要求低、配置簡單等優勢，被廣泛應用於二層網絡中。當然，用得多了大家碰到的問題也就多了，STP有哪些故障現象呢，這些故障又是怎麼排除的呢？小編這次就結合幾個實際的STP故障，和大家分享一下STP故障解決之道。
小貼士
小夥伴們注意啦，本文中所指的STP是指廣義的STP哦，包括STP協議、RSTP協議、MSTP協議。當需要對三者進行區分時，分別會敘述為STP模式、RSTP模式、MSTP模式。
故障現象1：使能STP的網絡拓撲中出現鏈路故障或鏈路故障恢復後，業務流量恢復需要超過30秒，即端口無法快速收斂
定位思路
遇到這種問題時，小編給大家總結了如下的定位思路：
1) 確認對端端口是否使能STP；
2) 檢查端口是否工作在STP模式；
3) 檢查端口的鏈路類型是否為點對點。
定位步驟
具體的定位步驟，請小夥伴們往下瞅：
步驟1：確認對端端口是否使能STP
終端、服務器都不支持STP協議，如果這些設備和交換機連接，建議在交換機的端口上執行命令stp edged-port enable 開啟邊緣端口屬性或執行命令stp disable去使能STP。
否則，當用戶插拔鏈路連接介質，或先執行shutdown，再執行undo shutdown，重啟端口後，因對端端口不會發送STP的協議報文進行協商，導致交換機上的端口經過2倍的Forward Delay（默認為15秒）時間後才能正常轉發報文。
步驟2：檢查端口是否工作在STP模式
全局配置為RSTP/MSTP模式的設備，當端口接收到STP模式報文後，端口可以自動遷移到STP模式下工作。
通過命令display stp interface查看端口實際的工作模式（查看Port STP Mode字段哦）：
由於STP模式不能提供快速遷移機制，端口狀態變化後，需要等待2倍的Forward Delay（默認15秒）才能遷移到轉發狀態。
可以通過在交換機端口配置stp no-agreement-check命令來避免端口連接的上游設備模式為RSTP或者與MSTP實現存在私有性差異的廠商設備時，上游橋設備不能快速遷移問題。
當端口自動遷移到STP兼容工作模式後，以下情況端口無法自動遷移回原來的RSTP/MSTP模式，導致與其他運行RSTP/MSTP模式的設備無法互通。
· 運行STP模式的設備已關機或移走；
· 運行STP模式的設備修改為運行RSTP/MSTP模式。
因此需要在端口上執行stp mcheck命令，將端口手動遷移到RSTP/MSTP模式。
步驟3：檢查端口鏈路類型是否為點對點
RSTP/MSTP模式提供了端口快速遷移機制：當兩端均使能STP而且鏈路類型為點對點時，才能實現端口狀態的快速遷移。
可以通過stp point-to-point { auto | force-false | force-true }命令配置鏈路類型，端口的鏈路類型默認為auto，即由RSTP/MSTP來檢測與端口相連的鏈路是否是點對點鏈路，兩端均工作在全雙工模式是才可能成為點對點鏈路。
通過display stp interface查看端口的鏈路類型：
Config=auto表示使用stp point-to-point命令配置的值為auto，Active=true表示當前工作在點對點鏈路類型。
步驟4：如果以上步驟還不能解決問題，小夥伴們莫急，可以收集相關信息聯繫華為工程師處理。
小貼士
在這裡提醒下小夥伴們，在使能STP之前，別忘了檢查參與STP計算的端口是否使能了bpdu enable命令。具體的請參見下面的表格。
另外，小夥伴們需要關注這種場景：因為中間設備或者傳輸的問題導致STP報文不能透傳，這個可以通過display stp interface interface-type interface-number命令判斷，查看BPDU Received計數。如果計數一直為零或者沒有增加，則有可能是中間設備或者傳輸導致收不到STP報文。
故障現象2：使能STP的網絡中，流量業務時斷時續，設備CPU佔用率高
定位思路
同樣滴，小編給大家總結了如下的定位思路：
1) 端口是否持續收到TC報文；
2) 端口是否收到多種STP報文；
3) 設備是否存在報文攻擊。
定位步驟
具體的定位步驟，請小夥伴們繼續往下瞅：
步驟1：端口是否持續收到TC報文
執行命令display cpu-usage查看設備整機或接口板上佔用CPU較高的任務，如果交換機接口板的PPI任務（適配層任務，維護芯片中各個接口的狀態）CPU使用率較高，則排查端口是否持續收到大量TC報文。如果CPU利用率較高的任務中沒有PPI任務，則按照步驟3進行處理。
通過如下命令行可查看端口收、發TC報文的情況：
· display stp tc-bpdu statistics：該命令從框式V100R006版本，盒式V100R005版本開始支持。
· display stp topology-change: 該命令從框式V100R006版本，盒式V100R005版本開始支持。
如果通過以上排查，確認端口持續收到大量TC報文，小夥伴們可以通過使用stp tc-protection命令，使能交換機對TC報文的保護功能，實現對TC報文的限制，以達到對設備進行保護的目的。另外，還可以通過stp tc-protection threshold命令指定Hello Time時間內處理TC類型STP報文的次數。
在收到TC報文轉發刷新轉發表項時，STP的收斂方式不同，交換機對ARP表項的處理方式不同，建議配置為normal：
· 如果STP的收斂方式配置為fast，交換機將ARP表中的相關表項直接刪除。
· 如果STP的收斂方式配置為normal，交換機將ARP表中相關表項的剩餘存活時間置為0，對這些表項進行老化處理。
如果使能TC保護、修改STP收斂方式後，PPI任務的CPU利用率仍然較高，小夥伴們莫著急，請繼續按照步驟2進行處理。
步驟2：端口是否收到多種STP報文
可以通過display stp history命令查看端口角色計算的歷史記錄，如果端口的角色不斷更新，表明端口收到來自不同設備的報文，說明組網存在問題：
同時，打開以下STP debug開關，採集故障期間交互的STP報文和事件信息，排除非法的STP報文。
步驟3設備是否存在報文攻擊
網絡中出現鏈路故障或報文攻擊，可能導致端口長時間接收不到對端發送的STP協議報文，發生STP切換狀態，例如會產生如下日誌：
Jul 26 2012 02:26:40 Switch %%01MSTP/6/SET_PORT_DISCARDING(l):In MSTP process 0 instance 0, MSTP set port GigabitEthernet4/0/10 state as discarding.
Jul 26 2012 02:26:43 Switch %%01MSTP/6/SET_PORT_FORWARDING(l):In MSTP process 0 instance 0, MSTP set port GigabitEthernet4/0/10 state as forwarding.
IFNET/4/LINK_STATE:The line protocol [line-protocol] on the interface [interface-name] has entered the [state] state.
如果鏈路正常，通過display stp interface interface-type interface-number查看BPDU Received計數。
如果計數沒有周期增長，且端口下BPDU配置正確，則在端口入方向綁定流策略對STP報文進行流量統計，以確認對端設備是否週期發送了STP協議報文。配置和查看方法如下：
· 配置流策略：
· 查看流量統計：
· 如果通過流量統計查看到STP報文計數在週期增加，但使用命令display stp interface interface-type interface-number查看BPDU Received計數沒有增加，那麼需要再使用命令display cpu-defend statistics all查看是否有其他大量報文在上送CPU處理。
小貼士
小夥伴們注意啦：在不同形態、不同版本的交換機上，使用
display cpu-defend statistics all命令查看到的報文類型可能不同哦。· 交換機通過CPCAR機制對上送控制平面的報文進行業務細化，分別進行限速與隊列調度，以保護控制平面的安全。如果某些協議報文已經超過CPCAR的閾值出現丟包，通過命令display cpu-defend configuration all查看這些協議報文所在的隊列是否與STP報文在同一隊列：
閱讀更多 網由之路 的文章
