注:本文译自思科的白皮书Understanding Rapid Spanning Tree Protocol802.1w.
 
----------------------------------------------------------------------------------------------------------------------

 

在802.1d 生成树(STP)标准中,认为网络失效后能够在1分钟左右恢复,这样的性能是足够的。但是随着三层交换引入局域网环境,桥接开始与路由解决方案竞争,后者的开放最短路由协议(OSPF)和增强的内部网关路由协议(EIGRP)能在更短的时间提供备选的路径。
思科引入了Uplink Fast、Backbone Fast和Port Fast等功能来增强原始的802.1D标准以缩短桥接网络的收敛时间,但这些机制的不足之处在于它们是私有的,并且需要额外的配置。
快速生成树协议(RSTP;IEEE802.1w)可以看作是802.1D标准的发展而不是革命。802.1D的术语基本上保持相同,大部分参数也没有改变,这样熟悉802.1D的用户就能够快速的配置新协议。在大多数情况下,不经任何配置RSTP的性能优于思科的私有扩展。802.1w能够基于端口退回802.1D以便与早期的桥设备互通,但这会失去它所引入的好处。
新版的802.1D标准,IEEE802.1D-2004,合并了IEEE802.1t-2001 和IEEE802.1w标准。
本文提供了RSTP对先前的802.1D标准增强的内容。
 
下表总结了Catalyst交换机对RSTP的支持和所需软件的最低版本。

Catalyst Platform
MST w/ RSTP
RPVST+ (PVRST+)
Catalyst 2900 XL / 3500 XL
Not available.
Not available.
Catalyst 2940
12.1(20)EA2
12.1(20)EA2
Catalyst 2950/2955/3550
12.1(9)EA1
12.1(13)EA1
Catalyst 2970/3750
12.1(14)EA1
12.1(14)EA1
Catalyst 3560
12.1(19)EA1
12.1(19)EA1
Catalyst 3750 Metro
12.1(14)AX
12.1(14)AX
Catalyst 2948G-L3/4908G-L3
Not available.
Not available.
Catalyst 4000/2948G/2980G (CatOS)
7.1
7.5
Catalyst 4000/4500 (IOS)
12.1(12c)EW
12.1(19)EW
Catalyst 5000/5500
Not available.
Not available.
Catalyst 6000/6500
7.1
7.5
Catalyst 6000/6500 (IOS)
12.1(11b)EX, 12.1(13)E, 12.2(14)SX
12.1(13)E
Catalyst 8500
Not available.
Not available.

 

 

802.1D定义了四个不同的端口状态:
1、Listening,
2、Learning,
3、Blocking
4、Forwarding
参见下面的表格以获得更多信息。
这些端口的状态,无论对于阻塞或转发流量,还是它在活动拓扑中的角色(Root端口,Desgnated端口等)来说,都是混杂的。比如,从操作的观点来看,Blocking和Listening状态的端口没有区别,它们都丢弃帧,也不学习MAC地址。真正的不同在于生成树给予它们的角色。我们可以安全的确定,Listening状态是Designated端口或Root端口在转变成Forwarding状态的过程中。不幸的是,一旦成为Forwarding状态,我们无法从端口状态推断该端口是Root还是Designated角色。这一点说明这个基于状态的术语的失败。RSTP通过分离端口的角色和状态来陈述这个主题。
 
RSTP中只留下了三个端口状态,它们对应着三个可能的操作状态。802.1D中的Disabled, Blocking 和Listening状态在802.1w中合并为同一个Discarding状态。

STP (802.1D) 端口状态
RSTP (802.1w)端口状态
端口包括在活动拓扑中?
端口学习MAC地址?
Disabled
Discarding
No
No
Blocking
Discarding
No
No
Listening
Discarding
Yes
No
Learning
Learning
Yes
Yes
Forwarding
Forwarding
Yes
Yes

 

现在,角色成为赋予端口的一个变量。root端口和Designated端口这两种角色仍然保留,然而Blocking端口角色被分成了Backup和Alternate角色。生成树算法(STA)根据桥协议数据单元(BPDUs)决定端口角色。简单起见,关于BPDU需要记住,总有一个方法可以用来比较它们(BPDUs)并决定哪一个是最优的,这个比较方法可以是基于存于BPDU中的变量来比较的,偶尔也可以基于接收到它们的端口上来比较哪个BPDU是最优的。考虑到这种情况,以下的段落用实践的方式来解释端口角色。
Root端口角色
在网桥设备上接收最优BPDU的端口是Root端口:它是按照术语路径开销(path cost)来计算的距离根网桥最近的端口。生成树算法(STA)在整个桥接网络中选择一个根桥(如在每个VLAN里),根网桥发送的BPDU比其他桥设备更有用。根网桥是在桥接网络中唯一没有Root端口的设备,所有其他的网桥都至少在一个端口上接收BPDU。

 

 

 

Designated 端口角色
如果一个端口在向它所连接的网段上发送最优BPDU,该端口就是一个Designated端口。802.1D桥接设备把不同的网段(segments),比如以太网段,连接在一起来产生一个桥接域。
在一个给定的网段中,理论上只允许存在有一条通往根桥的路径。如果有两条的话,说明该网络中存在环路。
连在同一网段的所有桥接设备(比如交换机)都互相侦听其他设备发送的BPDU,并最终一致同意将发送最优BPDU的网桥作为该网段的指定网桥,而该指定网桥上用来发送BPDU的端口就是Desinated端口。

 

 

 

Alternate和Backup端口角色
这两个端口角色对应于802.1D的Blocking状态。阻塞的端口被定义为非Designated和Root的端口。阻塞的端口接收到的BPDU优于其发送的BPDU。记住,一个端口绝对需要接收BPUD以便保持阻塞。为此,RSTP引入了两个角色。
Alternate端口由于从其他网桥上收到更优的BPDU而被阻塞,如下图所示:网桥A的端口由于从网桥B上收到更优的BPDU而被阻塞,这种区别其实在802.1D中已经做了区分,这也正是思科UplinkFast功能的本质。基本原理在于Alternate端口提供了一个到根网桥的备选路径,以便在原Root端口失效可以替代成为Root端口。如下图中,在A的R端口失效的情况下,替代端口将为A提供一个到根网桥的备选路径

 

 

 

Backup端口由于收到自身其他端口上更优的BPDU而被阻塞,如下图所示:网桥B的端口由于从自身的另一个端口上收到更优的BPDU而被阻塞,Backup端口提供了到达同一网段的备选路径,但不能保证到根网桥的备用连接。因此,它不包括在Uplink的组中。如上图中,在B的D端口失效的情况下,备用端口将为B提供到达AB间网段的备选路径,但并不为B提供到达根桥的备用路径

同样,RSTP用和802.1D同样的标准来计算生成树最终的拓扑,网桥和端口优先级的使用也没有丝毫改变,在思科的实现中,Discarding状态被称作Blocking,CatOS release 7.1及其后版本仍然显示Listening和Learning状态,这就比IEEE标准提供了更多的有关端口的信息。然而,这新功能会使协议定义的端口角色和它当前状态存在不一致的情况。比如,现在一个端口同时既是Designated又是Blocking是完全合法的,然而,这种情况只发生在很短的时间内,只是表示该端口正在向Designated forwarding状态转变。

 

RSTP的BPDU引入了很少改变。在802.1D中仅仅定义了两个标志:拓扑改变(TC)和TC确认(TCA)。然而,如今RSTP用来剩余的所有6位,用来完成以下工作:
1、编码产生该BPDU的端口的角色和状态
2、执行Proposal/Agreement机制

 

 

 

另外一个重大改变是,新的BPDU目前使用类型2和版本2,这也就意味着传统生成树协议将无法识别新的BPDU格式并且丢弃,这个属性使得运行快速生成树(802.1W)的网桥能够容易的检测到有没有运行标准生成树(802.1D)的网桥与其相连

 

 
BPDU在每个Hello-time发送
BPDU在每个Hello-time时间间隔都会发送,而不再仅仅转发(relay)。
在802.1D中,非根网桥只有在其Root端口收到BPDU时,才产生BPDU,也就是说,事实上网桥只是转发(relay)BPDU,而不是生成BPUD。
在802.1w中不再是这样,网桥在每一个<hello-time>(默认2秒)都会发送包含自己当前信息的BPDU,即便自己没有收到根网桥的BPDU。
 
一个端口如果连续三次没有收到hello,协议信息就会立即老化(或者如果max_age过期)。由于上面提到的协议修改,BPUD可以用作网桥之间的keep-alive机制。如果一个网桥连续没有收到三个BPDU,它就会认为自己已经和其直连的Root或Designated网桥失去连接。信息的快速老化可以快速的检测链路故障,如果一个网桥不能从其相邻的设备收到BPDU,它们之间的连接无疑已经断开了。这和802.1D是不同的,这种问题在802.1D中可能发生在通往根网桥的路径中的任何地方。
注:物理链路的失效能够更快的探测出来。
 
这个概念是BackboneFast(Cisco)的核心。IEEE 802.1w委员会决定在RSTP中引入类似的机制。当网桥从它的Designated或Root网桥收到次优的BPUD,它会立即接受它并替换掉先前存储的信息。

 

 

 

由于网桥C仍然知道根(Root)网桥是有效的和正常的,它立即向网桥B发送一个包含根网桥信息的BPDU。因此,网桥B不再发送它自己的BPDU,并接受连接到网桥C的端口为Root端口。
 
快速转变是802.1w引入的最重要的功能。先前的STA(快速生成树算法)在把一个端口转变成Forwarding状态前,只是被动的等待网络收敛。要想获得较快的收敛只能调整保守的默认参数(Forward Delay和Max_age定时器),但是这样子做往往造成网络的稳定性问题。新的快速STP能够主动的确定端口能够安全的转变成Forwarding状态,而无需依赖任何定时器。现在,在RSTP兼容的设备中有了一个真正的反馈机制。为了在端口上获得快速收敛,协议依靠两个新的变量:边缘端口(edge port)和链路类型(link type)。
 
边缘端口的概念思科生成树用户早已熟知,因为它和PortFast功能紧密相关。在网络中,所有和终端用户直连的端口不会产生环路。因此,边缘端口可以略去Listening和Learning阶段而直接转变为Forwarding状态。当链路断开或连上时,边缘端口和开启了PortFast功能的端口都不会引起拓扑改变。与PortFast端口不同的是,边缘端口一旦收到一个BPDU,它就会立即失去边缘端口的属性而成为一个正常的生成树端口。从这一点来看,边缘端口有一个用户配置值和一个操作值。思科在实现中保留了PortFast关键字用于边缘端口的配置,这使用户易于转变到RSTP。
 
RSTP只能在边缘端口和点对点链路上实现快速的转换为Forwarding状态。链路类型是从端口的双工模式(duplex mode)自动获取的。默认时,操作在全双工模式的端口被认为是点对点的,而操作在半双工模式的端口被认为是共享端口。这自动设置的链路类型能被显式的配置所覆盖。在当今的交换网络中,大多数的链路都是工作在全双工模式,RSTP会认为它们是点对点链路。因此,它们可以快速的转换为Forwarding状态。

 

802.1D的收敛
下面的图演示了当一个新的链路新加入桥网络时,802.1D的处理过程:

 

 

 

Root和交换机A中新加入的端口立即进入Listening
状态,阻塞流量。从根开始的BPDU开始通过A传播
在这种情景下,根桥和A之间的链路刚刚加入。假设之前桥A和根桥已经存在一条非直连路径(图中通过C-D)。STA会阻塞一个端口以避免桥接环路。首先,根桥和A之间链路的两个端口一旦激活,它们就会进入Listening状态。现在,桥A能够直接从根桥收到BPDU,它会立即把它的BPDU从Designated端口向树的枝叶方向传播出去。桥B和桥C一旦收到从桥A发送来的更优的BPDU,它们也会立即向枝叶方向传播这些信息。几秒钟后,桥D收到从根桥发送来的BPDU并立即阻塞端口P1。
 

 

 

很快,从根桥发出的BPDU到达桥D,桥D立即阻塞它的端口P1。虽
然现在拓扑收敛了,但网络被破坏了转发延时(forward_delay)的2倍时间。

 

802.1w的收敛
现在来看RSTP是怎样处理相同的情景。记住,最终的拓扑结构和802.1D计算的完全相同(就是说,一个Blocked端口位于和上面相同的位置),只是用于达到这种拓扑的步骤改变了。
桥A和根桥之间链路两端的端口一旦激活,它们就会被置于Designated阻塞状态。到目前为止,所有的行为和纯802.1D环境中完全相同。然而,在这个阶段,桥A和根桥之间要进行一次协商。一旦桥A收到根桥的BPDU,它就会阻塞它的非边缘端口。这个操作叫做同步。同步一完成,桥A就会明确的授权根桥将其端口置为Forwarding状态。下图演示了网络中这一过程的结果:桥A和根桥之间的链路被阻塞了,并且它们在交换BPDU。

 

 

 

一旦桥A阻塞了它的非边缘端口,桥A和根桥之间的链路就被置于Forwarding状态,而到达如下情景:

 

 

 

现在仍然没有环路。网络不再阻塞桥A以上的链路,而是阻塞桥A以下的链路。然而,这在不同的位置切断了网络环路。断点位置沿着根桥产生的BPDU通过桥A在树中向下传播。在这阶段,桥A中新的阻塞端口也会通过与桥B和桥C相连的端口进行协商而快速的进入Forwarding状态,当然在此之前桥B和桥C也会进行同步操作(同步:阻塞自身的非边缘端口)。不像根桥的端口和桥A,桥B只有边缘Designated端口。因此,没有端口需要阻塞以授权桥A进入Forwarding状态。同样,桥C仅阻塞它和桥D相连的Designated端口。图中的状态到达如下情景:

 

 

 

记住,最终的拓扑结构和802.1D实例中的完全相同,这意味这桥D的端口P1最终会被阻塞。这表示,仅在新的BPDU在树中传播的时间内,已经到达了最终的拓扑结构。在这快速的收敛过程中没有定时器参与。RSTP唯一引入的新机制是,一个交换机可以在它新的Root端口发送确认(acknowledgment)信息用于授权立即转换到Forwarding状态,而略过两倍的转发延时的Listening和Learning状态。管理员仅需要记住这些从快速收敛中的受益:
1、网桥之间的协商仅发生在点对点之间的链路中(就是说在全双工链路,除非显式的端口配置)
2、边缘端口扮演一个比802.1D中的PortFast更为重要的角色。如果管理员没有在桥B上正确的配置边缘端口,这些端口的连通性就会受到桥A和根桥之间链路的影响。

 

当一个端口被STA选为Designated端口,802.1D仍然会等两倍的<转发延时>秒(默认=2*15秒),才把它转为Forwarding状态。在RSTP中,这种情况对应于一个端口拥有Designated角色但处于Blocking状态。下图演示了快速状态转换是怎样一步一步完成的。假如根桥和桥A之间接入了新的链路,在收到对端的BPDU前,链路两端的端口都会被置于一个Designated阻塞状态

 

 

 

当一个Designated端口处于Discarding或者Learning状态(并仅在这种情况下),它会在它发出的BPDU中设置proposal位,如上图中的根桥的端口p0所做的,由于桥A受到更优的信息,它立即知道p1成为新的Root端口。桥A接着就会启动一个同步操作,以确定它所有的端口都处于同步状态。一个端口如果满足以下条件之一,那它就处于同步状态:
 
1、端口处于Blocking状态,即在稳定拓扑中的discarding状态。
2、端口是一个边缘端口。
为了演示同步机制对不同种类的端口的影响,假设网桥A存在一个Alternate端口p2,一个Designated端口p3,和一个边缘端口p4。请注意,p2端口和p4端口已经满足以上一个条件而不必在对其进行同步操作。为了完成同步(见上图的步骤2),桥A仅仅需要阻塞端口p3,并把它置为discarding状态。现在,桥A所有的端口都以同步,它可以打开它新选的Root端口p1并向根桥发送一个agreement消息(见步骤3)。这个消息是它收到的proposal BPDU的复制,不同之处仅是设置了agreement位而不是proposal位。这确保端口p0确切的知道它收到的是哪个proposal的agreement。

 

 

 

一旦p0收到该agreement,它会立即转换为Forwarding状态。这就是过程图中的步骤4。注意,同步后端口p3处于designated discarding状态。在步骤4中,这个端口处于与步骤1中的端口p0相同的状态。同样,它会和它的相邻网桥开始propose,试图快速的转变成转发状态。
Proposal/agreement机制是很快速的,因为它不依靠任何定时器。握手的浪潮快速的向网络的边缘扩散,并在网络拓扑改变后迅速的恢复连接。
如果Designated Discarding端口在发出proposal后没有受到哦agreement,它也会慢慢的转变为Forwarding状态,这又退回到了传统的802.1D的Listening-Learning过程。如果对端设备不能识别RSTP BPDU,或对端的端口处于阻塞状态,就会发生这种情况。
思科加强了同步机制,网桥同步时仅阻塞它先前的Root端口。这种机制的工作细节超出了本文的范围。然而,可以安全的假设它包括了绝大多数通常的重新收敛的情况。这种机制在本文“802.1w的收敛”一节中描述的情景中非常有效,因为仅仅在通往最终阻塞端口的路径上的端口临时阻塞了。

 

 

 

RSTP引入了另一个快速转变为Forwarding状态类似与思科的UplinkFast生成树私有扩展。基本上来讲,当一个网桥失去了它的Root端口,它能将它的最优的Alternate端口直接置为Forwarding状态(RSTP也会处理新Root端口的出现)。一个Alternated端口被选为新的Root端口会引起拓扑改变。802.1w拓扑改变机制会清除上游网桥可编址内容表(CAM)的相应条目。This removes the need for the dummy multicast generation process of UplinkFast。
UplinkFast不需要进一步的配置,因为RSTP本来就包括并自动使能了该机制。

 

当802.1D网桥检测到了拓扑改变,它会用一个可靠的机制来首先通知根网桥。如下图所示:

 

 

 

T处产生了拓扑改变。第一步,一个TCN向上发送给根桥。
第二步,根桥广播TC <最大老化时间+转发延时>时间

 

一旦根网桥得知网络拓扑有改变,它会在它所发出的BPDU中设置TC标志,这会传播给网络中的所有网桥。当一个网桥收到一个设置了TC标志位的BPDU,它会把它的桥转发表(bridge-table)的老化时间减少到转发延时的时间。这可以相对快速的清除旧信息,参见Understanding Spanning-Tree Protocol Topology Changes 以获得有关这一过程的更多信息。在RSTP中,这一机制发生了很大改进,无论拓扑改变过程的探测还是其在网络中的传播。
在RSTP中,仅仅非边缘端口转变为Forwarding状态会引起拓扑改变。这和802.1D不同,一个连接的断开不再被认为是拓扑改变(这就是说,一个端口转变为Blocking不再设置TC标志)。当一个RSTP网桥检测到拓扑改变:
l         如果必要,它会启动一个TC等待定时器(TC while timer),定时器的长度等于它所有非边缘Designated端口和Root端口的hello-time的两倍。
l         它会刷新所有和这些端口相关的MAC地址。
注:只要端口运行TC等待定时器,从这个端口发送出去的BPDU都会设置TC标志位。当TC等待定时器激活时,Root端口也会发送BPDU。
当网桥从邻接的网桥收到设置了TC位的BPDU,它会:
l         它会清除它所有端口上学到的MAC地址,除了收到拓扑改变的那个端口。
l         它会启动一个TC等待定时器,并在它所有的Designated和Root端口发送带有TC标志的BPDU(RSTP不再用特定的TCN BPDU,除非需要通知一个早期的网桥)。
这样,TCN快速的洪泛到整个网络。现在,TC传播成为一个一步的过程。事实上,是拓扑改变的发起者来洪泛该信息,不像在802.1D中,仅仅根网桥可以洪泛拓扑改变。这就不再需要等待通知根网桥,再在网络中维持<最大老化时间+转发延时>秒的拓扑改变状态。

 

 

TC产生者直接洪泛该信息到整个网络
仅在几秒之内,或几倍的Hello-time,整个网络中设备的CAM表中的大部分条目就会刷新。这个方法会引起更多的临时洪泛,但另一方面,它清除了潜在的会影响快速收敛的过时信息。
RSTP可以和早前的STP协议共同工作。不过,需要指出的是当与早期的网桥互操作时,802.1w会失去其固有的快速收敛的好处。
每一个端口都维护着一个变量,用于定义相应网段的协议。在端口激活时,一个3秒的迁移延时定时器也会同时启动。当定时器运行时,端口当前的STP或RSTP模式会被锁定。当迁移定时器过期时,端口会适应为它所收到的下一个BPDU的相应模式。如果端口是由于收到BPDU而改变操作模式,迁移延时会重新开始。这就限制了可能的频繁改变模式。

 

 

 

举例来说,假设上图中桥A和B在运行RSTP,桥A为该段的Designated端口。一个运行早期STP的桥C被引入该链路。由于802.1D网桥忽略RSTP BPDU并丢弃它们,C认为该段中没有其他的网桥,并开始发送它的次优的802.1D格式的BPDU。当桥A收到这些BPDU,最大两倍hello-time以后,该端口会改变为802.1D模式。因此,现在C可以理解桥A的BPDU,并接收A作为该段的指定网桥。

 

 

注意在特定情况下,如果移去桥C,桥A的那个端口仍然运行在STP模式,尽管它和它唯一的邻居B运行RSTP会更有效。这是因为桥A不知道桥C从网段中移去。对这种特殊(而很少见)的情况,需要用户手工干预以重启该端口的协议探测。
当一个端口运行在802.1D兼容模式时,它可以处理拓扑改变通知(TCN)BPDU和设置了TC或TCA标志位的BPDU。
RSTP(IEEE 802.1w)生来就包括大部分思科对802.1D生成树的私有增强,比如BackboneFast, UplinkFast和PortFast。RSTP在正确配置的网络中可以获得快速的收敛,有时在几百毫秒左右。传统的802.1D定时器,比如转发延时和最大老化时间,仅仅用于备用。如果点对点和边缘端口被正确的识别和被管理员正确设定,就不再需要这些定时器。而且,如果不用与早期的网桥互通,这些定时器也不再需要。