思科加强生成树性能的属性(Portfast /Uplinkfast/BackboneFast)与RSTP的关系

      思科加强生成树性能的属性(Portfast/Uplinkfast/BackboneFast)与RSTP的关系

                                            

                          本文截自于博主CCNP交换技术稿件内容

4.2.6思科加强生成树性能的属性(Portfast/Uplinkfast/BackboneFast)与RSTP的关系

首先说明一下,为什么笔者专门将(Portfast/Uplinkfast/BackboneFast)与RSTP的关系来独立成一个小节进行描述,那是因为,笔者不知被现实工程中的技术实施人员问了同一个问题N次,关于这个问题如下:“为什么在很多资料上,描述RSTP特性时都会提到Portfast /Uplinkfast/BackboneFast这三个特性,甚至说RSTP是具备这三个特性的,然而通过实践工程环境大家不难发现,在很多设备上支持Uplinkfast/BackboneFast这两个特性的交换机一般都不支持RSTP,相反支持RSTP的交换机上一般都不会存在Uplinkfast/BackboneFast这两个特性(至少没有配置它们的命令),而Portfast是乎是所有设备都支持的,这是为什么呢?”

因原是Portfast/Uplinkfast/BackboneFast这三个思科的属性被完整的移植并集成到了RSTP生成树中,也就是因为这个原因,所以很多关于生成树的资料典籍中,在描述RSTP时会同时讨论Portfast/Uplinkfast/BackboneFast三个属性。所以读者在查看别的资料时别被这个给弄混淆了,它们的关键区别如下:

一、Portfast/Uplinkfast/BackboneFast本是思科在RSTP提出之前就具备的三个厂商特性,后来当RSTP集成了Portfast/Uplinkfast/BackboneFast的功能后,通常在支持RSTP生成树的交换机中,IOS就不再提供Uplinkfast/BackboneFast这两个特性的独立配置指令了,因为RSTP会自动完成这两个功能的配置。所以支持RSTP的生成树,就不会存在Uplinkfast/BackboneFast功能的配置指令。下一小节取证将给大家更详细证明这一现象。

二、但是传统的独立支持Portfast/Uplinkfast/BackboneFast三个属性指令的交换机和支持RSTP生成树的交换机都保留了Portfast功能配置的指令,在RSTP中这里的portfast被另一个名词所替代,那就是RSTP中的“边缘端口”,事实上RSTP中的“边缘接口”和传统交换机上的portfast是一回事儿,只是说RSTP不会自动启用它,因为这样太危险,需要管理员手工启动,所以用户才会在传统的独立支持Portfast/Uplinkfast/BackboneFast三个属性指令的交换机和支持RSTP生成树的交换机上都能看到portfast的配置指令。

关于RSTP的特性和基本理论,笔者将在4.3小节部分做更多的描述。

4.2.7取证: Portfast/Uplinkfast/BackboneFast与RSTP的关系

为了更充分的证实4.2.6小节所描述的内容,现在可以通过对两台不同年代设备的生成树功能进行取证,来彻底的理解Portfast/Uplinkfast/BackboneFast与RSTP的关系。因为多数人习惯了在仿真平台上进行学习,那么也可以使用个不同的仿真平台来进行该小节的取证,比如:使用仿真平台GNS3中的3640交换机模块和思科官方的仿真平台Cisco Packet Tracer中的3560交换机。注意这两个设备在生成树功能上的区别在于,GNS3中的3640的交换模块相对于Cisco Packet Tracer中的3560交换机更传统,年代更久远。

首先在传统设备3640上在spanning-tree后面打问号,如图1所示,可以看到在所列出的可用参数中,用户是不能执行spanning-tree mode 来选择RSTP的生成树模式,因为它不支持RSTP模式,所以它提供了Portfast/Uplinkfast/BackboneFast三个思科私有属性来加速传统生成树;所以拥有独立执行三个思科私有属性的指令;相反在Cisco Packet Tracer中相对较新的交换机3560上在spanning-tree后面打问号,如图2所示,可以看到在所列出的可用参数中,用户是可以执行spanning-tree mode 来选择RSTP的生成树模式,由于RSTP是自动集成了Uplinkfast/BackboneFast,简单的讲就是RSTP生成树启动时,Uplinkfast/BackboneFast机制就被开启了,所以在3560上spanning-tree后面打问号就再也看不到启动Uplinkfast/BackboneFast的独立指令了。但是不难发现,无论是传统的3640还是相对较新的3560都能支持portfast指令,请注意对比图1和图3就很清晰,它们都支持portfast,是因为在RSTP生成树中,为了防止潜在的成环风险,边缘端口不会自动启用,需要管理员手工配置。

注意:通过上面的取证过程,说明了一个问题,如果交换机已经具备RSTP功能模式,还去独立搞个启动Uplinkfast/BackboneFast功能的指令作甚?这不画蛇添足吗?这并不是IOS镜像有问题,而是进一步体现了思科IOS镜像功能设计的精简性和科学性,如果用户有更好的网络技术基础,并知道一项技术的发展历程、以及移植集成性,还会在更多的功能上发现诸如此种特性。

时间: 2024-11-07 20:46:13

思科加强生成树性能的属性(Portfast /Uplinkfast/BackboneFast)与RSTP的关系的相关文章

【思科】BGP的community属性解析

BGP的community是一种路由标记方法,用于确保路由过滤和选择的连续性,并且具有可传递性. 实验拓扑: 实验需求: 1.在R1上设置11.0/24 community属性值100:11,将属性传递给R3 2.   为11.11.11.0/24再添加一条属性值no-export 3.   在R1上network 12.0/24网段,根据严格匹配原则,在R3上将到达12.0/24网段的metric设置为1111,而11.0/24的metric不变. 4.   在R3上删除11.0/24路由的n

java 类属性的加载顺序(带有继承关系的)

工作有三年之久了,突然感觉带有继承关系.父子俩既有静态变量又有成员变量的情况,变量的加载顺序很容易混淆,今晚写了个例子,总算是把关系搞清楚了 例子中,父类既有普遍的成员变量,也有static变量,也有static代码块,在父类的构造器前后都有static变量及普通变量,让我们看看初始化子类的时候会发生什么吧 先提供完整代码: LoadSequence.java public class LoadSequence { public static void main(String[] args) {

<meta>标签http-equiv属性中pragma cache-control expires三者的关系。

1 <meta http-equiv="pragma" content="no-cache"> 2 <meta http-equiv="cache-control" content="no-cache"> 3 <meta http-equiv="expires" content="0"> 三者所表达的意义是一样的,而且在现代浏览器中均完美支持. 其中c

性能优化 - 查看 webpack 打包后所有的依赖关系(webpack 可视化工具)

查看 webpack 打包后所有组件与组件间的依赖关系,针对多余的包文件过大, 剔除首次影响加载的效率问题进行剔除修改,本次采用的是 ==webpack-bundle-analyzer(可视化视图查看器)== == 介绍1:webpack-bundle-analyzer(可视化)== 将捆绑内容表示为方便的交互式可缩放树形图 如下效果图: 模块功能: 意识到你的文件打包压缩后中真正的内容 找出哪些模块组成最大的大小 找到错误的模块 优化它! 最好的事情是它支持缩小捆绑!它解析它们以获得实际大小的

STP生成树协议的分析总结

一,STP概述 STP(Spanning Tree Protocol,生成树协议)是有应用于交换机之间的防环的.功能是用来防环的. 基本原理: 通过在交换机之间传递一种特殊的协议报文,网桥协议数据单元(BPDU),来确定网络的拓扑结构.BPDU有两种,一种是配置BPDU(configuration BPDU),一种TC BPDU(拓扑变更BPDU). 前者是用于计算无环的生成树的:后者是用于在二层网络拓扑发生变化时产生用来缩短MAC表项的刷新时间的(由默认的300s--->15s) 分类: ST

STP的配置

拓扑图 实验一:STP之PVST(基于每个vlan的生成树)的配置 (1)将交换机之间的链路都设置为trunk,利用vtp在交换机上创建vlan2 s1(config)#interface range fastEthernet 0/1-3 s1(config-if-range)#switchport mode trunk s2(config)#interface range fastEthernet 0/1-3 s2(config-if-range)#switchport mode trunk

STP 3 - 生成树协议中4个guard 和 3个fast加一个filter

最近出的几个问题总是和生成树协议有问题,复习的时候顺带总结,温故而知新. 先上一个大牛总结的图(Vinny), 总结的非常好,你看完后面的文章再来看这张图就会会心一笑 - i got it ! 先讲下计时器,不论什么协议总是有些计时器,Hello数据包什么的.尤其到路由协议,怎么建立邻居关系,怎么通知拓扑改变,各种不同路由协议是各显神通. 所以在理解的时候最好要了解为什么这些协议需要计时器等等,这样我们就可以以不变应万变. STP Timer  (计时器的配置在当前交换机成为根桥时有用,因为默认

JavaScript 性能分析新工具 OneProfile

OneProfile 是一个网页版的小工具,可以用全新的方式展示 JavaScript 性能分析的结果,帮助开发者洞悉函数调用关系,优化应用性能. 点击打开 OneProfile 背景 Chrome Dev Tools 自带的 CPU Profile 功能非常好用.用它可以方便的生成 JavaScript 的 Flame Chart. 更棒的是你可以把 Flame Chart 导出,留着下次或者拷贝到其它机器上查看,特别好奇它是怎么实现的. 但是网上关于它的文件格式以及怎么画图的文档非常稀有,所

揭秘DOM中data和nodeValue属性同步改变那些事

问题引发:最近在整理DOM系列的一些知识点,发现在DOM的某些接口API中,存在一些我想不通的现象.就随便举个例子吧:DOM文档模型中的文本节点,可以通过nodeValue或data属性访问文本节点的文本内容,而且在更新data的时候nodeValue也即时更新,反之亦然.不光是data或nodeVaulue有这种相互影响的关系,其他类型节点也有比如该改变document.title也会随之改变网页标题.当时想弄明白这在JS引擎中是怎么实现的,于是乎进行了以下分析:通过文本节点的原型链继承关系