1.标准STP收敛
1.1 端口角色变迁
（1）RP放弃当前端口角色
①成为non-DP
此时直接进入Blocking状态，并不用等待
②成为DP
此时端口状态将保持forwarding，并不用等待
（2）DP放弃当前端口角色
与RP放弃端口角色时相同
（3）non-DP决定成为RP或DP
此时将从Blocking状态进入Listening，在2个Forward Delay之后进入forwarding
1.2 收到Inferior BPDU
（1）DP收到Inferior BPDU
触发发送BPDU，同步下游设备
（2）RP收到Inferior BPDU
忽略
（3）non-DP收到Inferior BPDU
忽略
实际上，当RP或non-DP收到来自指定桥的InferiorBPDU时，是发生间接链路故障的信号，但标准STP对其置之不理（除非开启BackboneFast）
可见：
标准STP收敛慢的根本原因在于
①端口状态转换是依赖计时器的
②Blocking状态端口欲成为RP或DP时需要等待收敛
③不能及时发现网络拓扑的变化（除非配置Cisco增强特性）
2.RSTP快速收敛
2.1 针对情况
RSTP针对STP中会造成缓慢收敛的地方进行了优化，而原本STP能够实现快速收敛的地方并未做改动
如上图所示，原先网络中SW1为根桥，如果此时修改优先级而导致SW3成为了新的根桥，则在RSTP中的收敛过程与STP中将完全一致
①SW3成为根桥，fa0/2放弃RP角色，成为DP，端口状态维持forwarding
SW3发送BPDU，同步其它设备
②SW2的fa0/3收到superior BPDU，重新进行STP选举，fa0/3放弃DP成为RP，端口状态维持forwarding
fa0/1放弃RP，成为DP，端口状态维持forwarding
SW2向下游发送BPDU
③SW1收到superior BPDU，重新进行STP选举，fa0/2放弃DP成为RP，端口状态维持forwarding
以上收敛在瞬间即可完成
2.2 限制
Link Type必须为point-to-point，否则将无法实现快速收敛特性
如果Link Type为shared，则在RSTP看来拓扑是类似于上图所示，超过2台参与RSTP的交换机接入在同一segment中
由于RSTP的proposal/agreement在设计时是针对两台设备间的，因此在BPDU中无法指明propose或者agree的对象，在多台设备接入时，将会导致混乱
2.3 实现机制
Proposal/Agreement、Synchronization
3.RSTP端口变化概述
3.1 Discarding端口决定成为RP
（1）概述
在STP中，阻塞端口欲成为RP，则需要经过至少30 s的收敛时间，而RSTP中，端口决定成为RP时，可以直接进入Forwarding状态
导致Discarding端口决定成为RP共有三种可能：
①本地通过修改相关参数导致RP改变
②RP失效或发生直接链路故障
③Discarding端口收到BPDU导致RP改变
（2）本地修改参数
此时，端口确定成为RP后，直接进入Forwarding状态，并且开启同步机制
（3）RP失效或发生直接链路故障
Altn Port成为RP，直接进入Forwarding状态，并且开启同步机制
（4）收到BPDU而导致RP改变
此时端口同样直接进入Forwarding状态，但是对于同步机制是否开启有如下判断
①如果该BPDU开启proposal bit，则本地在RP确定后开启同步机制
②如果BPDU未开启proposal bit，则本地不会开启同步机制
3.2 Discarding端口决定成为DP
在RSTP中，为了加快收敛，引入了Proposal/Agreement机制，此时DP并不立即进入Forwarding状态，而是与邻居进行协商，协商通过则立即进入Forwarding
注意：
如果端口状态放弃RP而成为DP，此时发送的BPDU中不会开启proposal bit
4.Synchronization
4.1 为何需要同步机制
对于生成树而言，确定DP是防止环路产生的关键，同步机制通过阻塞所有期望成为DP的端口，防止网络拓扑发生改变时，可能导致的环路
4.2 何时进行同步
①收到BPDU with proposal而产生新的RP，且本地存在non-edge DP
②本地通过修改STP相关参数而导致RP发生改变，且存在non-edgeDP
③RP收到BPDU with proposal，且同意该上游端口为DP
④发生间接链路故障时，Altn Port成为新的RP
注意：
如果收到的BPDU中未开启proposal，而由此产生了新的RP，此时是不会开启同步机制的
产生新的DP时（例如收到BPDU后，本地Altn Port被选举为DP）不会开启同步机制
DP收到BDPU withproposal，且同意的话，该端口状态将直接被置为Discarding，不会开启同步机制
4.3 如何进行同步
阻塞所有non-edge DP
5.Proposal/Agreement
5.1 如何体现
在BPDU的flags中，有2个bits分别用于表示proposal以及agreement
5.2 何时开启proposal
Discarding状态端口决定成为DP，由此可见，发送BPDUwith proposal的端口期望能成为DP
5.3 接收设备如何处理
（1）Altn Port收到BPDU withproposal
①认同
无响应，Altn Port并不会发送BPDU with agreement
②不认同
a.Altn Port是segment中最优的，因此决定成为DP，发送BPDU with proposal
b.是一个来自指定桥的InferiorBPDU，发生间接链路故障
（2）RP收到BPDU withproposal
①认同
a.确定当前交换机上各个端口的角色
b.开启同步机制，阻塞所有non-edgeDP
c.确定各个端口的状态——此时如果是新产生RP，该RP将直接进入Forwarding
d.RP发送BPDU withagreement
e.所有non-edge DP向下游发送BPDU witch proposal
②不认同
a.是一个来自指定桥的InferiorBPDU，发生间接链路故障
注意：
Discarding端口如果期望成为RP，则将直接进入forwarding状态
6.Indirection Failure in RSTP
6.1 何时发生间接链路故障
与STP开启BackboneFast时相同，当RP、Discarding端口收到Inferior BPDU时，说明出现了间接链路故障
6.2 故障处理
（1）RP收到Inferior BPDU
Inferior BPDU rcv on RP from DesignatedBridge
Indirection failure has happened //the old local RP has lostconnection to RootBridge
if(there is AltnPort)
Best BPDU rcv on AltnPort //local device can reach RootBridge from the AltnPort
AltnPort bdecomes the new RP
the elder RP will become DP //此前的指定桥由于失去了到根桥的连接，此时反而成为了当前设备看来的下游设备，原RP变成DP，向其提供到根桥的连接
run synchronization
else if(there is no AltnPort)
elect new RootBridge //the local device has lostconnection to RootBridge
（2）Discarding端口收到InferiorBPDU
①Discarding端口决定成为DP
then
②发送BPDU with proposal bit
注意：
不像RP收到Inferior BPDU那样还要等待Discarding端口收到Best BPDU，由于当前设备存在RP，此时认为到根桥的连接完好
（3）DP收到Inferior BPDU
相比于STP触发发送BPDU，RSTP中DP收到Inferior BPDU时将会对其忽略
7.案例
7.1 出现新的DP、RP
如图所示，所有STP相关参数（除了cost）均为默认值，System ID与设备编号一致，SW1的System ID最小，各个端口cost为10
因此，当生成树网络收敛完毕后，SW1成为根桥；SW2的fa0/1为RP，fa0/3为DP；SW3的fa0/1为RP，fa0/2为Altn Port，fa0/4为DP……
（1）修改SW2桥优先级
此时如果增大SW2的Bridge Priority，将导致在SW2与SW3所在的segment内，SW2的fa0/3变成Altn Port，SW3的fa0/2成为DP
①由于优先级值增大，SW2 BID依然劣于当前的Root ID，因此交换机角色并不会改变，端口状态同样不变
②SW3收到SW2发送的BPDU，当前的Discarding端口决定成为DP，发送BPDU withproposal
注意：
此时SW3上并不会出现同步现象，即fa0/4并不会被阻塞
③SW2收到BPDU witch proposal bit，由于该BPDU更优，因此DP将放弃该端口角色，而成为Altn Port，端口立即被阻塞，完成收敛
注意：
SW2的fa0/3由于立即被阻塞，不会发送BPDU with agreement
④SW3的fa0/2在经过2个Forward Delay之后，才完成收敛
（2）SW2将桥优先级改回默认值
①SW2在修改优先级后，由于之前fa0/3是下游端口，保留有BestBPDU，此时可以直接通过比较发现SW2在该segment内更优，因此Discarding端口在收到SW3的BPDU之前就已经决定成为DP，并且发送BPDU withproposal
②SW3收到BPDU，由于该BPDU更优，因此本地直接将端口阻塞，收敛完毕（同样不会发送BPDU withagreement）
③SW2的fa0/3在2个Forward Delay之后，完成收敛
（3）SW2将fa0/1的cost修改为1
在SW2与SW3之间，SW2通告的BPDU的Root Path Cost变小，但是由于SW2已经是指定桥了，因此端口角色、状态都不会变化
（4）SW3将fa0/2的cost修改为1
此时在SW3上产生了一条距离根桥更近的路径，fa0/2将成为RP，而fa0/1将变成Altn Port
①SW3上，RP发生了改变，STP确定各个端口的角色，fa0/2为RP，fa0/1为Altn Port，fa0/3为DP
②SW3开启同步机制，fa0/3被阻塞
③SW3确定各个端口的状态，fa0/2直接进入Forwarding，fa0/1为Blocking，fa0/3由于期望成为DP，发送BPDU with proposal
④SW4收到BPDU with proposal后，由于接收端口是RP，因此响应BPDU withagreement
⑤SW3收到BPDU with agreement，确定DP端口状态为Forwarding
7.2 出现新根桥
如上图所示，当生成树拓扑发生改变时，STP与RSTP的应对策略将有所不同：
SW4通过修改桥优先级，成为新的根桥
STP收敛步骤
RSTP收敛步骤
SW4：
①SW4的BID参数优于当前RID，成为新的根桥
②SW4所有端口将成为DP
因此fa0/2直接由RP转到DP
fa0/3由Blocking转为Listening
③SW4的所有端口在2xForward Delay后达到稳定
SW3：
①SW3收到SW4的BPDU，原先根桥被抑制
②fa0/4成为新的RP，端口状态依然为forwarding
③fa0/1以及fa0/2都有成为DP的潜力，因而
fa0/2进入listening状态
fa0/1由RP变为DP，维持forwarding
④fa0/2收到来自SW2的BPDU，选举后，将fa0/2阻塞
⑤fa0/1在选举中胜出，维持forwarding
⑥SW3的所有端口在fa0/2被阻塞后达到稳定
SW2：
①收到SW4的BPDU，原先根桥被抑制
②fa0/4成为新的RP，端口状态依然为forwarding
③fa0/1以及fa0/3都有成为DP的潜力，因而
fa0/1又RP变为DP，维持forwarding
fa0/3维持forwarding
④SW2的所有端口在收到SW4的BPDU后即可达到稳定
SW1：
①收到来自上游的BPDU，根桥发生改变
②根据接收到的BPDU，fa0/2由DP转为RP，维持forwarding
③fa0/3在选举中失败，被阻塞
④SW1的所有端口在收到来自SW2、SW3的BPDU
并确定端口角色后达到稳定
整个STP网络在30 s后完成收敛
限制因素在于SW4的fa0/3不得不从listening开始收敛
SW4：
①SW4的BID参数优于当前RID，成为新的根桥
②SW4所有端口将成为DP
fa0/2直接由RP转到DP
fa0/3由于之前处于discarding状态
fa0/3发送的BPDU中开启proposal bit
③SW4的所有端口在fa0/3收到agreement后达到稳定
SW3：
①SW3的fa0/4收到BPDU，原先根桥被抑制，
②fa0/4成为新的RP，端口状态依然为forwarding
③开启同步机制，阻塞将成为DP的fa0/1
fa0/2由于原本就处于discarding状态，因此维持阻塞
④同步完毕，从fa0/4发送BPDU，开启agreement bit
以上过程由于不受计时器限制，因此实际执行时速度很快
⑤fa0/2以及fa0/1发送的BPDU中，开启proposal bit
⑥由于SW2没有开启同步机制，因此其DP无需agreement
SW2发给SW3的BPDU中并不开启proposal
SW2由于收到superior BPDU，将fa0/3阻塞
⑦由于SW1处发生了状况，此时SW3的fa0/1一直收不到agreement
经过2xForward Delay后进入forwarding
⑧SW3上的所有端口在fa0/1收敛完毕后达到稳定
SW2：
①收到SW4的BPDU，原先根桥被抑制
由于SW4的fa0/2的BPDU不带有proposal
同步机制不会被开启
②SW2根据BPDU，fa0/4成为新的RP，其它端口均为DP
fa0/1、fa0/3维持forwarding状态
③SW2的所有端口在收到SW4的BPDU后即可达到稳定
SW1：
①SW1首先收到来自SW3的BPDU
原先根桥被抑制
②fa0/3将成为RP，由于BPDU中带有proposal bit
SW1开启同步机制
fa0/2被阻塞
③fa0/2收到来自SW2的BPDU，其中proposal bit没有开启
④由于fa0/2收到的BPDU更优，RP发生改变
fa0/3由于已经收到了来自SW3的BPDU
此时该端口不再认为自己将成为DP
又由于proposal bit没有开启，因此fa0/3不会进行同步
fa0/3处于discarding状态，且不会向上游发送agreement
⑤SW1的所有端口在收到来自SW2的BPDU后达到稳定
整个STP网络在30 s后完成收敛
限制因素在于SW3的fa0/1不得不等待2个Forward Delay
可见：
RSTP的收敛速度并不总快于STP
本例中导致RSTP收敛需要30 s，主要是因为proposal/agreement机制与STP标准收敛同时进行
QQ群⑧：
窥视卡
雷达卡
发表于 2013-9-10 09:38:37
提升卡
置顶卡
沉默卡
喧嚣卡
变色卡
千斤顶
显身卡