CN103763135B - 一种pe设备流量调度方法及装置 - Google Patents
一种pe设备流量调度方法及装置 Download PDFInfo
- Publication number
- CN103763135B CN103763135B CN201410006143.3A CN201410006143A CN103763135B CN 103763135 B CN103763135 B CN 103763135B CN 201410006143 A CN201410006143 A CN 201410006143A CN 103763135 B CN103763135 B CN 103763135B
- Authority
- CN
- China
- Prior art keywords
- port
- trunk
- uplink
- hash
- positions
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Abstract
本发明提供一种PE流量调度方法及装置,应用于VCF系统的PE设备上,该方法包括以下步骤:为第一交换芯片创建Trunk a及Trunk b,其中Trunk a包括N个Hash位置,该N个Hash位置分别被分配给G1以及G2的端口;Trunk b包括N个Hash位置,该N个Hash位置分别分配给G2的端口;所述G1的端口的Trunk标识为a,所述G2的端口Trunk标识为b;对第二交换芯片进行相同的处理;向第一交换芯片以及第二交换芯片下发PE上行流量的本地转发表项,其中该本地转发表项的出口为该交换芯片的上行端口;根据上行端口的上行链路状态的变化相应将对应Trunk中至少一个Hash位置进行重新分配。相较于现有技术,本发明能够将上行流量更加均匀地分担到两个交换芯片的各个上行链路上去。
Description
技术领域
本发明涉及通信技术领域,尤其涉及一种PE设备流量调度方法及装置。
背景技术
随着网络规模的扩大,网络设备数量随之增大,网络管理成为数据中心基础设施管理中的一个棘手问题。另一方面,现代大数据中心对网络提供给服务器的端口密度也提出了更高的要求,例如万台服务器的规模已是互联网数据中心现实中的普遍需求。端口扩展技术作为提高接入设备端口密度的一种有效手段逐渐成熟并获得了业界的认可。
VCF纵向虚拟化技术(Vertical Converged Framework,纵向融合框架)即是该技术的一种实现方式,满足数据中心虚拟化高密接入并可以简化管理。VCF在纵向维度上支持对系统进行异构扩展,即在形成一台逻辑虚拟设备的基础上,把一台盒式设备作为一块远程的接口板加入主设备系统,以达到扩展主设备系统的I/O端口能力和进行集中控制管理的目的。
另一种网络设备虚拟化的技术叫做弹性智能架构IRF,其是一种典型的堆叠技术。在堆叠设备内部各个成员设备按角色可分为Master和Slave。Slave在一定条件下可转变为Master,两者业务处理能力是同一水平的。对于VCF来说,设备内部各个成员按角色分为CB(Controlling Bridge,控制桥)设备和PE(Port Extender,端口扩展)设备两种。CB表示控制设备,PE表示纵向扩展设备,即端口扩展器(或称远程接口板)。通常来说,PE设备的能力不足以充当CB,因此VCF中PE与CB的角色通常是不能互相转换的,这是VCF与IRF之间一个重要的不同点。VCF与IRF另一个不同点是,VCF的在异构性和扩展性上更强。
在实际组网过程中,可以使用IRF设备作为VCF中的CB设备,这相当于将VCF与IRF两项技术充分融合,发挥各自的优势。但是深度融合的过程中,PE设备依然存在流量分担不均匀的问题,甚至严重失衡的问题。
发明内容
有鉴于此,本发明提供一种PE流量调度方法,应用于VCF系统的PE设备上,其中该VCF系统还包括CB设备,所述PE设备包括第一交换芯片以及第二交换芯片,所述第一交换芯片包括面向CB的上行端口集合G1以及与第二交换芯片级联的级联端口集合G2,第二交换芯片包括面向CB的上行端口G3以及与第一交换芯片级联的级联端口集合G4;其中任意一个端口集合至少包括一个端口,其中该方法包括以下步骤:
A,为第一交换芯片创建第一聚合口Trunk a及第二聚合口Trunk b,其中Trunk a包括N个Hash位置,该N个Hash位置分别被分配给G1以及G2的端口;Trunk b包括N个Hash位置,该N个Hash位置分别分配给G2的端口;所述G1的端口的Trunk标识为a,所述G2的端口Trunk标识为b;其中N为大于或等于2的自然数;
B,为第二交换芯片创建第三聚合口Trunk c及第四聚合口Trunk d,其中Trunk c包括N个Hash位置,该N个Hash位置分别被分配给G3以及G4的端口;Trunk d包括N个Hash位置,该N个Hash位置分别被分配给G4的端口;所述G3的端口的Trunk标识为c,所述G4的端口的Trunk标识为d;其中Trunk a中G1的端口分配到的Hash位置集合与Trunk c中G4的端口分配到的Hash位置集合相同,Trunk a中G2的端口分配到的Hash位置集合与Trunk c中G3的端口分配到的Hash位置集合相同;
C,向第一交换芯片以及第二交换芯片下发PE上行流量的本地转发表项,其中该本地转发表项的出口为该交换芯片的上行端口;
D,检测上行端口的上行链路状态的变化;并根据上行端口的上行链路状态的变化相应将对应Trunk中至少一个Hash位置进行重新分配。
本发明还提供一种PE流量调度装置,应用于VCF系统的PE设备上,其中该VCF系统还包括CB设备,所述PE设备包括第一交换芯片以及第二交换芯片,所述第一交换芯片包括面向CB的上行端口集合G1以及与第二交换芯片级联的级联端口集合G2,第二交换芯片包括面向CB的上行端口G3以及与第一交换芯片级联的级联端口集合G4;其中任意一个端口集合至少包括一个端口,其中该装置包括:聚合管理单元、故障检测单元以及表项管理单元,其中:
聚合管理单元,用于为第一交换芯片创建第一聚合口Trunk a及第二聚合口Trunkb,其中Trunk a包括N个Hash位置,该N个Hash位置分别被分配给G1以及G2的端口;Trunk b包括N个Hash位置,该N个Hash位置分别分配给G2的端口;所述G1的端口的Trunk标识为a,所述G2的端口Trunk标识为b;其中N为大于或等于2的自然数;
聚合管理单元,进一步用于为第二交换芯片创建第三聚合口Trunk c及第四聚合口Trunk d,其中Trunk c包括N个Hash位置,该N个Hash位置分别被分配给G3以及G4的端口;Trunk d包括N个Hash位置,该N个Hash位置分别被分配给G4的端口;所述G3的端口的Trunk标识为c,所述G4的端口的Trunk标识为d;其中Trunk a中G1的端口分配到的Hash位置集合与Trunk c中G4的端口分配到的Hash位置集合相同,Trunk a中G2的端口分配到的Hash位置集合与Trunk c中G3的端口分配到的Hash位置集合相同;
表项管理单元,用于向第一交换芯片以及第二交换芯片下发PE上行流量的本地转发表项,其中该本地转发表项的出口为该交换芯片的上行端口;
故障检测单元,用于检测上行端口的上行链路状态的变化;
其中所述聚合管理单元进一步用于根据上行端口的上行链路状态的变化相应将对应Trunk中至少一个Hash位置进行重新分配。
相较于现有技术,本发明能够将上行流量更加均匀地分担到PE的各个上行链路上去,解决了跨芯片进行负载分担的难题。
附图说明
图1是一个典型的VCF系统示意图;
图2是一种使用ECMP机制实现负载分担的VCF系统示意图;
图3是一种使用上行流量Pinning机制的VCF系统示意图;
图4是本发明一种实施方式中装置逻辑结构以及硬件原理图;
图5是本发明一种实施方式中处理流程图;
图6是本发明一种实施方式中VCF系统流量负载分担示意图。
具体实施方式
随着VCF技术的进步,PE可以实现多归属的接入方式。请参考图1,在该VCF中,一个PE归属到两个CB,分别是CB1和CB2。多归属的实现方式有多方面的优点:
(1)将CB上IRF的可靠性传递到PE。例如图1中,如果CB1故障,则PE的流量可全部倒换到CB2,由CB2完成全部数据的转发。
(2)PE上需要转发的业务数据分配到不同的CB,CB之间转发业务均匀分担;如此可以避免单个CB负载过高引发延迟或丢包等问题。
对于第(2)点而言,这个优势往往难以实现,目前不少交换芯片不能支持Higig(美国博通公司推出的串行总线互联技术)端口跨芯片聚合,所以无法通过端口聚合在多个上行链路之间进行流量分担。请参考图1,上行链路1到4之间,无法通过端口聚合来实现负载分担。
请参考图2,一种解决方案是通过等价路径(Equal-Cost Multipath Routing,ECMP)的方式来解决该问题。这个方式中,PE的出方向VCF端口可以视为是等价的。通过报文MAC字段和IP字段来进行哈希Hash处理,然后得到一条路径,该方法能够较好地保证从PE出方向的报文流量能够进行比较均匀的负载分担。然而这种该种方式只对承载有IP报文的二层报文有效,对于普通一个没有承载IP报文的二层报文没有任何效果。
请参考图3,另一种解决方案是上行流量Pinning(固定)机制。上行流量采用固定端口入且固定端口出的方式,PE的业务口根据上行端口数量划分组,同一组业务口的流量固定从同一条上行链路出。从PE的0芯片端口上行的流量,会选择“上行链路1”,而“上行链路2”,则不会有流量,从而造成带宽浪费。
为了解决当前芯片存在的上述问题,本发明从控制层面提出一种PE流量调度方案来解决该问题。在一种实施方式中,本发明提供一种PE流量调度装置,该装置应用于VCF系统的PE设备上,其中该VCF系统还包括CB设备,所述PE设备包括第一交换芯片以及第二交换芯片,所述第一交换芯片包括面向CB的上行端口集合G1以及与第二交换芯片级联的级联端口集合G2,第二交换芯片包括面向CB的上行端口G3以及与第一交换芯片级联的级联端口集合G4;其中任意一个端口集合至少包括一个端口。该装置位于控制层面,用于对芯片进行管理调度以将芯片对流量的转发进行更加合理的规划。以计算机软件实现(并不排除其他实现方式)为例,请参考图4,从逻辑上来说,该装置可以理解为CPU将相应的计算机程序读取到内存中运行形成的逻辑装置,该装置包括,聚合管理单元41、故障检测单元42以及表项管理单元43。该装置在运行过程中执行如下处理过程。
步骤501,聚合管理单元41为第一交换芯片创建第一聚合口Trunk a及第二聚合口Trunk b,其中Trunk a包括N个Hash位置,该N个Hash位置分别被分配给G1以及G2的端口;Trunk b包括N个Hash位置,该N个Hash位置分别被分配给G2的端口;所述G1的端口的Trunk标识为a,所述G2的端口Trunk标识为b;其中N为大于或等于2的自然数;
步骤502,聚合管理单元41为第二交换芯片创建第三聚合口Trunk c及第四聚合口Trunk d,其中Trunk c包括N个Hash位置,该N个Hash位置分别分配给G3以及G4的端口;Trunk d包括N个Hash位置,该N个Hash位置分别分配给G4的端口;所述G3的端口的Trunk标识为c,所述G4的端口的Trunk标识为d;其中Trunk a中G1的端口分配到的Hash位置集合与Trunk c中G4的端口分配到的Hash位置集合相同,Trunk a中G2的端口分配到的Hash位置集合与Trunk c中G3的端口分配到的Hash位置集合相同;
步骤503,表项管理单元43向第一交换芯片以及第二交换芯片下发PE上行流量的本地转发表项,其中该本地转发表项的出口为对应交换芯片的上行端口;
步骤504,故障检测单元42检测上行端口的上行链路状态的变化;
步骤505,聚合管理单元41根据上行端口的上行链路状态的变化相应将对应Trunk中至少一个Hash位置进行重新分配。
本发明PE上的多个芯片的上行端口以及芯片间的级联端口被有序地使用聚合技术联系起来,这样的规划可以使得上行流量能够更加均匀地从两个芯片的上行端口分担出去。以下将通过具体的示例来介绍经过上述处理之后第一及第二交换芯片对流量的分担结果。
请参考图6,假设PE设备包括两个芯片,分别标号为0和1,芯片0和芯片1均包括面向CB方向的上行端口,芯片0的上行端口集合G1中包括上行端口P1和P2,而芯片1的上行端口集合G3包括上行端口P3和P4。芯片0的级联端口集合G2包括两个级联端口P3以及P4,分别连接芯片1级联端口集合G4的两个级联端口P1和P2。值得注意的是,芯片0和芯片1都有P1口,但是在全局来看,这两个端口不是同一个端口,两者有着不同的标识。芯片0的P1的端口标识可以理解为Chip0-P1,芯片1的P1的端口标识可以理解为Chip1-P1。在本发明中,控制层面初始针对芯片0和芯片1分别下发表1和表2所示的聚合表。需要说明的是:以下的所示聚合表仅仅是示例性的和原理性的。
表1
表2
用该聚合表1和表2来指导芯片0和芯片1对于上行报文流量的转发可以将上行报文流量更加均匀地分担开。对于芯片0本地上行报文流量而言,报文流量的入端口一定是P1~P4之外的其他端口(一般是面向主机的接入端口)进入芯片0的,对于这些报文流量中的每个报文来说,其都需要上送到CB来进行转发。对于上行报文流量中任意一个单播报文而言,其进入芯片0之后,芯片0查询表1进行处理。芯片0查询表1的处理过程包括以下步骤:
步骤701,查询本地转发表确定出口为上行端口P1或P2,转步骤702;
步骤702,继续查询表1中第3条表项确定上行端口P1或P2的聚合口标识PORT_TRUNK_ID为1,确定聚合口1Trunk1为该报文的出口;
步骤703,根据预定Hash算法对报文进行Hash运算,选择与Hash运算结果匹配的端口作为报文的实际出口。
通过步骤701至步骤703,上行报文流量被基本均匀地分到芯片0的P1至P4这4个端口上发送出去;每个端口发送的流量为整体上行报文流量的25%,这意味着通过芯片0的P3和P4进入芯片1的流量为上行报文流量的50%。报文进入芯片1之后,芯片1查询表2进行处理,处理过程包括如下步骤:
步骤801,查询本地转发表确定出口为上行端口P3或P4,转步骤802;
步骤802,继续查询表2第3条表项确定上行端口P3或P4的PORT_TRUNK_ID,确定Trunk1为该报文的出口;
步骤803,根据预定Hash算法对报文进行Hash运算,选择与Hash运算结果匹配的端口作为报文的实际出口。
上行报文流量从其他端口(通常是主机的接入端口)进入芯片0之后,对于芯片0而言,其目标是要将该报文转发给CB。对这一需求,在本发明中,可以下发静态的本地转发表项到芯片0,比如说下发一个ACL,这个ACL可以是所有报文的出口为P1。这样上行报文进入之后查询本地转发表命中该ACL,得到报文的出口为P1或者P2。但是由于P1和P2都是聚合口的成员,其属性上具有聚合成员属性,因此需要查询聚合表找到对应的聚合口作为出口。根据表1找到的聚合口为Trunk1,因此需要在Trunk 1内部做Hash,这样流量就可以均匀地分担到P1至P4上发送。也就是说50%的流量经过步骤701-703的处理之后进入了芯片1。
在本发明中,芯片0的P3与P4分配到的两个Hash位置与芯片1的P3和P4的两个Hash位置是相同的,理论上来说,G1分配到的Hash位置集合如果与G3分配到的Hash位置集合相同,那么流量便可均匀地分担开。请参考表3,芯片对报文的Hash运算结果可能有很多种,但是每个运算结果有一个对应的Hash位置。比如说X1和X5这两个Hash运算结果都对应Hash位置1。而每个Hash位置上填写的端口标识决定了流量从那个端口出去,也就是说,Hash位置1填写P1端口的标识,那么这个Hash位置相当于分配给了P1。如果四个Hash位置上填写的端口标识不同,则流量就可以分担到不同的四个端口上发送出去。
在本实施方式中,芯片0的P3和芯片1的P3的Hash位置都为3。因此只要芯片0和芯片1采用相同的Hash算法,比如说系统开发时选择相同规格型号的芯片,那么对于报文3而言,其先在芯片0做Hash运算的结果是X3,X3对应Hash位置3,Trunk1中Hash位置3分配给了P3,因此报文从芯片0的P3发送到芯片1。报文通过芯片0的P3进入芯片1后,芯片1执行步骤801-803过程同样对该报文进行Hash运算,其Hash运算结果仍然是X3,该结果一样对应Trunk2中的Hash位置3,因此报文同样从芯片1的P3发送出去。同样的道理,对于从芯片0的P4进入芯片1的报文而言,其最终会从芯片1的P4发送出去。因此从级联端口过来需要上行的这部分报文流量永远不会从芯片1的P1和P2发送出去,虽然P1和P2的Hash位置在Hash运算对比的范围内。本实施方式将芯片0的芯片级联口与芯片1的上行端口的Hash位置设为相同的Hash位置,这就使得从芯片0本地进入的上行报文流量最终被均匀地分担到芯片0的P1和P2以及芯片1的P3和P4上转发出去到达CB。
报文 | Hash结果 | Hash位置 | 端口 |
报文1 | X1 | 1 | P1 |
报文2 | X2 | 2 | P2 |
报文3 | X3 | 3 | P3 |
报文4 | X4 | 4 | P4 |
报文5 | X5 | 1 | P1 |
报文6 | X6 | 2 | P2 |
…… | …… | …… | …… |
表3
同样的道理,从芯片1进入的本地上行报文流量,会有着与上述相同的处理流程,其中50%的流量通过自身的P3和P4发送出去到达CB,另外50%的流量通过自身的P1和P2进入芯片0之后,经过同样的Hash处理之后从芯片0的P1和P2发送出去到达CB。由此可见在上行方向上,整体的流量可以被均匀地分配到四个上行端口上发送给CB。
在下行方向上,仍然以芯片0为例,假设CB发送过来的下行报文流量从芯片0的P1进入芯片0,此时芯片0查询表1的第3条确定入端口的PORT_TRUNK_ID为1,即该报文的入口为Trunk1。此时报文的出口肯定为Trunk1以外的其他端口。在出口上,由于PE设备事实上就是CB的一个远程接口板,PE的接入端口也就是CB的接入端口。因此CB一侧做完真正的二层转发之后,CB会同时告知PE芯片0其对该下行报文的转发结果,这个转发结果中会指明报文的实际出口,而这个实际出口肯定是芯片0或者芯片1的接入端口。
假设下行报文的出口是芯片0的接入端口,那么芯片0根据CB提供的实际出口直接从该接入端口将报文发送出去即可。假设报文的出口是芯片1的接入端口。按照Higig这样的芯片间协议,芯片0应该从级联端口P3或P4将报文转发给芯片1。但是由于P3和P4是属于Trunk1的,报文的入口是Trunk1,因此芯片0需要遵循入口不回转的内部处理逻辑,报文不能直接从P3和P4发送出去。另一方面,由于本发明中引入了Trunk2,Trunk2实际上是一个级联聚合口,因此从芯片1的处理逻辑上,从Trunk2发送就不会形成入口回转问题。此时芯片0选择Trunk2来将下行报文发送给芯片1。下行报文在Trunk2中进行Hash处理,芯片0中Trunk2的Hash位置有4个,但Trunk2中4个Hash位置平均分配给了P3和P4,因此报文只会从P3和P4发送出去。这样一来,出口是芯片1的下行报文流量中有50%被分担到P3,另外50%被分担到P4。接下来下行报文进入芯片1之后,芯片1根据CB给出的实际出口将报文从对应的接入端口发送出去。对于从芯片1进入的下行报文流量的处理过程类似,不再一一赘述。
以上描述了单播报文流量的上行和下行处理过程,对于多播报文流量,比如广播或者组播或者未知单播来说,处理的原理是相同的,只不过芯片需要利用自身的防环机制来抑制部分出口的报文发送,从而避免出现环路的状况,具体过程这里不再详细描述。本发明对于芯片上行端口的数量并无限制,其可以1个,也可以超过2个,聚合表原理类似。请参考表4的示例,整个处理过程与之前的描述的过程一致,只是端口数量上的差异。
表4
考虑到芯片的上行端口所连接的上行链路可能会发生故障,也有可能发生故障恢复正常的情况,上行端口的上行链路状态变化时需要相应地更新芯片上指向相应端口的Hash位置。针对故障或者故障恢复正常,本发明也有相应的处理机制。当G1中一个上行端口的上行链路发生故障时,若该故障的上行端口为芯片本地转发表项的出口,则表项管理单元将该本地转发表项的出口修改为其他状态正常的上行口;当G1中所有上行端口的上行链路发生故障时,将表项管理单元则将该本地转发表项的出口修改为G2中的级联端口。
对于聚合管理单元而言,当G1中一个上行端口的上行链路发生故障时,该聚合管理单元在Trunk 1中将该故障端口对应的Hash位置分配给其他正常的上行端口。在G1中所有上行端口的上行链路都故障时,所述聚合管理单元有两种处理方式,一种方式是删除芯片0的Trunk1,这样流量都会走Trunk 2转发芯片1,这种处理方式适应大部分芯片;另一种方式是在芯片0的Trunk 1中将该些故障上行端口对应的Hash位置重新分配给G2的端口,并保持Trunk 1与Trunk 2中各个端口分配到的Hash位置相同;这种方式需要芯片能够支持两个相同Trunk的处理。另一方面来说,由于芯片0已经没有上行口,那么聚合管理单元需要将芯片1的Trunk 1中分配给G3端口的Hash位置分配给G4端口,避免芯片1接入端口进入的流量进入芯片0。
在故障恢复的正常时,对于聚合管理单元而言,当G1中任意一个上行端口的上行链路故障恢复正常时,在Trunk a中保持初始G2的端口分配到的Hash位置数量的前提下,聚合管理单元将所有其他Hash位置以最均匀的方式分配给当前所有正常的上行端口。也就是说,只要G1上有上行端口恢复正常,那么流量应当尽量往芯片0所有正常的上行口上分担;但是不管如何,原来级联端口初始分担的流量比例还应该保持。如果此时恢复正常的上行链路是G1中唯一的正常上行链路,那么聚合管理单元保持G4端口初始分配到的Hash位置的前提下,还需要将芯片1的Trunk 1中原来分配给G4端口的Hash位置重新分配给G3端口,或者简单来说,就是将芯片1中Trunk1和Trunk2中各个端口分配到的Hash位置恢复到初始状态。对于表项管理单元而言,当G1中任意一个上行端口的上行链路故障恢复正常时,检查芯片0本地转发表项的出口是否为级联端口(也就是说之前所有上行链路都故障了),如果是,则将芯片0本地转发表项的出口修改为当前状态正常的上行端口。
仍然以上述例子基础进行详细说明,故障以及故障恢复可以分为以下几种情况:
情况I,假设芯片0的P1的上行链路发生故障,此时将Trunk1中分给P1的Hash位置分配给P2。经过这样的修改之后,原来通过Hash运算通过P1发送出去的上行流量都会从P2发送出去,相当于P2的上行链路接管了原先由P1上行链路承载的流量,请参考表5的示例。相应地,假设原来本地转发表项中的出口是P1,此时表项管理单元则相应将该出口修改为其他正常的上行端口,即本例中的P2。
表5
情况II,当芯片0上行端口P1和P2的上行链路都故障时,那么可以将Trunk1删除,或者将Trunk1中分配给P1和P2的Hash位置分别分配给P3和P4,保持Trunk1和Trunk2中各个端口分配到的Hash位置相同,请参考表6的示例。此时由于本地转发表中的出口变成了P3或P4,这样一来,在步骤701-703中处理,假设此时Trunk1被删除,那么报文将在Trunk2中Hash,这样从芯片0接入端口上来的上行流量将分担到级联端口P3和P4,进而进入芯片1,这样芯片1可以通过自身的上行端口P3和P4将这些流量发给CB。相应地,由于芯片0的上行链路都已经故障,此时从芯片1的接入端口进入的报文,无法从芯片0的上行链路发送给CB,相应地,需要将芯片1的Trunk1的Hash位置进行更新,更新结果请参考表7所示,主要是将芯片1的P1和P2分配到的Hash位置收回,再重新分别分配给自身的上行端口P3和P4,这样一来上行流量就不会被送往芯片0了。
表6
表7
情况III,在表6的基础上,芯片0的上行端口P1的上行链路的故障恢复正常,此时原来被分担到P3和P4上的流量需要回迁到P1上来。首先本地转发表的出口修改为P1,而原来重新分配给P3和P4的Hash位置1以及Hash位置2需要重新分配给P1,请参考表8所示。当然如果后来P2的上行链路也恢复了,那么Hash位置2重新分配给P2,表8又变回了表1。如前所述,由于芯片0的上行链路恢复了,此时表7相应地更新为表2,以允许流量从芯片0发送给CB。
表8
以上所述仅为本发明的较佳实施例而已,并不用以限制本发明,凡在本发明的精神和原则之内,所做的任何修改、等同替换、改进等,均应包含在本发明保护的范围之内。
Claims (10)
1.一种端口扩展PE设备流量调度方法,应用于纵向融合框架VCF系统的PE设备上,其中该VCF系统还包括控制桥CB设备,所述PE设备包括采用相同Hash算法的第一交换芯片以及第二交换芯片,所述第一交换芯片包括面向CB设备的上行端口集合G1以及与第二交换芯片级联的级联端口集合G2,第二交换芯片包括面向CB设备的上行端口集合G3以及与第一交换芯片级联的级联端口集合G4;其中任意一个端口集合至少包括一个端口,其特征在于,该方法包括以下步骤:
A,为第一交换芯片创建第一聚合口Trunk a及第二聚合口Trunk b,其中Trunk a包括N个Hash位置,该N个Hash位置分别被分配给G1以及G2的端口;Trunk b包括N个Hash位置,该N个Hash位置分别分配给G2的端口;所述G1的端口的Trunk标识为a,所述G2的端口Trunk标识为b;其中N大于或等于2的自然数;
B,为第二交换芯片创建第三聚合口Trunk c及第四聚合口Trunk d,其中Trunk c包括N个Hash位置,该N个Hash位置分别被分配给G3以及G4的端口;Trunk d包括N个Hash位置,该N个Hash位置分别被分配给G4的端口;所述G3的端口的Trunk标识为c,所述G4的端口的Trunk标识为d;其中Trunk a中G1的端口分配到的Hash位置集合与Trunk c中G4的端口分配到的Hash位置集合相同,Trunk a中G2的端口分配到的Hash位置集合与Trunk c中G3的端口分配到的Hash位置集合相同;
C,向第一交换芯片下发PE设备上行流量的本地转发表项,其中该本地转发表项的出口为第一交换芯片的上行端口;以及,向第二交换芯片下发PE设备上行流量的本地转发表项,其中该本地转发表项的出口为第二交换芯片的上行端口;
D,检测上行端口的上行链路状态的变化;并根据上行端口的上行链路状态的变化将对应Trunk中至少一个Hash位置进行重新分配。
2.如权利要求1所述的方法,其特征在于:
其中步骤C具体包括:
C1,当G1中一个上行端口的上行链路发生故障时,若该故障的上行端口为本地转发表项的出口,则将该本地转发表项的出口修改为其他状态正常的上行端口;
其中步骤D具体包括:
D1,当G1中一个上行端口的上行链路发生故障时,在Trunk a中将该故障端口对应的Hash位置分配给其他正常的上行端口。
3.如权利要求2所述的方法,其特征在于:
其中步骤C还包括:
C2,当G1中所有上行端口的上行链路都发生故障时,则将该本地转发表项的出口修改为G2中的级联端口;
其中步骤D中还包括:
D2,当G1中所有上行端口的上行链路都故障时,删除Trunk a,并将Trunk c中分配给G3端口的Hash位置分配给G4端口。
4.如权利要求2所述的方法,其特征在于:
其中步骤C还包括:
C2,当G1中所有上行端口的上行链路都发生故障时,则将该本地转发表项的出口修改为G2中的级联端口;
其中步骤D中还包括:
D2,当G1中所有上行端口的上行链路都故障时,在Trunk a中将该些故障上行端口对应的Hash位置重新分配给G2的端口,并保持Trunk a与Trunk b中各个端口分配到的Hash位置相同;将Trunk c中分配给G3端口的Hash位置分配给G4端口。
5.如权利要求3所述的方法,其特征在于:
其中步骤C具体包括:
C3,当G1中任意一个上行端口的上行链路故障恢复正常时,检查第一交换芯片本地转发表项的出口是否为级联端口,如果是,则将本地转发表项的出口修改为当前状态正常的上行端口;
其中步骤D还包括:
D3,当G1中任意一个上行端口的上行链路故障恢复正常时,在Trunk a中保持初始G2的端口分配到的Hash位置数量的前提下,将所有其他Hash位置以最均匀的方式分配给当前所有正常的上行端口,如果此时恢复正常的上行链路是G1中唯一的正常上行链路,则将中Trunk c和Trunk d中各个端口分配到的Hash位置恢复到初始状态。
6.一种端口扩展PE设备流量调度装置,应用于VCF系统的PE设备上,其中该VCF系统还包括CB设备,所述PE设备包括第一交换芯片以及第二交换芯片,所述第一交换芯片包括面向CB设备的上行端口集合G1以及与第二交换芯片级联的级联端口集合G2,第二交换芯片包括面向CB设备的上行端口集合G3以及与第一交换芯片级联的级联端口集合G4;其中任意一个端口集合至少包括一个端口,其中该装置包括:聚合管理单元、故障检测单元以及表项管理单元,其特征在于:
聚合管理单元,用于为第一交换芯片创建第一聚合口Trunk a及第二聚合口Trunk b,其中Trunk a包括N个Hash位置,该N个Hash位置分别被分配给G1以及G2的端口;Trunk b包括N个Hash位置,该N个Hash位置分别分配给G2的端口;所述G1的端口的Trunk标识为a,所述G2的端口Trunk标识为b;其中N为大于或等于2的自然数;
聚合管理单元,进一步用于为第二交换芯片创建第三聚合口Trunk c及第四聚合口Trunk d,其中Trunk c包括N个Hash位置,该N个Hash位置分别被分配给G3以及G4的端口;Trunk d包括N个Hash位置,该N个Hash位置分别被分配给G4的端口;所述G3的端口的Trunk标识为c,所述G4的端口的Trunk标识为d;其中Trunk a中G1的端口分配到的Hash位置集合与Trunk c中G4的端口分配到的Hash位置集合相同,Trunk a中G2的端口分配到的Hash位置集合与Trunk c中G3的端口分配到的Hash位置集合相同;
表项管理单元,用于向第一交换芯片下发PE设备上行流量的本地转发表项,其中该本地转发表项的出口为第一交换芯片的上行端口;以及,向第二交换芯片下发PE设备上行流量的本地转发表项,其中该本地转发表项的出口为第二交换芯片的上行端口;
故障检测单元,用于检测上行端口的上行链路状态的变化;
其中所述聚合管理单元进一步用于根据上行端口的上行链路状态的变化将对应Trunk中至少一个Hash位置进行重新分配。
7.如权利要求6所述的装置,其特征在于:
所述表项管理单元,进一步用于在G1中一个上行端口的上行链路发生故障时,若该故障的上行端口为本地转发表项的出口,则将该本地转发表项的出口修改为其他状态正常的上行端口;
所述聚合管理单元进一步用于在G1中一个上行端口的上行链路发生故障时,在Trunka中将该故障端口对应的Hash位置分配给其他正常的上行端口。
8.如权利要求7所述的装置,其特征在于:
所述表项管理单元进一步用于在G1中所有上行端口的上行链路都发生故障时,将该本地转发表项的出口修改为G2中的级联端口;
所述聚合管理单元进一步用于在G1中所有上行端口的上行链路都发生故障时,删除Trunk a并将Trunk c中分配给G3端口的Hash位置分配给G4端口。
9.如权利要求7所述的装置,其特征在于:所述表项管理单元进一步用于在G1中所有上行端口的上行链路都发生故障时,将该本地转发表项的出口修改为G2中的级联端口;
所述聚合管理单元进一步用于在G1中所有上行端口的上行链路都发生故障时,在Trunk a中将该些故障上行端口对应的Hash位置重新分配给G2的端口,并保持Trunk a与Trunk b中各个端口分配到的Hash位置相同;将Trunk c中分配给G3端口的Hash位置分配给G4端口。
10.如权利要求9所述的装置,其特征在于:
所述表项管理单元进一步用于在G1中任意一个上行端口的上行链路故障恢复正常时,检查第一交换芯片本地转发表项的出口是否为级联端口,如果是,则将本地转发表项的出口修改为当前状态正常的上行端口;
所述聚合管理单元进一步用于在G1中任意一个上行端口的上行链路故障恢复正常时,在Trunk a中保持初始G2的端口分配到的Hash位置数量的前提下,将所有其他Hash位置以最均匀的方式分配给当前所有正常的上行端口,并且如果此时恢复正常的上行链路是G1中唯一的正常上行链路,则将中Trunk c和Trunk d中各个端口分配到的Hash位置恢复到初始状态。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201410006143.3A CN103763135B (zh) | 2014-01-06 | 2014-01-06 | 一种pe设备流量调度方法及装置 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201410006143.3A CN103763135B (zh) | 2014-01-06 | 2014-01-06 | 一种pe设备流量调度方法及装置 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN103763135A CN103763135A (zh) | 2014-04-30 |
CN103763135B true CN103763135B (zh) | 2017-05-10 |
Family
ID=50530298
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201410006143.3A Active CN103763135B (zh) | 2014-01-06 | 2014-01-06 | 一种pe设备流量调度方法及装置 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN103763135B (zh) |
Families Citing this family (12)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN105337851B (zh) * | 2014-07-02 | 2018-11-27 | 新华三技术有限公司 | 一种报文处理方法及端口扩展板 |
CN104243358B (zh) * | 2014-09-18 | 2018-10-26 | 新华三技术有限公司 | Vcf系统中pe设备软件加载的方法以及装置 |
CN106941453A (zh) * | 2016-01-04 | 2017-07-11 | 中兴通讯股份有限公司 | 数据发送方法及装置 |
CN107547419B (zh) * | 2016-06-28 | 2020-08-04 | 新华三技术有限公司 | 一种扩展网桥系统以及报文转发方法及装置 |
CN106254282B (zh) * | 2016-09-30 | 2019-09-06 | 新华三技术有限公司 | 链路聚合的实现方法及装置 |
CN106533775B (zh) * | 2016-11-28 | 2019-09-06 | 迈普通信技术股份有限公司 | 虚拟化成员设备及邻居发现方法 |
CN106533889A (zh) * | 2016-12-30 | 2017-03-22 | 盛科网络(苏州)有限公司 | 芯片中bpe跨端口扩展设备实现链路聚合的方法 |
CN107547247B (zh) * | 2017-05-31 | 2020-11-06 | 新华三技术有限公司 | 智能弹性架构中的三层管理网ip地址分配方法和装置 |
CN109728991B (zh) * | 2017-10-31 | 2021-11-02 | 中兴通讯股份有限公司 | 一种快速恢复扩展桥系统的方法、装置、设备及存储介质 |
CN108768897B (zh) * | 2018-06-28 | 2021-02-05 | 新华三技术有限公司 | 端口扩展设备和堆叠系统 |
CN109005110B (zh) * | 2018-08-29 | 2021-05-28 | 新华三技术有限公司合肥分公司 | 生成聚合路由的方法及装置 |
CN113422735B (zh) * | 2021-06-22 | 2022-08-05 | 恒安嘉新(北京)科技股份公司 | 负载均衡配置方法、汇聚分流器及介质 |
Citations (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN102035741A (zh) * | 2010-12-20 | 2011-04-27 | 中兴通讯股份有限公司 | 一种环形拓扑网络中单播报文的转发方法及设备 |
CN103166874A (zh) * | 2013-03-25 | 2013-06-19 | 杭州华三通信技术有限公司 | 一种报文转发方法及设备 |
Family Cites Families (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2009211140A (ja) * | 2008-02-29 | 2009-09-17 | Hitachi Ltd | ストレージシステム及びその記憶媒体管理方法 |
US8798064B2 (en) * | 2011-06-06 | 2014-08-05 | Broadcom Corporation | Method and system of frame forwarding with link aggregation in distributed ethernet bridges |
-
2014
- 2014-01-06 CN CN201410006143.3A patent/CN103763135B/zh active Active
Patent Citations (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN102035741A (zh) * | 2010-12-20 | 2011-04-27 | 中兴通讯股份有限公司 | 一种环形拓扑网络中单播报文的转发方法及设备 |
CN103166874A (zh) * | 2013-03-25 | 2013-06-19 | 杭州华三通信技术有限公司 | 一种报文转发方法及设备 |
Also Published As
Publication number | Publication date |
---|---|
CN103763135A (zh) | 2014-04-30 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN103763135B (zh) | 一种pe设备流量调度方法及装置 | |
TWI543566B (zh) | 基於軟體定義網路的資料中心網路系統及其封包傳送方法、位址解析方法與路由控制器 | |
CN102067533B (zh) | 与虚拟接口相关联的端口分组 | |
KR101989333B1 (ko) | 소프트웨어 정의 네트워킹에서의 데이터 전달 방법, 기기 및 시스템 | |
CN106487695B (zh) | 一种数据传输方法、虚拟网络管理装置及数据传输系统 | |
CN104584491B (zh) | 提供分布式虚拟路由和交换(dvrs)的系统和方法 | |
CN103081418B (zh) | 计算机系统和计算机系统中的通信方法 | |
CN106936777A (zh) | 基于OpenFlow的云计算分布式网络实现方法、系统 | |
US11381883B2 (en) | Dynamic designated forwarder election per multicast stream for EVPN all-active homing | |
CN105897459A (zh) | 多级交换机结构故障检测和处理 | |
CN106059915A (zh) | 基于sdn控制器实现租户南北向流量限速的系统及方法 | |
CN103477588A (zh) | 刀片服务器中刀片间网络业务的分类和管理方法和系统 | |
CN104468358A (zh) | 分布式虚拟交换机系统的报文转发方法及设备 | |
CN102469019B (zh) | 一种包交换网络中聚合链路带宽的分配方法及装置 | |
CN104301417B (zh) | 一种负载均衡方法及装置 | |
CN104980361A (zh) | 一种负载均衡方法、装置及系统 | |
CN108092934A (zh) | 安全服务系统及方法 | |
US10404597B2 (en) | Virtual horizontally-scalable packet broker systems and methods for distribution of session-based network traffic | |
CN106330704A (zh) | 一种报文转发方法和装置 | |
CN106656905A (zh) | 防火墙集群实现方法及装置 | |
EP2930893A1 (en) | Communication system, control apparatus, communication control method, transfer control method, and transfer control program | |
CN104081692A (zh) | FCoE的融合结构 | |
CN105224385A (zh) | 一种基于云计算的虚拟化系统及方法 | |
CN107566237A (zh) | 一种数据报文处理方法及装置 | |
CN105791402A (zh) | 一种云计算平台网络虚拟化实现方法及相应插件和代理 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
C06 | Publication | ||
PB01 | Publication | ||
C10 | Entry into substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
CB02 | Change of applicant information |
Address after: 310052 Binjiang District Changhe Road, Zhejiang, China, No. 466, No. Applicant after: Xinhua three Technology Co., Ltd. Address before: 310053 Hangzhou hi tech Industrial Development Zone, Zhejiang province science and Technology Industrial Park, No. 310 and No. six road, HUAWEI, Hangzhou production base Applicant before: Huasan Communication Technology Co., Ltd. |
|
CB02 | Change of applicant information | ||
GR01 | Patent grant | ||
GR01 | Patent grant |