23、MSTP多进程

          图1 MSTP和STP-RSTP混合应用场景图.png

                         图1 MSTP和STP/RSTP混合应用场景图

      如上图1所示：

      UPE为汇聚层设备，运行MSTP，UPE1和UPE2之间为二层链路，UPE1和UPE2下接有多个环，不同环通过不同端口接入。环上的交换设备为接入层设备，只运行STP/RSTP，同时UPE1和UPE2属于不同的运营商，不希望计算在一个生成树中，拓扑变化不能影响对方。

      如上图1所示，交换设备和UPE组成多个二层环路，因此需要在此环路上启用生成树协议来防止环路。UPE1和UPE2同时连接多个接入环，各个环之间互相独立，不需要互通，这样在启动生成树协议时就不能将所有交换设备构成的环路计算成一个大生成树，这就需要在各个交换设备构成的环上启用独立的生成树协议进行计算，且互不影响。

      对于MSTP协议标准来说，MSTP支持生成树多实例，但是MSTP支持的多实例必须存在同一个域中，且同一个域中所有设备配置也必须一致。如果不同的设备属于不同的域，那么MSTP在进行生成树计算时，只按一个实例进行计算。

      所以，当网络内的设备属于不同域时，整个网络只能在一个实例中进行生成树计算，网络内任何一台设备状态发生变化，都将影响整个网络。

      上图1所示组网中与UPE相连的交换设备只支持STP/RSTP协议，不支持MSTP协议。根据MSTP协议标准，UPE收到来自交换设备的RSTP报文后，则认为彼此不属于同一个域。那么UPE和交换设备构成的环只会计算出一个生成树，不能实现各个接入环的相互独立。

      为了解决上述问题，引入了MSTP多进程。

      MSTP多进程是基于MSTP协议的增强性技术。此技术可将二层交换设备上的端口绑定到不同的进程中，并以进程为单位进行MSTP协议计算，不在同一个进程内的端口不参与此进程中的MSTP协议计算，从而实现各个进程内的生成树计算相互独立，互不影响。

       因此通过MSTP多进程机制，可将上图1所示组网划分为多个MSTP进程，每个进程对应一个交换设备构成的环，每个MSTP进程功能相同，支持生成树多实例，各进程进行MSTP协议计算时相互独立，不会影响到其它进程中的MSTP协议计算。

       MSTP多进程机制并不只限于MSTP协议，RSTP和STP协议同样适用。

 如上图1所示网络通过部署MSTP多进程可实现如下：

       1、极大地提升了在不同组网条件下生成树协议的可部署性。为了保证运行不同类型生成树协议的网络可靠运行，可将不同类型的生成树协议划分到不同的进程中，不同进程对应的网络进行独立的生成树协议计算。   

      2、增强了组网的可靠性，对于大量的二层接入设备，可减少单台设备故障对整个网络的冲击。通过进程隔离不同的拓扑计算，即某台设备故障只影响其所在的进程对应的拓扑，不会影响其他进程拓扑计算。

      3、网络扩容时，可减少网络管理者维护量，从而提升了用户运维管理的方便性。当网络扩容时，只需要划分新的进程与原有网络对接，不需要调整原有网络的MSTP进程配置。如果是某个进程中进行了设备扩容，此时也只需要针对扩容的进程进行修改，而不需要调整其他进程中的配置。

      4、实现二层端口分割管理。每个MSTP进程可以管理设备上的部分端口，即设备的二层端口资源被多个MSTP进程分割管理，每个MSTP进程上均可运行标准的MSTP。

 

    24、MSTP多进程原理

    1、公共链路的状态

如上图1所示，UPE1和UPE2之间的链路是二层链路，并运行MSTP协议。

UPE1和UPE2之间的公共链路和接入交换设备的链路不同在于：公共链路上的端口需要参与多个接入环和多个MSTP进程的计算，这样UPE1和UPE2之间的MSTP协议报文就需要能区分是来自哪个进程的MSTP协议报文。

      此外，公共链路上的同一个端口同时参与多个MSTP进程的计算，多个MSTP进程中都会计算出端口状态，这样端口就可能同时存在多个状态，从而无法决定采用哪个生成树的状态。

      对于上述情况，公共链路上的端口虽然参与多个MSTP进程的状态计算，但是只具有MSTP进程0的状态，从而不会影响其他MSTP进程。

      设备启动后，设备默认存在ID为0的MSTP进程，系统视图和接口视图中的MSTP相关配置都属于此进程。

      2、可靠性

      图2 MSTP多进程拓扑变化示意图.png

                   图2 MSTP多进程拓扑变化示意图

      如上图2所示，当交换设备构成的环上设备产生拓扑变化后，通过MSTP多进程的特性，UPE可以把TC报文洪泛到环上所有设备，同时可以保证一个交换设备构成的环的拓扑变化消息不会洪泛到其他交换设备环上，UPE1和UPE2及时刷新和本生成树相关端口的MAC和ARP表项，并且不影响其它的交换设备。

       图3 公共链路故障示意图.png

                        图3 公共链路故障示意图

如上图3所示，如果UPE1和UPE2之间的公共链路故障，可能导致多个交换设备接入环路都会打开阻塞端口。

如果UPE1配置为最高优先级，UPE2配置为次高优先级，交换设备采用默认优先级或配置为更低优先级。当UPE1和UPE2之间链路发生故障后，交换设备上的（根端口替换端口）阻塞端口因不再收到高优先级报文而重新进行状态机计算，新计算的结果是成为指定端口，此时就会产生永久环路，如下图4所示。

      图4 接入环路之间形成环路示意图 .png

                图4 接入环路之间形成环路示意图 

       为了解决接入环路之间形成环路问题，可部署以下特性解决。

       1、UPE1和UPE2之间部署跨板Eth-Trunk。

在UPE1和UPE2之间的公共链路使用跨板Eth-Trunk，以提供高可靠性的链路，如下图5所示。

图5 跨板Eth-Trunk提供链路可靠性示意图.png

                    图5 跨板Eth-Trunk提供链路可靠性示意图 
       2、UPE1和UPE2之间部署根保护。

如果UPE1和UPE2之间所有的链路均出现故障，此时UPE1和UPE2之间部署的跨板Eth-Trunk也将不起作用，接入环路仍然会产生永久环路。为了解决上图4所示的永久环路故障，可通过部署根保护解决。

图6 MSTP多进程配置根保护示意图.png

                         图6 MSTP多进程配置根保护示意图 

      如上图6所示，以蓝色的交换设备环为例，UPE1配置为最高优先级，UPE2配置为次高优先级，交换设备环上的设备采用默认优先级或配置为更低的优先级，并在UPE2上配置根保护。

      假设阻塞端口在S1上，当UPE1和UPE2之间的公共链路发生故障后，S1上的阻塞端口因不再收到高优先级BPDU报文而重新进行状态机计算，新计算的结果是该端口成为指定端口，同时和下游设备进行P/A协商。

      当与UPE2直连的S1发送的更高优先级的BPDU报文到达UPE2的启动了根保护的端口后，该端口将被阻塞，因为后续会持续收到报文，所以该端口将一直处于阻塞状态。从而保证不会出现环路。

     

    25、MSTP其它注意事项

当设备使用某个特定的VLAN，创建VLANIF接口作为管理网口时，如果设备启用MSTP协议，通过执行ethernet-loop-protection ignored-vlan命令将该特定VLAN设置为忽略VLAN，在进行协议计算时，该VLAN会忽略阻塞状态，恒为转发状态。从而避免了端口状态为阻塞状态时导致的业务流量中断。

当生成树的拓扑结构发生改变时，和它建立映射关系的VLAN的转发路径也将发生变化。此时，交换设备的ARP表中与这些VLAN相关的表项也需要更新。根据对ARP表项的处理方式不同，STP/RSTP的收敛方式分为fast和normal两种：fast：ARP表将需要更新的表项直接删除；normal：ARP表中需要更新的表项快速老化。

交换设备将ARP表中这些表项的剩余存活时间置为0，对这些表项进行老化处理。如果配置的ARP老化探测次数大于零，则ARP对这些表项进行老化探测。

建议选择normal收敛方式。若选择fast方式，频繁的ARP表项删除可能会导致设备CPU占用率高达100%，报文处理超时导致网络震荡。

 

26交换机的MSTP能与其他厂商设备对接吗

交换机的MSTP采用MSTP标准算法，根据其他厂商运行的协议，可以分为以下几种情况：

如果其他厂商设备运行标准的STP协议（包括STP、MSTP、RSTP），交换机均可与之对接。如果其他厂商设备运行非标准STP协议（cisco的pvst除外），可在端口下配置stp disable、bpdu enable命令实现与该厂商设备STP报文透传。

对cisco设备，如果起了pvst，交换机现有版本无法参与协商计算，但是可以透传报文。

 

27、为什么交换机配置STP非零的实例后无法查看到相应信息

交换机支持MSTP协议，也就是说同时兼容STP和RSTP协议，而非0的实例仅是针对MSTP模式时有效。当STP协议工作在STP/RSTP模式时，仅有实例0有效。

如果需要查询非零实例的相应信息，请执行命令stp mode mstp，配置交换机的STP工作模式为MSTP，即可查询到STP非零实例的相应信息。