RSTP快速收敛（Cisco实现）

shenhp

　　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>
Best BPDU rcv on>AltnPort bdecomes the new RP
　　the elder RP will become DP       //此前的指定桥由于失去了到根桥的连接，此时反而成为了当前设备看来的下游设备，原RP变成DP，向其提供到根桥的连接
run synchronization


else if(there is no>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>　　因此，当生成树网络收敛完毕后，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>　　②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标准收敛同时进行