理解快速生成树协议(802.1w)
注:本文译自思科的白皮书
Understanding Rapid Spanning Tree Protocol(802.1w).
----------------------------------------------------------------------------------------------------------------------
介绍
Catalyst 交换机对RSTP的支持
新的端口状态和端口角色
端口状态(Port State)
端口角色(Port Roles)
新的BPDU格式
新的BPDU处理机制
BPDU在每个Hello-time发送
信息的快速老化
接收次优BPDU
快速转变为Forwarding状态
边缘端口
链路类型
802.1D的收敛
802.1w的收敛
Proposal/Agreement 过程
UplinkFast
新的拓扑改变机制
拓扑改变的探测
拓扑改变的传播
与802.1D兼容
结论
----------------------------------------------------------------------------------------------------------------------
介绍
在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交换机对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定义了四个不同的端口状态:
l Listening,
l Learning,
l Blocking
l Forwarding
参见下面的表格以获得更多信息。
这些端口的状态,无论对于阻塞或转发流量,还是它在活动拓扑中的角色(Root端口,Desgnated端口等)来说,都是混杂的。比如,从操作的观点来看,Blocking和Listening状态的端口没有区别,它们都丢弃帧,也不学习MAC地址。真正的不同在于生成树给予它们的角色。我们可以安全的确定,Listening状态是Designated端口或Root端口在转变成Forwarding状态的过程中。不幸的是,一旦成为Forwarding状态,我们无法从端口状态推断该端口是Root还是Designated角色。这一点说明这个基于状态的术语的失败。RSTP通过分离端口的角色和状态来陈述这个主题。
端口状态(Port State)
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
|
端口角色(Port Roles)
现在,角色成为赋予端口的一个变量。root端口和Designated端口这两种角色仍然保留,然而Blocking端口角色被分成了Backup和Alternate角色。生成树算法(STA)根据桥协议数据单元(BPDUs)决定端口角色。简单起见,关于BPDU需要记住,总有一个方法可以用来比较它们并决定哪一个是最优的,这是基于存于BPDU中的变量来得到的,偶尔也存在接收它们的端口上。考虑到这种情况,以下的段落用实践的方式来解释端口角色。
Root端口角色
在桥设备上接收最优BPDU的端口是Root端口。它是按照术语路径开销(path cost)来计算的距离根网桥最近的端口。生成树算法(STA)在整个桥接网络中选择一个根桥,根网桥发送的BPDU比其他桥设备更有用。根网桥是在桥接网络中唯一没有Root端口的设备,所有其他的网桥都至少在一个端口上接收BPDU。
Designated 端口角色
如果一个端口在向它所连接的网段上发送最优BPDU,该端口就是一个Designated端口。802.1D桥设备把不同的段(segments),比如以太网段,连接在一起来产生一个桥接域。在一给定的段中,只能有一条通往根桥的路径。如果有两条的话,网络中就会有桥接环路。连在同一段的所有桥设备侦听每个BPDU,并一致同意发送最好BPDU的网桥作为该段的指定网桥,该网桥的相应端口就是Desinated端口。
Alternate和Backup端口角色
有两个端口角色对应于802.1D的Blocking状态。阻塞的端口被定义为非Designated和Root的端口。阻塞的端口接收到的BPDU优于其发送的BPDU。记住,一个端口绝对需要接收BPUD以便保持阻塞。为此,RSTP引入了两个角色。
Alternate端口由于收到其它网桥更优的BPDU而被阻塞,如下图所示:
Backup端口由于收到自己发出的更优的BPDU而被阻塞,如下图所示:
这种区别其实在802.1D中已经做了区分,这也正是思科UplinkFast功能的本质。基本原理在于Alternate端口提供了一个到根网桥的备选路径,因此如果Root端口失效可以替代Root端口。当然,Backup端口提供了到达同段网络的备选路径,但不能保证到根网桥的备用连接。因此,它不包括在Uplink的组中。
同样,RSTP用和802.1D同样的标准来计算生成树最终的拓扑,网桥和端口优先级的使用也没有丝毫改变,在思科的实现中,Discarding状态被称作Blocking,CatOS release 7.1及其后版本仍然显示Listening和Learning状态,这就比IEEE标准提供了更多的有关端口的信息。然而,这新功能会使协议定义的端口角色和它当前状态存在不一致的情况。比如,现在一个端口同时既是Designated又是Blocking是完全合法的,然而,这种情况只发生在很短的时间内,只是表示该端口正在向Designated forwarding状态转变。
新的BPDU格式
RSTP的BPDU引入了很少改变。在802.1D中仅仅定义了两个标志:拓扑改变(TC)和TC确认(TCA)。然而,如今RSTP用来剩余的所有6位,用于:
l 编码产生该BPDU的端口的角色和状态
l 执行Proposal/Agreement机制
新的BPDU处理机制
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中可能发生在通往根网桥的路径中的任何地方。
注:物理链路的失效能够更快的探测出来。
接收次优BPDU
这个概念是BackboneFast(Cisco)的核心。IEEE 802.1w委员会决定在RSTP中引入类似的机制。当网桥从它的Designated或Root网桥收到次优的BPUD,它会立即接受它并替换掉先前存储的信息。
由于网桥C仍然知道根(Root)网桥是有效的和正常的,它立即想网桥B发送一个包含根网桥信息的BPDU。因此,网桥B不再发送它自己的BPDU,并接受连接到网桥C的端口为Root端口。
快速转变为Forwarding状态
快速转变是802.1w引入的最重要的功能。先前的STA(快速生成树算法)在把一个端口转变成Forwarding状态前,只是被动的等待网络收敛。要想获得较快的收敛只能调整保守的默认参数(Forward Delay和Max_age定时器),并往往造成网络的稳定性问题。新的快速STP能够主动的确定端口能够安全的转变成Forwarding状态,而无需依赖任何定时器。现在,在RSTP兼容的设备中有了一个真正的反馈机制。为了在端口上获得快速收敛,协议依靠两个新的变量:边缘端口(edge port)和链路类型(link type)。
边缘端口
边缘端口的概念思科生成树用户早已熟知,因为它和PortFast功能紧密相关。在网络中,所有和终端用户直连的端口不会产生环路。因此,边缘端口可以直接转变为Forwarding状态,而略去Listening和Learning阶段。当链路断开或连上时,边缘端口和使能了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状态。管理员仅需要记住这些从快速收敛中的受益:
l 网桥之间的协商仅发生在点对点之间的链路中(就是说在全双工链路,除非显式的端口配置)
l 边缘端口扮演一个比802.1D中的PortFast更为重要的角色。如果管理员没有在桥B上正确的配置边缘端口,这些端口的连通性就会受到桥A和根桥之间链路的影响。
Proposal/Agreement 过程
当一个端口被STA选为Designated端口,802.1D仍然会等两倍的<转发延时>秒(默认=2*15秒),才把它转为Forwarding状态。在RSTP中,这种情况对应于一个端口拥有Designated角色但处于Blocking状态。下图演示了快速状态转换是怎样一步一步完成的。假如根桥和桥A之间接入了新的链路,链路两端的端口都会被置于一个Designated阻塞状态,知道它们从对段受到BPDU。
当一个Designated端口处于Discarding或者Learning状态(并仅在这种情况下),它会在它发出的BPDU中设置proposal位。这正是在上图所示的步骤1中,根桥的端口p0所需要做的。由于桥A受到更优的信息,它立即知道p1称为新的Root端口。桥A接着就会启动一个同步操作,以确定它所有的端口都处于同步状态。一个端口如果满足以下条件之一,那它就处于同步状态:
l 端口处于Blocking状态,即在稳定拓扑中的discarding状态。
l 端口是一个边缘端口。
为了演示同步机制对不同种类的端口的影响,假设网桥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的收敛”一节中描述的情景中非常有效,因为仅仅在通往最终阻塞端口的路径上的端口临时阻塞了。
UplinkFast
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表中的大部分条目就会刷新。这个方法会引起更多的临时洪泛,但另一方面,它清除了潜在的会影响快速收敛的过时信息。
与802.1D兼容
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定时器,比如转发延时和最大老化时间,仅仅用于备用。如果点对点和边缘端口被正确的识别和被管理员正确设定,就不再需要这些定时器。而且,如果不用与早期的网桥互通,这些定时器也不再需要。