生成树协议的不足:api
端口从阻塞到转发必须经历30s延时
网络
快速生成树 802.1wide
具有STP全部功能,收敛时间 小于1s
spa
与802.1d兼容,可是兼容后 收敛时间仍是30s
3d
特色:blog
1,新拓扑中的根端口能够马上进入转发状态,节省两个延时。(须要同步,来防止环路)
接口
2,在点到点链路上,指定端口能够经过与相连的网桥进行一次握手,快速进入转发状态。
图片
链路类型,分为了: P2P (全双工 延时<1s)
get
: shared (链接了hub等 延时仍是30s)
同步
注意 :握手必须在点到点链路上。
一次握手后,相应握手的网桥的非边缘指定端口将变为blocking 状态,则须要向本身 的邻居网桥发起握手--即握手扩散
3,网络边缘的端口,即直接与终端相连,而不是和其余网桥相连的端口
能够直接进入转发状态,不须要任何延时。与portfast等同
配置:
接口下
spanning-tree portfast
端口状态:
discarding(丢弃)
learning
forwarding
RSTP BPDU flag
配置 全局下
spanning-tree mode rapid-pvst
sho spann vlan 1
同步:
最初A与root之间是断开的,当连通后,A上的接口变为RP,会立刻forward,可是root上的指定端口不会立刻转发数据,而是会向A发送proposal置位的报文给A,要等A同步后才回复root agreement;
A的同步,就是要block掉本地全部除了边缘接口之外的全部接口,而后回复root,而后root才开始向A转发;而此时A的P3口由于以前的同步被block了,等A和root收敛后,p3成为指定端口,也会发送proposal给B,等B同步,回复agreement给A,
当交换机收到BPDU以前,变为指定端口后,会block本地除了边缘接口之外的其余全部接口,直到发送的proposal收到回复。
若是proposal一直收不到回复,就会等待30s延时,再转发。
RSTP拓扑发生变化
每一个交换机都会发送TCN,MAC表会立刻老化
STP 和 RSTP
802.1d 只有 根 发BPDU,其余非根只是转发BPDU (2s刷新,20s老化)
802.1w 全部交换机都会发 BPDU,不用转发。
当链路断开后,除了像802.1d同样,本段链路接口down会立刻知道或者等待老化20s,
还能够等待3个BPDU(6s)就知道链路故障