RSTP快速生成樹協議之（一）STP協議的不足
STP協議的不足
STP協議雖然能夠解決環路問題，但是由於網絡拓撲收斂較慢，影響了用戶通信質量，而且如果網絡中的拓撲結構頻繁變化，網絡也會隨之頻繁失去連通性，從而導致用戶通信頻繁中斷，這也是用戶無法忍受的。
由於STP的不足，IEEE於2001年發布的802.1w標准定義了RSTP。RSTP在STP基礎上進行了諸多改進優化，使得協議更加清晰、規范，同時也實現了二層網絡拓撲的快速收斂。那STP協議具體存在哪些不足呢？RSTP協議是如何在STP協議的基礎上進行優化的呢？本節筆記主要着重講述STP協議中都帶來了哪些不足。
注：下面的拓撲圖中，如無特意標注，DP代表指定端口，RP代表根端口，BP代表阻塞端口（Block Port）或備份端口（Backup Port）。由於BP可能有兩種釋義，所以會在下文中特地注明是哪種端口。
問題一：設備運行STP初始化環境收斂時間長
STP從初始狀態到完全收斂至少需經過30s。
在前面的隨筆中介紹的STP協議介紹時也有提到，STP算法是采用被動等待計時器超時的方式來判斷已收集全網所有的BPDU，進而再進行計算。
①在STP運行的初始時間點，交換機之間會相互發送，監聽BPDU，並計算生成樹，其中端口狀態會先從Discarding到Listening。
②STP為避免臨時環路，必須等待足夠長的時間（即確保BPDU能同步發送至全網各節點）確保全網的端口狀態全部確定，才能進入轉發。此時端口狀態從Listening到Learning，大約需要15秒的時間。
③在STP進入轉發前還需根據收到的用戶流量構建MAC地址表，仍需等待計時器超時才能進入轉發。此時端口狀態從Learning到Forwarding，大約需要15秒的時間。
所以端口要從阻塞到轉發，從Discarding到Forwarding，是需要總共經歷30秒的時間，才能完成收斂。
問題二：交換機有BP端口，RP端口down的場景
直連鏈路down掉，其BP端口切換成RP端口並進入轉發狀態至少需要經過30秒。
當SWC檢測到其與根橋失去連接，根端口（RP）down的時候，它會將自己的阻塞端口（BP）重新選舉為根端口。為確保拓撲變化信息已經擴散到全網，且所有設備都已完成拓撲更新，故SWC的新的根端口還需等待計時器超時后才能進入轉發。
SWC要將阻塞端口變成新的根端口，從開始的blocking（阻塞）狀態，並經過2個Forward Delay時間（30秒）才進入轉發狀態。
問題三：交換機無BP端口，RP端口down的場景
SWB與SWA的直連鏈路down掉，則SWC的BP端口切換成DP端口並進入轉發狀態大約需要50秒。
由上圖，SWB檢測到其與根橋連接的根端口（RP）失效，其運作方式如下：
①SWB會以自己為根橋開始向SWC的阻塞端口（Blocked Port）發送配置BPDU。
②SWC還可以通過根端口（RP）收到根橋的BPDU ，而阻塞端口（BP）收到BPDU則不會作處理，因為此時SWB發來的BPDU是次優的（SWB的優先級比SWA低）。在STP中，交換機除指定端口外的其他端口收到次優BPDU都不會做處理。
③一開始沒有發生故障時，SWC的阻塞端口（BP）會定期收到關於根橋的BPDU，而等待了BPDU的老化時間（Max Age），端口緩存的BPDU超時后（大約需要20秒的時間）后，這個阻塞端口（BP）才會開始重新進行收斂。
④重新進行收斂，端口還要等待並經過2個Forward Delay時間（30秒）才進入轉發狀態。
綜上所述，從產生故障到拓撲收斂，總共至少需要50秒的時間。
問題四：運行STP的交換機連接用戶終端的場景
交換機連接終端的鏈路進入轉發需要經過30s。
STP中，連接終端的鏈路也要進行生成樹計算，且鏈路進入轉發需等待2個Forward Delay時間（30秒）。而事實上，只要保證該端口下連接的是終端設備就不會出現環路，即沒有必要進行STP計算和等待計時器超時
問題五：STP的拓撲變更機制
在之前的STP筆記中也有提到，當局域網中某台交換機突然感應到拓撲發生了更改，會想上游交換機發送TCN BPDU報文，當時給出的例子只有三台交換機，那么如果是多台交換機的情況下，STP協議又是怎么應對的呢？
拓撲變更處理過程：
①在網絡拓撲發生變化后，下游設備會不間斷地向上游設備發送TCN BPDU報文。
②上游設備收到下游設備發來的TCN BPDU報文后，只有指定端口處理TCN BPDU報文。其它端口也有可能收到TCN BPDU報文，但不會處理。
③上游設備會把配置BPDU報文中的Flags的TCA位設置1，然后發送給下游設備，告知下游設備停止發送TCN BPDU報文。
④上游設備復制一份TCN BPDU報文，向根橋方向發送。
⑤重復上述步驟，直到根橋收到TCN BPDU報文。
⑥根橋把配置BPDU報文中的Flags的TC位置1后發送，通知下游設備直接刪除橋MAC地址表項。
可以看出，當發生拓撲變更時，STP需要逐層將TCN BPDU發送到根橋，並向下游回復TCA消息，最后再由根橋向下發送TC消息，通知設備刪除MAC地址表項，在交換網絡設備數量不斷增大的今天，STP的機制愈顯復雜，致使效率低下。
以上就是STP具有的問題，那么下一節將會繼續討論RSTP協議相對於STP協議來說，其用了什么方法來解決現有的問題，以及都作出了哪些改進。
RSTP快速生成樹協議筆記之(一)：STP協議的不足
https://www.cnblogs.com/zylSec/p/14651273.html
RSTP快速生成樹協議筆記之(二)：端口角色和端口狀態的改進
https://www.cnblogs.com/zylSec/p/14655908.html
RSTP快速生成樹協議之(三):RSTP對STP的改進以及數據包分析
https://www.cnblogs.com/zylSec/p/14665145.html
RSTP快速生成樹協議之(四)：RSTP的保護功能
https://www.cnblogs.com/zylSec/p/14672493.html
RSTP快速生成樹協議之(五)：RSTP配置實例與抓包分析