RSTP快速生成樹協議之（三）
RSTP對STP的改進以及數據包分析
在RSTP快速生成樹協議之（一）STP協議的不足中，已經列舉了STP協議中的各種弊端：初始化時間長；拓撲變更時收斂時間長，機制復雜；連接終端造成不必要的計算；以及端口角色和端口狀態的不足等。所以，本節筆記將會介紹RSTP對STP這些弊端的改進措施。
在討論RSTP對STP的改進前，可以先去了解一下之前的筆記，其中介紹了STP有哪些不足之處：
參考鏈接：https://www.cnblogs.com/zylSec/p/14651273.html
RST BPDU（RSTP的BPDU報文）
RSTP協議的BPDU格式和STP協議是相同的，但是報文參數略有不同。
（1）BPDU Type字段
RSTP使用了類似STP的BPDU報文，即RST BPDU報文。而報文中的BPDU Type字段則是用來區分不同STP協議的BPDU報文的。
STP協議的BPDU Type字段是0（0x00）時，代表這個報文是配置BPDU；當是128（0x80）時，代表這個報文是TCN BPDU（Topology Change Notification）；當是2（0x02）時，則代表是RSTP的RST BPDU報文。
Tips：BPDU Type是0x02時，不僅可能是RST BPDU（Rapid Spanning-Tree BPDU），還可能是MST BPDU（Multiple Spanning-Tree BPDU）。
（2）flags字段
在STP協議中，BPDU的報文中flags字段只定義了拓撲變化TC（Topology Change）和拓撲變化確認TCA（Topology Change Acknowledge），而其他字段是保留的。
而在RSTP的RST BPDU中，flags還使用了其他的字段，它把原來保留的中間6位都利用了起來。這新增的6位作用包括表示P/A進程，定義端口角色和端口狀態。這樣改變了配置BPDU的叫RST BPDU。
以下是flags字段中各bit所代表的含義：
TCA（第7 bit，高位）： 拓撲改變響應位，STP筆記中有提及，不再贅述
Agreement（第6 bit）： P/A進程的A置位。詳細用途會在下面講P/A機制時再進行探討
Forwarding（第5 bit）： 為真時表示端口的狀態是Forwarding，此時端口處於既轉發用戶流量又學習MAC地址的狀態。
Learning（第4 bit）： 為真時表示端口的狀態是Learning，此時端口處於學習MAC地址，但不轉發用戶流量的狀態。
Flags（第3和2 bit）： 表示端口角色（Port Role），因為占2個比特，可以表示4種不同的端口角色。
Proposal：（第1 bit）： P/A進程的P置位，詳細用途會在下面講P/A機制時再進行探討。
TC（第0 bit，低位）： 拓撲改變位，STP筆記中有提及，不再贅述。
Tips：端口角色（Port Role）不同取值的不同含義
Port Role = 00 時，為Unkown未定義
Port Role = 01 時，為Alternate Port 預備端口 /Backup Port 備份端口
Port Role = 10 時，為Root Port根端口
Port Role = 11 時，為Designated Port指定端口
針對問題一的改進：P/A機制
我們知道，STP有初始化環境下收斂時間長的問題，為了改進這個問題，RSTP提出了P/A機制。
（1）P/A機制的基本原理
P/A機制，即Proposal/Agreement機制，中文對應是提議/同意機制。它的目的是使一個指定端口盡快的進入到Forwarding狀態中。
P/A機制要求兩台交換設備之間鏈路必須是點對點的全雙工模式。一旦P/A協商不成功，指定端口的選舉就會回到STP的協商方式，就需要等待兩個Forward Delay（30秒）時間。
相對於STP來說，P/A帶來了來回確認機制和同步變量機制，而不再需要等待計時器超時來保障無環路。
（2）P/A機制的具體工作過程
通過P/A機制，RSTP是這樣加快拓撲收斂的速度的。如下圖所示，局域網內有三台剛開啟的運行RSTP協議的交換機：
階段一：
由於設備剛啟動，與STP一樣，所有交換機都會認為自己是根橋。不同的是，此時交換機會向其他交換機發送P置位（即Flags中的Proposal位置為1）的BPDU報文（以下將這種報文簡稱為P消息），這個BPDU報文包含了該交換機的配置信息；並把發送P消息的端口變成指定端口（DP口），同時端口狀態處在Discarding狀態。如上圖所示。
階段二：
由於SWA的橋優先級是最高的，所以SWA不會對SWB或SWC發來的BPDU做出反應，而是繼續發送自己的P消息。
SWB和SWC收到SWA發送過來的P消息，對比橋優先級后一致認為SWA才是根橋，此時他們就會根據P/A機制協商流程向SWA回復A置位（即Flags中的Agreement位置為1）的BPDU（以下將這種消息簡稱為A消息）。並把自己的發送端口改為根端口（RP），同時端口處於Forwarding狀態，可以進行數據轉發。
階段三：
此時SWB與SWA，SWC與SWA的P/A協商基本完成，接下來就是SWB和SWC之間的P/A協商。以下是協商的過程：
Step 1：SWB和SWC都會發送根橋為SWA的P消息給對方。
Step 2：SWC收到SWB的P消息后，發現P消息里雖然根橋和自己認可的一樣，但是發送者的橋優先級比自己高(SWB>SWC)，所以會馬上停止發送P消息，但是由於已經有端口是根端口（RP），也不會回A消息。
Step 3：SWB收到SWC的P消息后，發現P消息里雖然根橋和自己認可的一樣，但是發送者的橋優先級比自己低(SWB>SWC)，所以會繼續不停地發送P消息。
Step 4：以上狀態在等待2個Forward Delay（30秒）時間后，SWB的橋優先級比較高，所以SWB的端口為指定端口（DP），處於Forwarding狀態；SWC的橋優先級比較低，所以SWC的端口為預備端口（AP），處於Discarding狀態。
實際上SWB與SWC之間的協商等同於退回到STP的模式，但是反正是Discarding狀態，根本不影響其他業務轉發。
Tips：以上就是RSTP使用P/A機制進行選舉端口角色的過程。可以看出，其原理從本質上還是和STP協議是相同的。流程都可以總結如下：
選舉根橋（根交換機）=》 選舉根端口 =》選舉指定端口 =》選舉預備端口和備份端口
RSTP在這個流程的基礎上，加入了“發起提議-同意回復”（P/A機制）這種確認機制，正是因為在每個步驟有確認機制的接入，就再不需要依賴計時器來保證網絡拓撲無環才去轉發，只需要考慮BPDU發送報文並計算無環拓撲的時間（一般都是秒級）。
針對問題二的改進：根端口快速切換機制
在STP協議中，如果一台非根交換機的根端口（RP）因故障原因突然down了，那么其阻塞端口（BP）則需要等待兩倍的Forward Delay（30秒）時間才能重新進入Forwarding（轉發）狀態。那么RSTP是如何解決這個問題的呢？
如圖所示：非根交換機SWC的根端口（RP）突然發生故障而down了。
RSTP定義中，作為到根橋的備份，其新增了端口角色：預備端口Alternate Port（以下簡稱AP）。為加快收斂時間，當設備上舊的根端口失效時，預備端口就可以在保證鏈路無環的情況下，從Discarding狀態立刻遷移到Forwarding狀態。
RSTP協議中，預備端口（AP）要切換成根端口（RP）並進入轉發狀態可以在秒級時間內完成收斂。這樣就可以解決STP收斂慢的問題。
針對問題三的改進：次等BPDU處理機制
在問題二中，我們討論的是當非根交換機的根端口down了，而另一個端口是預備端口時的情況，由於預備端口不參與轉發BPDU，所以交換機可以很快的將該端口切換成根端口。
那么如果另一個端口是指定端口（DP）的情況呢？
在STP協議中，由於對端交換機收到了次優的BPDU且不做處理，需要等計時器超時（20秒），交換機才會知道拓撲發生了變更。而想要重新選舉，還要等待兩倍的Forward Delay（30秒）的時間，才能讓拓撲收斂。那么，RSTP又是如何改進這個問題的呢？
如上圖所示：SWB與根橋SWA之間的鏈路發生故障，使得根端口down了，接下來RSTP協議的協商過程如下：
Step 1：SWB感應到自己的根端口發生故障，失去了與根橋的聯系。於是開始將自己作為根橋，向外發送Proposal置位的BPDU。
Step 2：SWC的預備端口（AP）收到次優BPDU后會馬上發送本地最優的BPDU給對端SWB，同時端口角色從預備端口（AP）變更為指定端口（DP）。
Step 3：SWB收到更優的BPDU，會立即重新定義端口角色，將原指定端口（DP）端口改為根端口（RP），然后發送Agreement置位的BPDU。
Step 4：SWC在收到Agreement置位的BPDU后會立即進入轉發狀態。
RSTP處理次等BPDU報文時，不再依賴於任何定時器超時解決拓撲收斂，而是會立即發送本地最優的BPDU給對端，從而加快了拓撲收斂。
針對問題四的改進：引入邊緣端口
在STP協議中，即使是連接終端的鏈路也都參與到拓撲收斂的計算中。但是只要確保終端設備不會出現環路，那么納入STP的計算和使用等待計時器超時的機制都是不必要的。
為此，RSTP引入了邊緣端口的概念。只要設置連接終端的端口為邊緣端口，那么交換機上的該對應鏈路可立即進入轉發狀態。
交換機上連接終端設備的接口設置成為邊緣端口后，不會參與STP的計算，而會立即進入轉發。
Tips：
但當該端口收到BPDU后，就喪失了邊緣端口屬性，成為普通STP端口，並重新進行生成樹計算。
RSTP中對STP的改進已經大致介紹了，但其實這只是淺顯的理解，RSTP的改進之處還遠遠不止這些。下一次的筆記會繼續介紹關於RSTP的保護功能。
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配置實例與抓包分析