RSTP快速生成树协议笔记之(二):端口角色和端口状态的改进
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配置实例与抓包分析