CN101867513B - 一种三层网络多生成树链路倒换性能优化的实现方法 - Google Patents

Abstract

本发明公开了一种三层网络多生成树链路倒换性能优化的实现方法，旨在提供一种通信领域多生成树链路倒换性能的优化。其技术方案的要点是，一种三层网络多生成树链路倒换性能优化的实现方法，将所有的TC进行打包，统一发送；改变清表的过程，在一次拓扑变化的过程中，多个实例都要对一个端口按端口清ARP表时，只对该端口ARP统一清表一次；并在hello报文中不携带TC。具体实现包括如下两处，一处在端口变转发，要发出TC处；另一处为收到TC后的处理。本发明的用途：在保证多生成树基本功能的前提下，大大提高生成树链路倒换性能，三层倒换性能可达300-600ms。

Description

一种三层网络多生成树链路倒换性能优化的实现方法

技术领域

本发明涉及到通信领域，更具体地说，属于通信领域多生成树链路倒换性能的优化。 

背景技术

在IEEE提供的标准802.1Q上，对MSTP协议有一个原理上的描述，同时也写出的通用的实现算法，但是标准上所列的该算法，并未对性能提升方面，有较多的提及。 

随着当今社会，科技日新月异的飞速发展，人民对效率要求的越来越高，对工业通信设备而言，有更快的交换速度，就意味着每秒中能处理更多交通流量，就意味着每秒钟商家能生产更多的产品，就意味着安全的生产和生活……现有的生成树技术，并不能达到较为优化的性能，并不能满足持续发展的工业化社会的需要。 

在MSTP性能的优化的过程中，尝试了几种方法，最后选定了一种方法，这种方法能有效的提高性能，而且不会引发其它的一些问题。 

开始分析倒换性能时，分解倒换过程中的各个环节，对各个环节所消耗的时间进行统计分析，发现在整个倒换的过程中握手流程耗费的时间是最多的，所以决定从优化握手流程着手，优化MSTP的倒换性能。 

MSTP发包的个数，有一定的限制，在代码中有一个值，这个值所起到的作用是MSTP在一秒钟发送报文的个数，姑且叫其为发包上限(TX_HOLD_COUNT)，超过发包上限的报文在当前的一秒钟内是无法发送出去的，程序中有变量记录每秒钟的发包个数，每当程序发送一个报文，该变量计数增1，并将该变量与上限(TX_HOLD_COUNT)进行比较，若报文统计发包个数已经等于最大的发包上限(TX_HOLD_COUNT)的时候，如果程序还需要发送报文，那只能等到下一秒了。 

发包上限，是一个常量，通常协议文档中的建议值是在每秒不超过10个，在我司实现的代码中，这个值已经被修改为一个较大的值了，远远大于10。 

而每个实例由事件激发都有可能发送报文，而且每个实例都进行单独发送报文，这样，如果有多个实例，就会有较多的报文交互，在两个交换机报文交互的过程中，如果报文发送的个数超过发包上限所设定的最大值，那么就要等到下一秒进行发送。因此影响了握手消息的交互时间，间接延长了倒换时间，给倒换性能带来了很大的障碍。 

MSTP划分为多个实例，每个实例都单独发包，每个实例有事件到来，都会驱动MSTP协议栈发送报文，每个实例不但要发送报文，还要接收报文，完成交互过程，这个如果是多个实例就会有较多的报文交互，并且每个交互根据消息的标志位的不同还会引发一些其它的报文交互过程。 

这样和发包上限放在一起进行考虑，多实例发包个数必然多，而发包上限要对发包的个数做限制，这两个方面互相矛盾。 

从报文的结构上来看，每个报文中含有，多个实例的信息，每发送一个报文，都会携带其它实例的所有信息，在网络中会有较多的重复性的传输，并且状态机也有很多的重复性的处理。 

举例，域中配置10个实例，实例1需要发送消息，实例1会驱动协议栈发送该报文，该报文中除了携带实例1的消息外，同时也携带其它9个实例的消息，这9个实例是被重复发送的，对端收到这样的消息，并不知道哪个实例才是驱动这个报文发出的实例，所以每个实例所携带的信息，都要执行一遍。相当于有9x9＝81个处理过程被浪费掉了。 

对于发包个数的限制，发明人也曾经尝试来修改发包个数来提高MSTP的倒换性能，对这个值一定的修改的确是可以某种程度上提高性能，它的主要原理就是，将txcount值增大，让其在一秒钟能发较多的包，MSTP所需要发送的报文在一秒钟尽量全部发送出去。经测试，原来MSTP的倒换性能为最大3秒，经过修改txcount的值，可以使倒换性能提高到600毫秒以内。 

但是这样修改同时也存在一些问题，第一个所引起的比较严重的问题，是在多环的拓扑结构的网络中，重启一台主设备的时候会产生MSTP协议报文风暴，而且不可恢复；第二，在网络中交互的MSTP报文较多，这样会影响网络中业务数据的流量。 

发明内容

本发明的目的是克服现有技术中的不足，提供一种更优化的实现方法技术。 

本发明的技术方案是，一种三层网络多生成树链路倒换性能优化的实现方法，将所有的拓扑变化(Topology Change，简写TC)进行打包，统一发送；改变清表的过程，在一次拓扑变化的过程中，多个实例都要对一个端口按端口清地址解析协议(Address Resolution Protocol，简写ARP)表时，只对该端口ARP统一清表一次；并在hello报文中不携带TC。 

具体实现包括如下两处，一处在端口变转发，要发出TC处；另一处为收到TC后的处理； 

(1)端口变转发要发送TC，即首次发出TC标志，将多实例的TC打包统一发送，在一个报文中，携带所有应该带TC的实例； 

(2)收到TC，程序会转到TCM状态机，需在各实例拓扑变化机(Topology Change Machine，简称TCM)处理之前保存下tx_count的值，并将其临时设置为TX_HOLD_COUNT， 在TCM处理完之后，将tx_count设置回前边所保存原值，并调用发送报文的状态机发送报文，该报文将会携带所有实例的TC。 

具体实现步骤如下： 

(1)依次保存所有端口当前的tx_count值，并将其设置为TX_HOLD_COUNT，直至所有端口处理完毕； 

(2)依次以实例为参数调用端口信息状态机，在端口状态机中，以实例为参数调用端口角色选择状态机，直至所有实例处理完毕； 

如果端口角色从替换角色变为指定角色或根角色，设置“是否首发TC”标志为true，否则设为false； 

(3)设置“普通报文是否携带TC”标志为true或false，如果其它报文带TC标志，设置为true，否则设置为false； 

(4)取回在步骤(1)中已保存的所有端口的tx_count值；如果tx_count与TX_HOLD_COUNT相等，则给tx_count减一； 

(5)判断“是否首发TC”或“普通报文是否携带TC”标志只要有一个为true，端口发送的报文就要携带TC，并设置“是否首发TC”标志为默认值false；否则端口发送的报文不携带TC； 

(6)循环(4)-(5)，直至所有端口处理完毕； 

(7)设置“普通报文是否携带TC”标志为true。 

通过端口清表任务信号量的方式进行限制，该信号量保证是否要做清表的动作；具体步骤为： 

(1)持有端口清表任务信号量，这样清表任务会等待； 

(2)依次判断端口实例链表中的实例是否需要清表，如果需要，设置由该清表函数所使用的端口映射(map)； 

(3)等端口上的全部实例添加到清表的端口map中后，释放该信号量；这样清表任务只会对多个实例要清多次的某一端口清一次，而不是各个实例分别要清一次。 

为了尽可能的减少拓扑改变消息，在非拓扑改变事件引发的报文，不携带TC，具体步骤同hello报文中不携带TC，hello报文中不携带TC的具体步骤： 

(1)设置一个“是否发送TC标志”，在发送hello前将该标志置为false；程序中在对报文进行编码的地方，检测该标志，该标志位被置为false的时候不将TC打包在报文中； 

(2)判断“是否发送TC标志”是否被设为true；如果设为true，发送带携带TC的hello报文；设为false，发送不携带TC的hello报文； 

(3)在发完后，再设置“是否发送TC标志”为true。 

本发明的有益效果是：在保证多生成树基本功能的前提下，大大提高生成树链路倒换性能，实测结果三层倒换性能从最大2秒，提高到300～600毫秒左右。 

附图说明

图1TC报文发送流程图； 

图2清ARP表流程图； 

图3hello报文中是否携带TC流程图； 

图4四台高端交换机连接图； 

图5交换机1为根的各端口角色图； 

图6交换机2为根的各端口角色图； 

图7端口标识示意图； 

图8hello报文中携带TC示意图； 

图9hello报文中不携带TC示意图。 

具体实施方式

MSTP表示多生成树协议； 

Instance：实例； 

Vlans Mapped：虚拟局域网映射； 

dtring-2：代表多生成树域； 

tx_count：报文发送个数； 

TX_HOLD_COUNT：一秒钟允许发包的最大个数； 

TC报文：是MSTP用来将新的拓扑信息告知网络中的其它所有节点，这个消息会一跳一跳的向下传递，直到传遍整个网络，网络中的每个节点在收到TC报文的时候，根据端口清ARP表，清表的过程是否迅速，也会影响到MSTP倒换的性能。 

下面结合幅图对本发明进行说明。 

图1指示了TC报文发送流程图，将所有的TC进行打包，统一发送； 

具体实现包括如下两处，一处在端口变转发，要发出TC处；另一处为收到TC后的处理； 

具体实现步骤如下： 

(1)端口变转发，依次保存所有端口当前的tx_count值，并将其设置为TX_HOLD_COUNT，直至所有端口处理完毕； 

(2)依次以实例为参数调用端口信息状态机，在端口状态机中，以实例为参数调用端口角色选择状态机，直至所有实例处理完毕； 

a、如果端口角色从替换角色变为指定角色或根角色，设置“是否首发TC”标志为true，否则设为false； 

(3)设置“普通报文是否携带TC”标志为true或false，如果其它报文带TC标志，设置为true，否则设置为false； 

(4)取回在步骤(1)中已保存的所有端口的tx_count值；如果tx_count与TX_HOLD_COUNT相等，则给tx_count减一； 

(5)判断“是否首发TC”或“普通报文是否携带TC”标志只要有一个为true，端口发送的报文就要携带TC，并设置“是否首发TC”标志为默认值false；“是否首发TC”或“普通 报文是否携带TC”标志没有true，端口发送的报文不携带TC； 

(6)循环(4)-(5)，直至所有端口处理完毕； 

(7)设置“普通报文是否携带TC”标志为true。 

图2指示了清ARP表流程图，改变清表的过程，在一次拓扑变化的过程中，多个实例都要对一个端口按端口清ARP表时，只对该端口ARP统一清表一次； 

通过端口清表任务信号量的方式进行限制，该信号量保证是否要做清表的动作；具体步骤为： 

(1)持有端口清表任务信号量，这样清表任务会等待； 

(2)依次判断端口实例链表中的实例是否需要清表，如果需要，设置由该清表函数所使用的端口map； 

(3)等端口上的全部实例添加到清表的端口map中后，释放该信号量；这样清表任务只会对多个实例要清多次的某一端口清一次，而不是各个实例分别要清一次。 

图3指示了hello报文中是否携带TC流程图，hello报文中不携带TC的具体步骤： 

(1)设置一个“是否发送TC标志”，在发送hello前将该标志置为false；程序中在对报文进行编码的地方，检测该标志，该标志位被置为false的时候不将TC打包在报文中； 

(2)判断“是否发送TC标志”是否被设为true；如果设为true，发送带携带TC的hello报文；设为false，发送不携带TC的hello报文； 

(3)在发完后，再设置“是否发送TC标志”为true。 

拓扑消息多实例打包发出，和其它的消息的打包发出，不能在一个地方进行处理，要分开处理，如放在一起会导致协议运行性能的下降，这样在TC定时器内，会有其它的报文也发出，并且也会携带TC标志。为了尽可能的减少拓扑改变消息，在非拓扑改变事件引发的报文，不携带TC，具体步骤同hello报文中不携带TC相同。 

下面各图指示了该发明的使用环境、实现过程及效果。 

图4指示了由四台高端交换机组成的连接图，图中每一个带有四个箭头的方块体，代表一台高端交换机，图中的黑色实线代表交换机间的连线(光缆或网线)，可以看出该拓扑是一个多环的网络结构，例如，交换机12和3形成了一个环形结构，交换机124形成了一个环形结构，交换机1234也形成了一个环形结构，根据交换机的转发特性，在这样的拓扑中，必须要使用生成树协议来避免网络中产生风暴。 

四台设备的生成树配置信息均为： 

对于四台设备上述信息相同，也就意味着四台设备在同一个域内，从该配置信息还可以看出， 

在该域内有10个实例。 

优先级设置，各设备有所不同，数值越小，优先级越高； 

设备1的优先级配置为： 

dtring-2 

dtring-2 mst 0 priority 4096 

dtring-2 mst 2 priority 8192 

dtring-2 mst 3 priority 4096 

dtring-2 mst 4 priority 8192 

dtring-2 mst 5 priority 4096 

dtring-2 mst 6 priority 8192 

dtring-2 mst 7 priority 4096 

dtring-2 mst 8 priority 8192 

dtring-2 mst 9 priority 4096 

dtring-2 mst 10 priority 8192 

设备2的优先级配置，和设备1的优先级配置刚好是相反的： 

dtring-2 

dtring-2 mst 0 priority 8192 

dtring-2 mst 2 priority 4096 

dtring-2 mst 3 priority 8192 

dtring-2 mst 4 priority 4096 

dtring-2 mst 5 priority 8192 

dtring-2 mst 6 priority 4096 

dtring-2 mst 7 priority 8192 

dtring-2 mst 8 priority 4096 

dtring-2 mst 9 priority 8192 

dtring-2 mst 10 priority 4096 

设备3的优先级配置和设备4的优先级配置保持默认配置，即所有实例的优先级都为32768。 

图5指示了交换机1为根的各端口角色图；根据以上的优先级设置，对于实例03579 交换机1为根，协议根据设定的基本属性值，设定各端口角色，各端口角色如图所示。 

图6指示了交换机2为根的各端口角色图；对于实例2 4 6 8 10交换机2为根，各端口角色如图所示。 

图7指示了端口标识示意图；白色的圆圈表示根端口，黑色的圆圈表示指定端口，白色的方块表示替换端口，黑色的方块表示备份端口；端口角色中根端口和指定端口业务数据可以流入流出，替换端口阻止业务数据的流入流出，所以整个网络的虽然有多个环，但是实际上通过MSTP协议计算出的个端口角色已经将网络计算成优化的树状，每一个实例都是一棵树，实际的拓扑中已经不存在环路了。 

针对上述配置的基本操作及数据的基本流程 

数据的流向，从交换机3发送数据，从交换机4接收数据，或者同时从交换机4发送数据在交换机3接收数据，发送端持续的发送，接收端持续的接收。 

在此过程中中断承载数据的某一根通路上的数据线，导致数据在链路上发生倒换，用性能测试仪器记录下其在一秒钟以内丢失数据包的数量，通过固定时间内丢包的多少可以判断其倒换性能的优劣。 

具体初始时的数据流向，和断哪条线，导致数据流向如何改变，二层和三层有所不同。二层倒换握手过程流程分析 

对于二层倒换过程的测试，从交换机3的vlan9发送数据，在交换机4的vlan9接收数据，相当于数据在实例9中流动，所发送的报文为二层的单播或者广播报文。 

根据图四中端口角色的分析，实例9是以交换机1为根的，实例9中的数据会从交换机3的1/3端口发出，经交换机1，从交换机1的1/1端口发出，到达交换机4，二层数据所走的就是这样一条通路，就是3-1-4。 

为了触发数据链路倒换的发生，断开交换机1和交换机4之间的连线，这条线正式承载业务数据的一条线，断开这条线，数据就要另找通路才能到达交换机4，数据所选择的新的通路为3-1-2-4，数据链路从1到4的路上倒换到了1到2到4上，这个倒换过程会导致一些数据的丢失，数据丢失的量就是倒换的性能，如果能减少数据丢失的数量，也就是提高的倒换的性能。 

下面分析在此数据倒换的过程中，MSTP都做了哪些计算工作，断开交换机1和交换机4之间的连线，交换机4根端口失去，要重新计算和选定新的根端口，此时4会以自己为根向 相邻的交换机发送消息，在此拓扑中，交换机4会向交换机2发送以自己为根的消息。 

交换机2收到交换机4发来的bpdu，与自己所持有的根优先级向量进行比较，经比较，在交换机4发来的消息中所持有的根优先级向量，没有交换机2持有的优先级向量优，交换机2会回复一个bpdu给交换机4，在bpdu中包含交换机2持有的优先级向量，交换机2持有的优先级向量对于交换机4来说，是比交换机4持有的根信息更优的根优先级向量，那么当交换机4收到交换机2发来的bpdu，经比较计算会取bpdu中的根优先级作为新的优先级向量，交换机4选定了新的优先级，同时也认为自己不是网络中的根，1/3端口是新的根优先级向量的来源端口，那么1/3端口就被选定为根端口。 

因为1/3原为阻塞端口，现其需要转变为转发端口，MSTP中规定，如果一个根端口对端所连接的指定端口处于转发状态，那么新的根端口可无延时立即变为转发状态，所以1/3端口立即变为了转发状态，链路过程较快。 

在上述分析，断开交换机1上1/1的线，链路的整个切换过程并未引起其它的消息交互，过程较快完成。 

接通刚刚断开交换机的1到交换机4之间的线路，链路从刚刚的交换机1交换机到2到交换机4，倒换为从交换机1直接到交换机4。 

交换机1的1/1端口up，端口角色变为指定端口并且状态置为阻塞状态，向交换机4发送带有proposaling标志的bpdu报文；同样交换机4的1/1端口up，端口角色变为指定端口并且状态置为阻塞状态，向交换机1发送带有proposaling的bpdu报文。交换机4收到交换机1发来的bpdu报文，交换机4把收到的bpdu报文中持有的优先级向量和自身持有的优先级向量进行比较，发现从端口1/1所接收到的根信息要优于从端口1/3所接受到的根信息，从端口1/1收到的优先级向量中路径开销更小，所以根端口要重新进行选定。 

经MSTP重新进行端口角色选择的计算，端口1/3被计算为指定端口，迅速被阻塞掉，1/1端口被计算为新的根端口，另外在端口1/1上收到的消息中也携带了agreement标志位，对于交换机4的端口1/1发出proposing收到了agreement，根端口在发出proposing并收到agreement端口状态迁为转发状态。 

此时虽交换机4的1/1端口已经变为转发状态，但是交换机1的1/1尚未转变为转发状态，交换机1的1/1若要转为转发状态，也需完成一次握手，即交换机1发送proposing给交换机4，交换机4的1/1以根为角色发出agreement消息，当交换机1收到交换机4发出的agreement，交换机1的端口1/1将转为转发状态。 

需要注意的是交换机4发出的agreement如果不是以根角色发出的，那么交换机1的端 口1/1也不会转为转发状态，也就是交换机4的1/1变为根后发出的agreement才有效，否则发出的agreement，都是无效的，都不能使交换机1的1/1端口转变为转发状态。 

交换机1的1/1端口变为转发状态交换机1到交换机4之间的路才真正的通起来，在本次链路的切换的过程中，首先是交换机4的端口1/3变为阻塞，使交换机4和交换机3之间的数据通路断了开来，然后经过一次握手交换机4的端口1/1变为了转发状态，然后又经过一次握手交换机1的端口1/1变为转发状态，交换机1的1/1端口变成转发时，交换机3和交换机4又重新从断状态转为了通状态。 

如上所述，数据通路从断开到再次在新的通路上通起来，这个时间的长短，决定倒换性能的优劣，对于单个实例来说，以上过程没有问题。对于多个实例，上述的握手过程每个实例都要完成。 

对于多个实例的握手过程，MSTP有如下的三个特点，一，发送报文以事件和定时器事件为驱动，多个实例当其中有一个实例发生了某事件，那么MSTP将立即发送一个bpdu出去，不管其它实例是否有发送报文的需求。二，一个bpdu报文中携带所有的实例信息，也就是说10个实例，如果有一个实例要发送bpdu，那么这个bpdu就要携带其它9个10实例的信息。三，收端收到bpdu的时候，收端是无法判断这个bpdu是由于那个实例事件的驱动而被发送出去的，所以收端要对bpdu中携带的所有实例信息进行进行处理，不管是否需要。 

三层倒换过程流程分析 

三层倒换，需要跨VLAN，数据会穿越不同实例，需要虚拟网关(VRRP)对数据进行转发，因此测试环境要在二层的基础上做一定的更改。 

要在3的实例5上发送数据，但是要在4上的实例6上接收数据，实例5的虚拟网关(VRRP)在1上是主，在2上是备，IP为192.168.5.254；实例6的虚拟网关(VRRP)在2上是主，在1上是备，IP为192.168.6.254。 

设备1上的VRRP配置： 

VrId<1> 

 State is Backup 

 Virtual IP is 192.168.6.254(Not IP owner) 

 Interface is Vlan6 

 Priority is 1 

 Advertisement interval is 1 sec 

 Preempt mode is TRUE 

VrId<2> 

 State is Master 

 Virtual IP is 192.168.5.254(Not IP owner) 

 Interface is Vlan5 

 Priority is 2 

 Advertisement interval is 1 sec 

 Preempt mode is TRUE 

设备2上的VRRP配置： 

VrId<1> 

 State is Master 

 Virtual IP is 192.168.6.254(Not IP owner) 

 Interface is Vlan6 

 Priority is 2 

 Advertisement interval is 1sec 

 Preempt mode is TRUE 

VrId<2> 

 State is Backup 

 Virtual IP is 192.168.5.254(Not IP owner) 

 Interface is Vlan5 

 Priority is 1 

 Advertisement interval is 1sec 

 Preempt mode is TRUE 

所发送的测试报文为三层报文，报文中mac地址设置为对应的虚拟网关的地址，目的地址设置为和4相连的主机的IP地址。 

数据流向，数据从和3相连的主机发出，在1上找到其网关，网关会向Vlan5(实例5)中的数据，转给目的IP对应的Vlan 6(实例6)，因为实例6中4的1/1端口是阻塞状态，所以实例6将数据通过1的1/8端口发送给2，由2再到4，整个数据流向为3-1-2-4。 

测试操作，断开1上的1/3使数据链路发生倒换，数据的流向变为3-2-1-2-4，数据为什么会走这样的路径呢？原因是，断开1和3之间的连线，使实例5中3的1/1端口由原来的替换端口变成新的根端口，由阻塞变成了转发状态，首先数据要通过3-2-1找到实例5的网关，通过实例5的网关将数据转到目的IP地址对应Vlan6中，因为在实例6里，4的1/1端口是替换端口，处于阻塞状态，因此实例6中的数据走1-2-4的路径到达4。 

对于端口角色变化，和在端口角色变化过程中的消息交互，过程同2层中的分析，在此就不做重复叙述了。 

连通1和3之间的连线也同样导致链路的切换，过程整好同上述过程相反，在这里不做详细叙述了。 

在链路倒换过程中，记录丢包的个数，根据丢包个数来判断其倒换性能，发现倒换时间 远超过1秒。 

三层和二层数据转发过程有一很大不同，就是三层数据是根据ARP表进行数据转发的，而每次拓扑变化，MSTP都要根据一定的规则进行清表操作，规则是TC报文从变转发的端口发起，该消息流经拓扑中的各个设备，直到传遍整个网络，TC报文从哪一端口发出，该端口就要按端口清ARP表。 

第一个问题是TC报文未打包发出，这样造成了，各实例TC报文的重复携带发出，是同一实例的TC报文被处理了多次，推理得出ARP表也被清了多次，例如例子中的拓扑，3的1/1端口发送各实例的TC报文，每个实例发送一次TC报文，而且这个消息中同时也携带其它实例的TC标志，这样TC报文从1/1端口发出，十个实例发10次，1/1端口清表10次，TC报文传到2由2的1/8和1/3端口再次发出时，TC报文就会转变为100个，1/8和1/3分别发出100个TC报文，也就清ARP表100次，因此必然导致性能较慢，解决这个问题的方法就是将TC报文打包发出，若10个实例都要发送TC报文将10个TC打包成一个报文发出，这就消除了每一个传递TC报文的节点对TC报文的重复处理。 

第二个问题，我们可以从上述可以看到，2的端口1/8和1/3端口分别清了10次表，是因为有10个实例，每个实例都要对各个端口清一次表，这里可以改进为，10个实例都要对某一端口进行清表的时候，10个实例统一对该端口清一次，而不是清10次，这样大大减少了清表的次数，有效的提高了性能。 

第三个问题，hello timer是2秒，TC timer是4秒，hello报文中将携带TC标志，在4秒的TC timer中，可能会有两个hello报文发出，相当于发出了三个TC报文，在第二跳，TC报文发出的数量就会增加至9个，TC报文还会逐跳的增加，TC传播的越远，TC增加的就越多，TC的增多也就相当于ARP清表的次数也在不断的增多。用上例对这个过程进行分析，3发出一个TC报文，在TC timer没过期之前，又发出了两个hello报文，hello报文中携带TC标志，就相当于发出了三个TC报文，3的1/1清三次表。2收到三个TC报文，就要在1/8和1/3端口上分别转出这三个TC报文，同时1/8和1/3端口也要在TC timer时间内发送两个hello报文，所以在1/8和1/3端口上分别共发出了5个TC报文，同理TC报文如果从1的端口再转出，TC报文的个数就会变成7个，随着跳数的增加TC报文发送个数在增加，清表的次数也在增加。解决这个问题的方法是，让hello报文不携带TC标志，有效的解决了这个问题，减少了TC报文逐跳增加的这种可能性，TC报文不增加，ARP清表的次数也不会随之增加，有效的提高了性能。 

图8指示了hello报文中携带TC示意图，直观的表现出导致TC报文增多的情况。 

图9指示了hello报文中不携带TC示意图，直观的表现出修改后的数据流程。 

以上所述仅为本发明的过程及方法实施例，并不用以限制本发明，凡在本发明的精神和实质之内所做的任何修改、等同替换、改进等，均应包含在本发明保护范围之内。 

Claims (5)

1.一种三层网络多生成树链路倒换性能优化的实现方法，其特征在于：将所有的拓扑变化（TC）进行打包，统一发送；改变清表的过程，在一次拓扑变化的过程中，多个实例都要对一个端口按端口清ARP表时，只对该端口ARP统一清表一次；并在hello报文中不携带拓扑变化（TC），将所有的拓扑变化（TC）进行打包和统一发送的具体实现包括如下两处，一处在端口变转发，要发出拓扑变化（TC）标志处；另一处为收到拓扑变化（TC）后的处理；

⑴端口变转发要发送拓扑变化（TC），即首次发出拓扑变化（TC），将多实例的拓扑变化（TC）打包统一发送，在一个报文中，携带所有应该带拓扑变化（TC）的实例；

⑵收到拓扑变化（TC），程序会转到拓扑变化机（TCM），需在各实例拓扑变化机（TCM）处理之前保存下报文发送个数（tx_count）的值，并将其临时设置为发包上限（TX_HOLD_COUNT），在拓扑变化机（TCM）处理完之后，将报文发送个数（tx_count）设置回前边所保存原值，并调用发送报文的状态机发送报文，该报文将会携带所有实例的拓扑变化（TC）。

2.根据权利要求1所述的方法，其特征在于，端口变转发要发送拓扑变化（TC）和收到拓扑变化（TC）后的处理的具体实现步骤如下：

⑴依次保存所有端口当前的报文发送个数（tx_count）值，并将其设置为发包上限（TX_HOLD_COUNT），直至所有端口处理完毕；

⑵依次以实例为参数调用端口信息状态机，在端口信息状态机中，以实例为参数调用端口角色选择状态机，直至所有实例处理完毕；

如果端口角色从替换角色变为指定角色或根角色，设置“是否首发拓扑变化（TC）”标志为true，否则设为false；

⑶设置“普通报文是否携带拓扑变化（TC）”标志为true或false，如果其它报文带拓扑变化（TC）标志，设置为true，否则设置为false；

⑷取回在步骤（1）中已保存的所有端口的报文发送个数（tx_count）值；如果报文发送个数（tx_count）与发包上限（TX_HOLD_COUNT）相等，则给报文发送个数（tx_count）减一；

⑸判断“是否首发拓扑变化（TC）”或“普通报文是否携带拓扑变化（TC）”标志只要有一个为true,端口发送的报文就要携带拓扑变化（TC），并设置“是否首发拓扑变化（TC）”标志为默认值false；否则端口发送的报文不携带拓扑变化（TC）；

⑹循环⑷-⑸，直至所有端口处理完毕；

⑺设置“普通报文是否携带拓扑变化（TC）”标志为true。

3.根据权利要求1所述的方法，其特征在于，通过端口清表任务信号量的方式进行限制，该信号量保证是否要做清表的动作；具体步骤为：

⑴持有端口清表任务信号量，这样清表任务会等待；

⑵依次判断端口实例链表中的实例是否需要清表，如果需要，设置由清表函数所使用的端口映射（map）；

⑶等端口上的全部实例添加到清表的端口映射（map）中后，释放该信号量；这样清表任务只会对多个实例要清多次的某一端口清一次，而不是各个实例分别要清一次。

4.根据权利要求1所述的方法，其特征在于，hello报文中不携带拓扑变化（TC）的具体步骤：

⑴设置一个“是否发送拓扑变化（TC）标志”，在发送hello前将该标志置为false；程序中在对报文进行编码的地方，检测该标志，该标志位被置为false的时候不将拓扑变化（TC）打包在报文中；

⑵判断“是否发送拓扑变化（TC）标志”是否被设为true；如果设为true，发送带携带拓扑变化（TC）的hello报文；设为false，发送不携带拓扑变化（TC）的hello报文；

⑶在发完后，再设置“是否发送拓扑变化（TC）标志”为true。

5.根据权利要求1所述的方法，其特征在于，该方法还包含，为了尽可能的减少拓扑改变消息，在非拓扑改变事件引发的报文，不携带拓扑变化（TC），具体处理过程如下：

⑴设置一个“是否发送拓扑变化（TC）标志”，在发送hello前将该标志置为false；程序中在对报文进行编码的地方，检测该标志，该标志位被置为false的时候不将拓扑变化（TC）打包在报文中；

⑵判断“是否发送拓扑变化（TC）标志”是否被设为true；如果设为true，发送带携带拓扑变化（TC）的hello报文；设为false，发送不携带拓扑变化（TC）的hello报文；

⑶在发完后，再设置“是否发送拓扑变化（TC）标志”为true。

Images