RSTP快速生成樹協議筆記之(二)
端口角色和端口狀態的改進
上一節筆記大致講述了正是因為STP協議的是采用被動等待計時器超時的方式來判斷已收集全網所有的BPDU，使得STP在拓撲收斂時浪費了大量的時間在不必要的等待上。這一節我們繼續闡述STP端口角色與端口狀態的不足，並開始探討RSTP協議是如何改進這些不足的。
STP端口角色的不足與RSTP的重新划分
我們知道，一台非根交換機（下圖中的SWC）的根端口（RP）down掉后，需要從其他三個端口中重新選舉且需等待計時器超時（30秒）后才能進入轉發。若是在一個對延時和丟包率要求特別高的網絡中，等待30秒的連接中斷時間簡直是致命的。
RSTP定義了兩種新的端口角色：備份端口（Backup Port）和預備端口（Alternate Port）。
根據STP的不足，RSTP新增加了兩種端口角色，並且把端口屬性充分地按照狀態和角色解耦，使得可以更加精確地描述端口，從而使得協議狀態更加簡便，同時也加快了拓撲收斂。通過端口角色的增補，簡化了生成樹協議的理解及部署。
那么我們應該怎樣理解這兩個新的端口角色呢？
從配置BPDU報文發送的角度來看：
Alternate Port就是由於學習到其它網橋發送的配置BPDU報文而阻塞的端口。
Backup Port就是由於學習到自己發送的配置BPDU報文而阻塞的端口。
從用戶流量角度來看：
Alternate Port作為根端口的備份端口，提供了從指定橋到根的另一條可切換路徑。
Backup Port作為指定端口的備份，提供了另外一條從根節點到葉節點的備份通路。
STP端口狀態的不足和RSTP的改進
下圖為STP的五種端口狀態，詳細描述已經在前面筆記中提到。
| STP端口狀態 |
端口狀態對應的行為 |
| Disabled |
不轉發用戶流量也不學習MAC地址
|
| Blocking |
|
| Listening |
|
| Learning |
不轉發用戶流量但是學習MAC地址 |
| Forwarding |
既轉發用戶流量又學習MAC地址 |
表1.1 STP端口狀態
從表1.1可以看出，Disabled，Blocking，Listening三種端口狀態從用戶使用的角度對應的行為都是相同的，即他們都是既不轉發用戶流量，也不學習MAC地址，但卻呈現出不同的狀態，這樣反而增加了使用難度。那么，可不可以將這三種狀態整合成一種狀態呢？
RSTP的狀態規范把原來的5種狀態縮減為3種。
| STP端口狀態 |
RSTP端口狀態 |
端口狀態對應的行為 |
| Disabled |
Discarding |
如果不轉發用戶流量也不學習MAC地址，那么端口狀態就是Discarding狀態。
|
| Blocking |
||
| Listening |
||
| Learning |
Learning |
如果不轉發用戶流量但是學習MAC地址，那么端口狀態就是Learning狀態。 |
| Forwarding |
Forwarding |
如果既轉發用戶流量又學習MAC地址，那么端口狀態就是Forwarding狀態。 |
表1.2 RSTP端口狀態與STP的比較
從用戶角度來講，Listening、Learning和Blocking狀態並沒有區別，都同樣不轉發用戶流量。所以RSTP將這三種狀態整合成了Discarding狀態，如果不轉發用戶流量也不學習MAC地址，統一都叫Discarding。
以上就是RSTP協議中對端口角色和端口狀態改進的介紹，下一節筆記會開始探討RSTP協議是如何解決《RSTP快速生成樹協議之(一)》中，STP遺留下來的問題的，其中涉及P/A機制，根端口快速切換機制，次等BPDU處理機制，以及邊緣端口的引入等知識。
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配置實例與抓包分析