RSTP快速收敛（Cisco实现）

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标准收敛同时进行