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配置实例与抓包分析