为什么要提出STP的优化问题?
简单的STP配置虽然可以工作,但可能存在一个突出的问题:收敛时间过长,有时候在全网收敛时间可能超过1分钟以上。所以STP在发展过程中也不断在优化,以提升其工作效率。
 
PortFast, UplinkFastBackboneFast
这些都是Cisco提出来的特别针对STP问题的解决方案,具体如下:
1PortFast              使用环境:在接入(access)端口上使用
                                     优化方法:一旦该端口物理上能工作,立即将其置为“转发”状态
                                     配置命令:spanning-tree portfast (interface subcommand)spanning-tree portfast default (global)
2UplinkFast           使用环境:在包含多条上行线路的接入层交换机上使用
                                     优化方法:当一个根端口(RP)失去连接时,立即用另一个RP替换,并                            可立即转发流量,在所有交换机的CAM中触发更新。
                                     配置命令:spanning-tree uplinkfast [max-update-rate rate] (global)
3BackboneFast    使用环境:主要在网络骨干上用来侦测间接的连接失败
                                     优化方法:当RP停止接收Hello时,不需要等待Maxage时间,而是直接                             查询与RP相连的交换机(使用RLQ BPDU)。
                                     配置命令:spanning-tree backbonefast (global)
  
快速生成树协议
IEEE 802.1w快速生成树协议(RSTP)对802.1d标准的提升:加速STP收敛。为了实现这个目的,RSTP定义了与STP所不同的BPDU,定义了新的端口状态以及新的端口角色,同时它还能与STP兼容。具体如下:
1RP反应速度:只等待3HelloSTP10个)
2)可由丢弃状态(代替了STP的阻塞状态)直接转换到学习状态,而不需要STP的监听状态
3CiscoPortFastUplinkFastBackboneFast功能的标准化
4)如果一个交换机有多个端口连接到同一共享LAN段,可以允许备份的DP
RSTP有效利用了交换网络的拓扑结构,因而可以加速收敛。RSTP定义了三种链路类型:
1)点对点:交换机间的连接
2)共享:交换机到hub的连接
3)边:交换机到用户设备的连接
对于边链路类型的处理方式,与前面所述的ProtFast类似(配置也一样)。对于点对点链路,RSTP直接向相邻交换机查询状态,这与BackboneFast类似,只不过这里使用的是IEEE的标准消息罢了。
RSTPSTP端口状态比较:
管理状态
STP状态(802.1d
RSTP状态(802.1w
不可用状态
屏蔽(Disabled
丢弃(Discarding
可用状态
阻塞(Blocking
丢弃(Discarding
可用状态
监听(Listening
丢弃(Discarding
可用状态
学习(Learning
学习(Learning
可用状态
转发(Forwarding
转发(Forwarding
RSTP中,丢弃状态意味着该端口既不转发帧,也不接收帧,也不学习源MAC地址,而不管其什么原因造成。RSTP不再需要监听状态,因为它是动态查询邻接交换机,这就已经保证其收敛的时候不会产生环。
STP类似,RSTP使用端口角色(port role)来表示端口是RP还是DP。除了这两个角色之外,RSTP还引入了一些新的角色,如下表所示:
RSTP角色
描述
根端口
STP
指定端口
STP
可替端口
类似于UplinkFast,可替换的根端口
备份端口
可替换的指定端口
设置RSTP的命令:spanning-tree mode rapid-pvst (global),也可以使用802.1s MST(使用的也是802.1w RSTP
 
快速Per VLAN增值生成树(RPVST+
RSTPPVST+的组合,结合了两者的优点,与MSTPPVST+兼容。
配置方法:在接口上,输入spanning-tree link-type point-to-point命令
 
本文出自 “第二次启航” 博客,请务必保留此出处http://riser.blog.51cto.com/252482/53922