• STP RSTP


    一、透明网桥

    1.对于一般的透明网桥来说,通常都具有以下的特点:
    +拓展LAN的能力
    +自主动态学习站点的地址信息
    当网桥的某个端口上收到含有某个源MAC地址的数据帧时,它就把该MAC地址和接收该数据帧的端口号保存在MAC地址表中。MAC地址表能够指明该MAC地址与透明网桥的哪个端口相连。
    +问题:一般的透明网桥不会对转发的报文做任何记号,这样没如果网络中存在回路,则有可能报文在回路中不断循环转发,造成网络拥塞

    当网桥收到一个数据帧时,会查找这张地址表,找到目的MAC所对应的端口。然后分下列三种情况进行处理:
    如果目的端口是接收端口,则抛弃这个帧;如果不是接收端口,则从那个端口转发该帧。
    如果收到的数据帧不能从该表中找到对应目的地址的端口,则要从除收到该数据之外所有其他端口广播出去。
    另外如果网桥收到的是广播帧,也要把该帧从除接收端口以外的所有其他端口转发出去。
    但问题是“透明”网桥毕竟不是路由器,它不会对报文做任何修改的,报文中不会记录到底经过了几个网桥,如果网络中存在环路,报文有可能在环路中不断循环和增生,造成网络的拥塞,因而导致了网络中“路径回环”问题的产生

    2.路径回环的产生
    由于环路造成报文循环和增生
    假定A站点还没有发送过任何包,因此网桥B1、B2和B3的地址表中都没有A的地址的记录。当A发送了一个包,最初三个网桥都接受了这个包,记录A的地址在LAN1上,并排队等待将这个包转发到LAN2上。根据LAN的规则,其中的一个网桥将首先成功的发送包到LAN2上,假设这个网桥是B1,那么B2和B3将会再次接收到这个包,因为B1对于B2和B3来说是透明的,这个包就好像是A在LAN2上发送的一样,于是B2和B3记录A在LAN2上,排队等待将这个新包转发到LAN1上,假设这时B2成功将最初的包转发到LAN2上,那么B1和B3都接收到这个包。B3还好,只是认为A仍然在LAN2上,而B1又发现A已经转移到LAN2上了,然后B1和B3都会排队等待转发新包到LAN1上。如此下去,包就在环路中不断循环,更糟糕的是每次成功的包发送都会导致网络中出现两个新包。

    3.生成树协议

    +通过阻断冗余链路来消除桥接网络中可能存在的路径回环
    +当前活动路径发生故障时激活冗余备份链路恢复网络连通性
    回路的存在可以在拓扑结构的某条链路断开之后,仍然保证网络的连通性。
    透明网桥在无回路的网络中发挥的作用是无可指摘的。
    找到了一种很好的算法,它通过阻断冗余链路将一个有回路的桥接网络修剪成一个无回路的树型拓扑结构,这样既解决了回路问题,又能在某条活动(active)的链路断开时,通过激活被阻断的冗余链路重新修剪拓扑结构以恢复网络的连通。
    上面的图中给出了一个应用生成树的桥接网络的例子,其中字符ROOT所标识的网桥是生成树的树根,实线是活动的链路,也就是生成树的枝条,而虚线则是被阻断的冗余链路,只有在活动链路断开时才会被激活。

    二、STP(Spanning Tree Protocol)生成树协议
    1.原理
    +基本思想 :在网桥之间传递特殊的消息(配置消息),包含足够的信息做一下工作:
    从网络中的所有网桥中,选出一个作为根网桥(root)
    计算本网桥到根网桥的最短路径
    对每个LAN,选出里根桥最近的哪个网桥作为指定网桥,负责所在LAN上的数据转发
    网桥选择一个根端口,该端口给出的路径是此网桥到根桥的最佳路径
    选择除根端口之外的包含于生成树上的端口(指定端口)

    网桥之间彼此传递一种特殊的配置消息,802.1D协议将这种配置消息称为“配置桥协议数据单元”或者“配置BPDU”。配置消息中包含了足够的信息来保证网桥完成生成树的计算。

    2.配置消息
    +配置消息也被称作桥协议数据单元(BPDU)
    +主要内容包括
    根网桥的Identifier(RootID)
    从指定网桥到根网桥的最小路径开销(RootPathCost)
    指定网桥的Identifier
    指定网桥的指定端口的Identifier
    即(RootID,RootPathCost,DesignatedBridgeID,DesignatedPortID)
    最初,所有的网桥都发送以自己为根桥的配置消息,比如网桥B发送的配置消息为(B,0,B,PortID); 网桥将接收到的配置消息和自己的配置消息进行优先级比较,保留优先级较高的配置消息,并据此完成生成树的计算。
    桥接网络中,每个网桥都有一个用来标识自己的唯一的48位地址,生成树协议中,使用网桥优先级和该48位地址的组合作为网桥的ID在配置消息的数据部分中来表示这个网桥。对每个网桥来说,这个网桥的所有端口可以使用端口优先级和端口索引值作为ID来表示,生成树协议使用这个ID在配置消息中唯一的表示网桥中的某个特定端口。
    配置消息格式
    BPDU配置消息是以以太网数据帧的格式进行传递的,它采用一个周知的多播MAC地址01-80-C2-00-00-00作为目的MAC地址,网络中所有的网桥收到该地址后都能够判断出该报文是生成树协议的协议报文。源MAC地址域中填的是本网桥的MAC地址。数据链路层报头中的S A P 值是0 1 0 0 0 0 1 0(0x42)。
    在报文的数据域中携带了用于生成树计算的所有数据。它除了上面所提到的根桥ID,到根的最小路径费用,指定桥ID和指定端口ID外,还包含其它一些辅助信息的值。

    3.生成树比较
    配置消息的处理
    +将各个端口收到的配置消息和自己的配置消息做比较,得出优先级最高的配置消息更新本身的配置消息,主要工作有:
    选择根网桥RootID:最优配置消息的RootID
    计算到根桥的最短路径开销RootPortCost:如果自己是根桥,组最短路径开销为0,否则为它收到的最优配置消息的RootPathCost与收到该配置消息的端口开销之和
    选择根端口RootPort:如果自己是根桥,则根端口为0,否则根端口为收到最优配置消息的那个端口
    选择指定端口:包括在生成树上处于转发状态的其他端口
    +从指定端口发送新的配置消息

    确定最优的配置消息
    配置消息优先级比较的原则是:
    先比较根网桥的ID,数值较小的那个优先级较高;
    如果根网桥ID相同,则比较发送网桥到根桥的最短路径,数值较小的优先级较高;
    如果前两者都相同,则比较发送网桥的ID,数值较小的优先级较高;
    最后如果前三者都相同,则比较发送端口ID(即配置消息中的指定端口的ID),同样是数值较小的优先级较高。
    如果前三者都相同,表明发送网桥的两个端口连接到一个物理LAN上。


    B81总共有五个端口,分别接收到这样的配置消息:
    Port1:(32,0,32)
    Port2:(23,18,123)
    Port3:(23,14,321)
    Port4:(23,14,100)
    Port5:(23,15,80)
    注意:在计算过程中,指定端口ID不影响根桥的选择,但会影响根端口的选择。在此,我们为简化起见,暂且不考虑指定端口ID。表示BPDU消息的优先级矢量用(RootID,RootPathCost,DesignatedBridgeID)来表示。
    经过优先级比较,可以确定最好的根桥是23;而且本网桥到根桥的最短路径是14+1=15;网桥还必须从端口3和端口4中选出一个作为根端口,由于端口4的配置消息的发送桥ID为100,比端口3的321较小,所以端口4为根端口。
    网桥81将发送(23,15,81)的配置消息,该配置消息优于端口1和2收到的配置消息,因此网桥81为端口1和2所连接的网段的指定网桥,并把自己的配置消息从端口1、2发送出去。
    这样就确定了,阻塞端口3和端口5,端口4是根端口,端口1和端口2是指定端口。阻塞的端口不参与数据的转发,根端口或指定端口收到的需要转发的数据只能从其他的根端口或指定端口转发出去。
    从整个网络来看,就等于阻塞了某些链路,而其他的链路组成一个无回路的树型拓扑结构。

    5.链路故障处理
    +Hello Time
    网桥从指定端口以Hello Time 为周期定时发送配置消息
    +Message Age和Max Age
    端口保存的配置消息有一个生存期Message Age字段,并按时间递增。每当收到一个生存期更小的配置消息,则更新自己的配置消息,当一段时间未收到任何配置消息,生存期达到Max Age时,网桥则认为该端口连接的链路发生故障,进行故障的处理
    生成树算法提供了一种定时器策略,配置消息中携带了一个生存期的域值,根网桥从它的所有端口周期性的发送生存期为0的配置消息,收到配置消息的网桥也同样从自己的指定端口发送自己的生存期为0的配置消息。如果生成树的枝条出现故障,则这条链路下游的端口将不会收到新鲜的配置消息,自己的配置消息的生存期值不断增长,直至到达一个极限。该网桥将抛弃这个过时的配置消息,重新开始生成树计算。
    其中,定时发送的周期为hello time;配置消息的生存期为message age;最大生存期为max age。


    6.临时回路的处理
    +当拓扑结构发生变化,新的配置消息要经过一定的时延才能传播到整个网络,在所有网桥收到这个变化的消息之前
    若旧拓扑结构中处于转发的端口还没有发现自己应该在新的拓扑中停止转发,则可能存在临时的回环
    若旧的拓扑结构中阻塞的端口还没有发现自己应该在新的拓扑中开始转发,则可能造成网络暂时失去连通性

    避免临时回路
    +端口由阻塞状态进入转发状态时,要经过一定时间的延时,这个时间起码时配置消息传播到整个网络所需最大时间的两倍
    +Forward Delay:配置消息传播到整个网络的最大时延
    设计中间状态:处于中间状态的端口只是学习站点的地址信息,但不转发数据
    端口从阻塞状态经过Forward Delay的延时后进入中间状态
    再经过Forward Delay的延时后才能进入转发状态

    端口的几种状态

    为解决临时回路的问题,生成树协议引入了若干中间状态。在802. 1D的协议中,端口有这样几种状态:
    Disabled:表示该端口不可用,不接收和发送任何报文。这种状态可以是由于端口的物理状态导致的,也可能是管理者手工配置的。
    Blocking:处于这个状态的端口不能够参与转发数据报文,但是可以接收配置消息,并交给CPU进行处理。不过不能发送配置消息,也不进行地址学习。
    Listening:处于这个状态的端口也不参与数据转发,不进行地址学习;但是可以接收并发送配置消息。
    learning:处于这个状态的端口同样不能转发数据,但是开始地址学习,并可以接收、处理和发送配置消息。
    forwarding:一旦端口进入该状态,就可以转发任何数据了,同时也进行地址学习和配置消息的接收、处理和发送。

    端口状态迁移

    当一个端口被选为根端口或指定端口,就会从blocking状态迁移到一个中间状态listening状态;经历forward delay的延时,迁移到下一个中间状态learning状态;再经历一个forward delay延时,迁移到forwarding状态。
    当一个端口由于拓扑发生改变不再是根端口或指定端口了,就会立刻迁移到blocking状态。
    并且,处于任何状态的端口都可能因为端口可用或者不可用变成disabled状态。
    从listening迁移到learning,或者从learning迁移到forwarding状态,都需要经过forward delay延时,通过这种延时迁移的方式,能够保证网络中需要迁移到discarding状态(即为胶片中的Blocking状态)的端口已经完成了迁移,因此能够有效的避免临时环路的形成。

    7.拓扑改变时处理
    +拓扑结构改变会使站点再生成树中的相对位置发生移动,那么网桥原来学习到的MAC地址信息就可能变得不正确,所以学习到的MAC地址信息也要有生存期,如果该时间内没有证明地址的正确,则抛弃这条地址信息
    +在生成树协议中有两个生存期
    拓扑稳定的时候用较长的生存期
    拓扑改变的时候用较短的生存期
    +网络拓扑发生改变的时候,并不是所有的网桥都能够发现这一变化,所以需要把拓扑改变的信息通知到整个网络

    拓扑改变消息的传播

    拓扑改变报文有三种:拓扑改变通知消息,拓扑改变应答消息,拓扑改变消息。下面分别来介绍一下三种报文的含义:
    1)拓扑改变通知消息:发现拓扑改变的网桥从根端口以hello time为周期定时向根网桥的方向发送拓扑改变通知消息,每一个收到这个通知消息的非根网桥也同样要向根桥的方向发送这个消息。这个消息是一个格式比较特殊的报文,它没有数据项,只需要让根知道拓扑改变即可。
    2)拓扑改变应答消息:收到拓扑改变通知消息的网桥如果不是根网桥需要响应一个拓扑改变应答消息,收到应答消息的网桥就知道了:哦,你已经收到我的通知消息,那我就停止发送通知消息吧。这个消息是携带在该网桥发送的下一个配置消息中,用一个拓扑改变应答标志位来标识。
    3)拓扑改变消息:根网桥收到拓扑改变通知消息,或者自己发现拓扑改变之后,则在一个时间段内,在以hello time为周期定时向其他网桥发送的配置消息中,携带一个拓扑改变的标志位。收到这个消息的网桥将会应用那个较短的地址表项生存期,直到收到的配置消息中不再有这个标志。

    8.生成树协议的不足
    +端口从阻塞状态进入转发状态必须经理两倍的Forword Delay时延,所以网络拓扑结构改变之后需要至少两倍的Forward Delay时延,才能恢复连通性
    +如果网络中的拓扑结构变化频繁,网络会频繁的失去连通性,这样用户就会无法忍受

    三、RSTP 快速生成树协议
    1.RSTP 快速生成树协议
    +快速生成树协议是从生成树协议发展而来,实现的基本思想一致
    +快速生成树具备生成树的所有功能
    +快速生成树改进目的就是当网络拓扑结构发生变化时,尽可能快的恢复网络的连通性

    2.快速生成树协议改进

    +在新拓扑结构中的根端口可以立刻进入转发状态,如果旧的根端口已经进入阻塞状态,而且新根端口连接的对端交换机的指定端口处于Forwarding状态
    快速生成树从三个方面实现“快速”功能:
    1)一个新的根端口从阻塞到转发:如果旧的根端口已经知道自己不再是根端口了,并进入阻塞状态,且此时新的根端口连接的网段的指定端口正处于转发状态,那么这个新的根端口就可以无延时的进入转发状态。

    2)一个非边缘指定端口从阻塞到转发:“非边缘”的意思是这个端口连接着其他的网桥,而不是只连接到终端设备。等待进入转发状态的指定端口向下游发送一个握手请求报文,如果下游的网桥响应了一个赞同报文,则这个指定端口就可以无延时的进入转发状态。
    握手请求报文是在该端口发送的下一个配置消息中,用一个握手标志位来标识;握手响应报文也是携带在端口发送的下一个配置消息中,用一个赞同标志位来标识。

    不过这种快速状态迁移需要一个前提条件:发起握手的端口与响应握手的端口之间是一条点对点链路!如果这个条件不满足,握手将不会被响应。那么这个指定端口只好等待两倍的forward delay时延了。
    可见点对点链路对快速生成树的性能有很大的影响,下面列举了点对点链路的几种情况:
    该端口是一个链路聚合端口,与聚合链路绑定;(请参考端口聚合部分的内容)
    该端口支持自协商功能,并通过协商工作在全双工模式;(请参考相关章节的描述)
    管理者将该端口配置为一个全双工模式的端口。
    其他的情况下,端口连接的链路都不能认为是点对点链路。
    还有一点需要注意的,响应握手的网桥只有在把自己的非边缘指定端口迁移到阻塞blocking状态之后,才会响应一个赞同报文。那么响应握手的网桥的非边缘指定端口也需要向下游发起握手了。也就是说,握手会不断扩散直到网络的边缘

    3)边缘端口从阻塞到转发:这一点很好理解,所谓“边缘端口”是指那些直接和终端设备相连,不再连接任何网桥的端口。这些端口的状态并不影响整个网络的连通,也不会造成任何的环路。所以网桥启动以后,这些端口可以无时延的快速进入转发状态。

    快速生成树改进后的性能归纳如下:
    1)如果网络的拓扑变化是根端口的改变引起的,并且有一个备用的端口可以成为新的根端口的话,那么故障恢复的时间就是根端口的切换时间,无需延时,无需传递配置消息,只是一个处理的延时。如果CPU足够快的话,这个恢复时间你可能根本就没觉察到。
    2)如果网络的拓扑变化是指定端口的变化引起的,并且也有一个备用端口可以成为新的指定端口的话,那么故障恢复的时间就是一次握手的时间。而一次握手的时间就是发起握手和响应握手的端口各发送一次配置消息的时间,即两倍的hello time。不过握手的扩散往往使情况糟糕一点,最坏的情况是:握手从网络的一边开始,扩散到网络的另一边,比如网络直径为7的情况,最多要经过六次握手,网络的连通性才能被恢复。
    3)如果网络的拓扑变化是边缘端口的变化引起的,无需延时。网络的连通性根本不受影响。

    四、生成树和快速生成树的比较
    除了端口状态迁移方面的改进,快速生成树协议与生成树协议的区别
    1)协议版本不同:在发送配置消息中有一个域携带了协议版本号。
    2)端口状态迁移方式不同;
    3)配置消息的格式不同;
    4)拓扑改变消息的传播方式不同。
    这些改进都是为了配合“快速”的需求。
    需要说明的是,快速生成树改进的只是生成树的收敛时间。并没有解决在整个桥接网络只应用一个单生成树实例的不足。因此建议在实际组网中不要使网络直径超过7。

    生成树协议配置

    一、
    1.配置生成树功能
    +生成树在交换机缺省实施关闭的,如果组网汇总可能存在路径回环,则要通过命令开启
    stp enable
    +如果确定某个端口连接的部分不存在回路,则可以通过命令关闭该端口的生成树功能
    stp disable
    +也可以根据需要关闭交换机的生成树功能,或者开启某个端口的生成树功能

    2.配置生成树参数
    1)网桥的优先级:Bridge Priority
    2)端口的优先级:Port Priority
    3)端口连接的链路的路径开销:Port Path Cost
    4)三个定时器的初值:hello time,max age,forward delay。
    5)整个交换网络的直径:Bridge Diameter
    可配参数的缺省值
    在系统视图配置模式下配置的参数是整个交换机必须遵从的参数,而在接口配置模式下配置的参数则是该接口需要遵从的参数。
    表中所描述的缺省值是指系统启动时所采用的参数值,如果用户不对其进行任何修改,则系统会始终采用这个值。

    通过配置消息选取合适的根桥
    +网桥ID由两部分组成
    BridgePriority+BridgeMacAddress //优先级+桥的MAC地址
    +如果网络中的所有交换机都在缺省配置下,根据配置消息比较原则,MAC地址最小的交换机被选为根桥,但是该交换机未必是理想的根桥,可以通过命令配置Bridge Priority将合适的交换机推举为根桥
    stp priority bridge-priority

    配置端口开销
    +从本网桥到根桥的路径上所有进过端口的端口开销之和为"跟路径开销",可以通过命令来改变端口开销的值
    stp cost cost

    每个端口对应的路径开销决定了本网桥到根的路径开销。一般说来,端口对应的路径开销取决于端口对应的链路速率。
    另外,一般端口的路径开销越大,该端口连接的LAN就越接近生成树的末梢,那么这个端口的流量就较少。如果某个LAN的带宽较小或者用户希望减少某个LAN的流量,就可以将该端口对应的路径开销配置一个较大的值。

    配置端口的优先级
    在配置消息进行优先级比较的时候,有两种情况会用到端口ID的比较:
    1)网桥收到N条根桥ID相同,根路径开销相同,发送桥ID也相同的配置消息,也就是说发送网桥的多个端口连接到了一个LAN上形成回路,或者两个网桥之间存在平行链路;
    2)网桥的不同端口收到完全相同的配置消息,也就是说该网桥的多个端口连接到了一个LAN上形成回路。
    解决上述两种情况的办法是给每个端口分配一个本地唯一的标识号,也就是端口ID。端口ID由两部分组成:端口优先级+端口号。端口的优先级可以由用户根据实际情况来配置,从而能够人为的控制在上述两种情况中选择参与生成树的端口。配置命令为:
    stp port priority port-priority

    配Hello Time置端口的
    配置hello time需要注意的是:
    较长的hello time可以降低生成树计算的消耗,因为网桥可以不那么频繁的发送配置消息;较短的hello time可以在丢包率较高的时候,增强生成树的健壮性,避免因为丢包而误认为链路故障。
    但是,过长的hello time会导致因为链路丢包而使网桥认为链路故障,开始生成树重新计算;过短的hello time会导致网桥频繁发送配置消息,增加网络负担和CPU负担。
    stp timer hello centiseconds

    配置端口的Max Age
    max age是用来判断配置消息是否“超时”的参数
    +需注意
    值太大,真正的链路故障可能就不能被及时的发现,降低网络自适应能力
    值太小,生成树计算就会比较频繁,而且很可能仅仅是网络拥塞导致的,而不是想象的链路故障。
    +命令
    stp timer max-age centiseconds

    配置端口的Forward Delay
    forward delay是用来防止端口在拓扑改变消息传遍整个网络之前就进入转发状态。
    +需注意
    值太大,生成树收敛太慢
    值太小,可能就避免不了临时回路;
    +命令
    stp timer forward-delay centiseconds

    配置网络直径
    bridge diameter对生成树的性能影响比较大。因为它可以间接的改变max age和forward delay参数,用户需要根据实际情况进行配置。而且在只应用单生成树实例的网络中,网络直径最好不要超过7。
    +定义
    任意两台终端设备之间通过的交换机数目的最大值
    +改变网络直径会间接影响到Max Age和Forword Delay这两个参数的值,而且这种影响比直接手工配置两个参数较为客观
    +所以当网络中加入交换机可以通过改变网络直径参数来达到适应网络状况的目的
    +命令
    stp bridge-diameter bridgenum

    3.监控与维护
    display stp[interface interface_list]
    reset stp [interface interface_list]

    www.huawei.com

  • 相关阅读:
    C# 时间戳转日期
    用robotframework框架搭建自动化测试框架示例一
    Spring MVC中静态资源处理的源码解析
    压缩sql server 数据库的空间,清理日志.ldf
    windows 玩转 nginx
    uniapp的获取token,移除token
    js获取confirm的返回值
    uniapp富文本复制文字内容
    uniapp使用richtext,对后台传入数据进行处理
    uniapp处理后台传入的html代码
  • 原文地址:https://www.cnblogs.com/OceanF/p/9249576.html
Copyright © 2020-2023  润新知