1.標準STP收斂
1.1 端口角色變遷
（1）RP放棄當前端口角色
①成爲non-DP
此時直接進入Blocking狀態，並不用等待
②成爲DP
此時端口狀態將保持forwarding，並不用等待
（2）DP放棄當前端口角色
與RP放棄端口角色時相同
（3）non-DP決定成爲RP或DP
此時將從Blocking狀態進入Listening，在2個Forward Delay之後進入forwarding
1.2 收到Inferior BPDU
（1）DP收到Inferior BPDU
觸發發送BPDU，同步下游設備
（2）RP收到Inferior BPDU
忽略
（3）non-DP收到Inferior BPDU
忽略
實際上，當RP或non-DP收到來自指定橋的InferiorBPDU時，是發生間接鏈路故障的信號，但標準STP對其置之不理（除非開啓BackboneFast）
可見：
標準STP收斂慢的根本原因在於
①端口狀態轉換是依賴計時器的
②Blocking狀態端口欲成爲RP或DP時需要等待收斂
③不能及時發現網絡拓撲的變化（除非配置Cisco增強特性）
2.RSTP快速收斂
2.1 針對情況
RSTP針對STP中會造成緩慢收斂的地方進行了優化，而原本STP能夠實現快速收斂的地方並未做改動
如上圖所示，原先網絡中SW1爲根橋，如果此時修改優先級而導致SW3成爲了新的根橋，則在RSTP中的收斂過程與STP中將完全一致
①SW3成爲根橋，fa0/2放棄RP角色，成爲DP，端口狀態維持forwarding
SW3發送BPDU，同步其它設備
②SW2的fa0/3收到superior BPDU，重新進行STP選舉，fa0/3放棄DP成爲RP，端口狀態維持forwarding
fa0/1放棄RP，成爲DP，端口狀態維持forwarding
SW2向下遊發送BPDU
③SW1收到superior BPDU，重新進行STP選舉，fa0/2放棄DP成爲RP，端口狀態維持forwarding
以上收斂在瞬間即可完成
2.2 限制
Link Type必須爲point-to-point，否則將無法實現快速收斂特性
如果Link Type爲shared，則在RSTP看來拓撲是類似於上圖所示，超過2臺參與RSTP的交換機接入在同一segment中
由於RSTP的proposal/agreement在設計時是針對兩臺設備間的，因此在BPDU中無法指明propose或者agree的對象，在多臺設備接入時，將會導致混亂
2.3 實現機制
Proposal/Agreement、Synchronization
3.RSTP端口變化概述
3.1 Discarding端口決定成爲RP
（1）概述
在STP中，阻塞端口欲成爲RP，則需要經過至少30 s的收斂時間，而RSTP中，端口決定成爲RP時，可以直接進入Forwarding狀態
導致Discarding端口決定成爲RP共有三種可能：
①本地通過修改相關參數導致RP改變
②RP失效或發生直接鏈路故障
③Discarding端口收到BPDU導致RP改變
（2）本地修改參數
此時，端口確定成爲RP後，直接進入Forwarding狀態，並且開啓同步機制
（3）RP失效或發生直接鏈路故障
Altn Port成爲RP，直接進入Forwarding狀態，並且開啓同步機制
（4）收到BPDU而導致RP改變
此時端口同樣直接進入Forwarding狀態，但是對於同步機制是否開啓有如下判斷
①如果該BPDU開啓proposal bit，則本地在RP確定後開啓同步機制
②如果BPDU未開啓proposal bit，則本地不會開啓同步機制
3.2 Discarding端口決定成爲DP
在RSTP中，爲了加快收斂，引入了Proposal/Agreement機制，此時DP並不立即進入Forwarding狀態，而是與鄰居進行協商，協商通過則立即進入Forwarding
注意：
如果端口狀態放棄RP而成爲DP，此時發送的BPDU中不會開啓proposal bit
4.Synchronization
4.1 爲何需要同步機制
對於生成樹而言，確定DP是防止環路產生的關鍵，同步機制通過阻塞所有期望成爲DP的端口，防止網絡拓撲發生改變時，可能導致的環路
4.2 何時進行同步
①收到BPDU with proposal而產生新的RP，且本地存在non-edge DP
②本地通過修改STP相關參數而導致RP發生改變，且存在non-edgeDP
③RP收到BPDU with proposal，且同意該上游端口爲DP
④發生間接鏈路故障時，Altn Port成爲新的RP
注意：
如果收到的BPDU中未開啓proposal，而由此產生了新的RP，此時是不會開啓同步機制的
產生新的DP時（例如收到BPDU後，本地Altn Port被選舉爲DP）不會開啓同步機制
DP收到BDPU withproposal，且同意的話，該端口狀態將直接被置爲Discarding，不會開啓同步機制
4.3 如何進行同步
阻塞所有non-edge DP
5.Proposal/Agreement
5.1 如何體現
在BPDU的flags中，有2個bits分別用於表示proposal以及agreement
5.2 何時開啓proposal
Discarding狀態端口決定成爲DP，由此可見，發送BPDUwith proposal的端口期望能成爲DP
5.3 接收設備如何處理
（1）Altn Port收到BPDU withproposal
①認同
無響應，Altn Port並不會發送BPDU with agreement
②不認同
a.Altn Port是segment中最優的，因此決定成爲DP，發送BPDU with proposal
b.是一個來自指定橋的InferiorBPDU，發生間接鏈路故障
（2）RP收到BPDU withproposal
①認同
a.確定當前交換機上各個端口的角色
b.開啓同步機制，阻塞所有non-edgeDP
c.確定各個端口的狀態——此時如果是新產生RP，該RP將直接進入Forwarding
d.RP發送BPDU withagreement
e.所有non-edge DP向下遊發送BPDU witch proposal
②不認同
a.是一個來自指定橋的InferiorBPDU，發生間接鏈路故障
注意：
Discarding端口如果期望成爲RP，則將直接進入forwarding狀態
6.Indirection Failure in RSTP
6.1 何時發生間接鏈路故障
與STP開啓BackboneFast時相同，當RP、Discarding端口收到Inferior BPDU時，說明出現了間接鏈路故障
6.2 故障處理
（1）RP收到Inferior BPDU
Inferior BPDU rcv on RP from DesignatedBridge
Indirection failure has happened //the old local RP has lostconnection to RootBridge
if(there is AltnPort)
Best BPDU rcv on AltnPort //local device can reach RootBridge from the AltnPort
AltnPort bdecomes the new RP
the elder RP will become DP //此前的指定橋由於失去了到根橋的連接，此時反而成爲了當前設備看來的下游設備，原RP變成DP，向其提供到根橋的連接
run synchronization
else if(there is no AltnPort)
elect new RootBridge //the local device has lostconnection to RootBridge
（2）Discarding端口收到InferiorBPDU
①Discarding端口決定成爲DP
then
②發送BPDU with proposal bit
注意：
不像RP收到Inferior BPDU那樣還要等待Discarding端口收到Best BPDU，由於當前設備存在RP，此時認爲到根橋的連接完好
（3）DP收到Inferior BPDU
相比於STP觸發發送BPDU，RSTP中DP收到Inferior BPDU時將會對其忽略
7.案例
7.1 出現新的DP、RP
如圖所示，所有STP相關參數（除了cost）均爲默認值，System ID與設備編號一致，SW1的System ID最小，各個端口cost爲10
因此，當生成樹網絡收斂完畢後，SW1成爲根橋；SW2的fa0/1爲RP，fa0/3爲DP；SW3的fa0/1爲RP，fa0/2爲Altn Port，fa0/4爲DP……
（1）修改SW2橋優先級
此時如果增大SW2的Bridge Priority，將導致在SW2與SW3所在的segment內，SW2的fa0/3變成Altn Port，SW3的fa0/2成爲DP
①由於優先級值增大，SW2 BID依然劣於當前的Root ID，因此交換機角色並不會改變，端口狀態同樣不變
②SW3收到SW2發送的BPDU，當前的Discarding端口決定成爲DP，發送BPDU withproposal
注意：
此時SW3上並不會出現同步現象，即fa0/4並不會被阻塞
③SW2收到BPDU witch proposal bit，由於該BPDU更優，因此DP將放棄該端口角色，而成爲Altn Port，端口立即被阻塞，完成收斂
注意：
SW2的fa0/3由於立即被阻塞，不會發送BPDU with agreement
④SW3的fa0/2在經過2個Forward Delay之後，才完成收斂
（2）SW2將橋優先級改回默認值
①SW2在修改優先級後，由於之前fa0/3是下游端口，保留有BestBPDU，此時可以直接通過比較發現SW2在該segment內更優，因此Discarding端口在收到SW3的BPDU之前就已經決定成爲DP，並且發送BPDU withproposal
②SW3收到BPDU，由於該BPDU更優，因此本地直接將端口阻塞，收斂完畢（同樣不會發送BPDU withagreement）
③SW2的fa0/3在2個Forward Delay之後，完成收斂
（3）SW2將fa0/1的cost修改爲1
在SW2與SW3之間，SW2通告的BPDU的Root Path Cost變小，但是由於SW2已經是指定橋了，因此端口角色、狀態都不會變化
（4）SW3將fa0/2的cost修改爲1
此時在SW3上產生了一條距離根橋更近的路徑，fa0/2將成爲RP，而fa0/1將變成Altn Port
①SW3上，RP發生了改變，STP確定各個端口的角色，fa0/2爲RP，fa0/1爲Altn Port，fa0/3爲DP
②SW3開啓同步機制，fa0/3被阻塞
③SW3確定各個端口的狀態，fa0/2直接進入Forwarding，fa0/1爲Blocking，fa0/3由於期望成爲DP，發送BPDU with proposal
④SW4收到BPDU with proposal後，由於接收端口是RP，因此響應BPDU withagreement
⑤SW3收到BPDU with agreement，確定DP端口狀態爲Forwarding
7.2 出現新根橋
如上圖所示，當生成樹拓撲發生改變時，STP與RSTP的應對策略將有所不同：
SW4通過修改橋優先級，成爲新的根橋
STP收斂步驟 | RSTP收斂步驟 |
SW4： ①SW4的BID參數優於當前RID，成爲新的根橋 ②SW4所有端口將成爲DP 因此fa0/2直接由RP轉到DP fa0/3由Blocking轉爲Listening ③SW4的所有端口在2xForward Delay後達到穩定 SW3： ①SW3收到SW4的BPDU，原先根橋被抑制 ②fa0/4成爲新的RP，端口狀態依然爲forwarding ③fa0/1以及fa0/2都有成爲DP的潛力，因而 fa0/2進入listening狀態 fa0/1由RP變爲DP，維持forwarding ④fa0/2收到來自SW2的BPDU，選舉後，將fa0/2阻塞 ⑤fa0/1在選舉中勝出，維持forwarding ⑥SW3的所有端口在fa0/2被阻塞後達到穩定 SW2： ①收到SW4的BPDU，原先根橋被抑制 ②fa0/4成爲新的RP，端口狀態依然爲forwarding ③fa0/1以及fa0/3都有成爲DP的潛力，因而 fa0/1又RP變爲DP，維持forwarding fa0/3維持forwarding ④SW2的所有端口在收到SW4的BPDU後即可達到穩定 SW1： ①收到來自上游的BPDU，根橋發生改變 ②根據接收到的BPDU，fa0/2由DP轉爲RP，維持forwarding ③fa0/3在選舉中失敗，被阻塞 ④SW1的所有端口在收到來自SW2、SW3的BPDU 並確定端口角色後達到穩定 整個STP網絡在30 s後完成收斂 限制因素在於SW4的fa0/3不得不從listening開始收斂 | SW4： ①SW4的BID參數優於當前RID，成爲新的根橋 ②SW4所有端口將成爲DP fa0/2直接由RP轉到DP fa0/3由於之前處於discarding狀態 fa0/3發送的BPDU中開啓proposal bit ③SW4的所有端口在fa0/3收到agreement後達到穩定 SW3： ①SW3的fa0/4收到BPDU，原先根橋被抑制， ②fa0/4成爲新的RP，端口狀態依然爲forwarding ③開啓同步機制，阻塞將成爲DP的fa0/1 fa0/2由於原本就處於discarding狀態，因此維持阻塞 ④同步完畢，從fa0/4發送BPDU，開啓agreement bit 以上過程由於不受計時器限制，因此實際執行時速度很快 ⑤fa0/2以及fa0/1發送的BPDU中，開啓proposal bit ⑥由於SW2沒有開啓同步機制，因此其DP無需agreement SW2發給SW3的BPDU中並不開啓proposal SW2由於收到superior BPDU，將fa0/3阻塞 ⑦由於SW1處發生了狀況，此時SW3的fa0/1一直收不到agreement 經過2xForward Delay後進入forwarding ⑧SW3上的所有端口在fa0/1收斂完畢後達到穩定 SW2： ①收到SW4的BPDU，原先根橋被抑制 由於SW4的fa0/2的BPDU不帶有proposal 同步機制不會被開啓 ②SW2根據BPDU，fa0/4成爲新的RP，其它端口均爲DP fa0/1、fa0/3維持forwarding狀態 ③SW2的所有端口在收到SW4的BPDU後即可達到穩定 SW1： ①SW1首先收到來自SW3的BPDU 原先根橋被抑制 ②fa0/3將成爲RP，由於BPDU中帶有proposal bit SW1開啓同步機制 fa0/2被阻塞 ③fa0/2收到來自SW2的BPDU，其中proposal bit沒有開啓 ④由於fa0/2收到的BPDU更優，RP發生改變 fa0/3由於已經收到了來自SW3的BPDU 此時該端口不再認爲自己將成爲DP 又由於proposal bit沒有開啓，因此fa0/3不會進行同步 fa0/3處於discarding狀態，且不會向上遊發送agreement ⑤SW1的所有端口在收到來自SW2的BPDU後達到穩定 整個STP網絡在30 s後完成收斂 限制因素在於SW3的fa0/1不得不等待2個Forward Delay |
可見：
RSTP的收斂速度並不總快於STP
本例中導致RSTP收斂需要30 s，主要是因爲proposal/agreement機制與STP標準收斂同時進行