报文控制的方法和装置与流程

文档序号:11138510阅读:413来源:国知局
报文控制的方法和装置与制造工艺

本申请涉及通信技术领域,尤其涉及报文控制的方法和装置。



背景技术:

防火墙是一种常用的网络安全设备,为了达到防治攻击、保护网关的目的,防火墙入口流量一般都需要送到CPU(Central Processing Unit,中央处理器)进行分析处理,但由于PCI(Peripheral Component Interconnect,外设部件互连标准)接口带宽的限制,通常设计HIGig接口来满足大流量数据的收发,同时会关闭PCI接口的收发使能,可参考图1a,业务报文和管理报文从MAC(Media Access Control,交换芯片)的不同端口进入,通过ACL(Access Control List,访问控制列表)规则引流到HIGig接口并发送CPU,HIGig接口有7个用于发送报文的队列,cos0至cos7,在处理过程中,业务报文和管理报文默认从同一队列cos0转出,会导致以下问题:

当流量过大时,管理报文会被丢弃,造成设备无法管理。



技术实现要素:

为克服相关技术中存在的问题,本申请提供了报文控制的方法和装置。

根据本申请实施例的第一方面,提供一种报文控制的方法,所述方法包括:

接收报文,所述报文携带接收所述报文的端口的标识;所述端口包括用于接收管理报文的管理端口和用于接收业务报文的业务端口;

基于所述标识判断所述报文的类型;

如果所述报文为管理报文,则从第一队列发送所述管理报文至CPU;如果所述报文为业务报文,则从第二队列发送所述业务报文至CPU;所述第一队列的优先级高于第二队列的优先级。

根据本申请实施例的第二方面,提供一种报文控制的装置,所述装置包括:

接收模块,被配置为接收报文,所述报文携带接收所述报文的端口的标识;所述端口包括用于接收管理报文的管理端口和用于接收业务报文的业务端口;

判断模块,被配置为基于所述标识判断所述报文的类型;

发送模块,被配置为如果所述报文为管理报文,则从第一队列发送所述管理报文至CPU;如果所述报文为业务报文,则从第二队列发送所述业务报文至CPU;所述第一队列的优先级高于第二队列的优先级。

本申请的实施例提供的技术方案可以包括以下有益效果:

将管理报文和业务报文分别从不同队列发送,可以避免流量过大、队列出口拥塞导致的管理报文被随机丢弃的现象,并且优先发送管理报文,保证管理报文被优先处理,确保设备可以管理。

应当理解的是,以上的一般描述和后文的细节描述仅是示例性和解释性的,并不能限制本申请。

附图说明

图1a是相关技术中一种报文发送的场景图。

图1b是本申请实施例一种报文被丢弃的场景图。

图2是本申请根据一示例性实施例示出的一种报文控制的方法的部分流程图。

图3是本申请根据一示例性实施例示出的另一种报文控制的方法的部分流程图。

图4是本申请根据一示例性实施例示出的一种报文控制的流程图。

图5a是本申请根据一示例性实施例示出的一种报文控制的装置的框图。

图5b是本申请根据一示例性实施例示出的另一种报文控制的装置的框图。

具体实施方式

这里将详细地对示例性实施例进行说明,其示例表示在附图中。下面的描述涉及附图时,除非另有表示,不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本申请相一致的所有实施方式。相反,它们仅是与如所附权利要求书中所详述的、本申请的一些方面相一致的装置和方法的例子。

在本申请使用的术语是仅仅出于描述特定实施例的目的,而非旨在限制本申请。在本申请和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式,除非上下文清楚地表示其他含义。还应当理解,本文中使用的术语“和/或”是指并包含一个或多个相关联的列出项目的任何或所有可能组合。

应当理解,尽管在本申请可能采用术语第一、第二、第三等来描述各种信息,但这些信息不应限于这些术语。这些术语仅用来将同一类型的信息彼此区分开。例如,在不脱离本申请范围的情况下,第一信息也可以被称为第二信息,类似地,第二信息也可以被称为第一信息。取决于语境,如在此所使用的词语“如果”可以被解释成为“在……时”或“当……时”或“响应于确定”。

如图1a所示,图1a是本申请实施例一种报文发送的场景图。防火墙10包括交换芯片(MAC)101和中央处理器(CPU)102。交换芯片101的一侧包括业务端口1011和管理端口1012,用于分别接收不同类型的报文,其中,业务端口1011用于接收交换机20发送的业务报文,管理端口1012用于接收管理设备(或监控设备)30发送的管理报文,其中,业务报文和管理报文分别携带业务端口1011和挂你端口1012的端口号。为满足大流量的需求,相关技术中设计HIGig接口1013来发送业务报文和管理报文,同时关闭PCI接口1014的收发使能。业务报文和管理报文在进入交换芯片101后,通过ACL规则引流到HIGig接口1013,并通过HIGig接口1013的某一队列发送至中央处理器102。HIGig接口1013有7个可以发送报文的队列,cos0至cos7,通常,管理报文和业务报文默认是从同一队列cos0发送。如图1b所示,业务报文和管理报文在经过队列cos0时,可能会由于数据量大造成队列出口拥塞,导致管理报文被MAC硬件随机丢弃;当报文进入CPU时,由于流量过大,CPU使用率达到上限,处理能力不足,也会导致报文被CPU硬件或软件丢弃,经过多个环节后,管理报文大部分被丢弃,导致设备无法管理。

本申请将管理报文和业务报文分别从不同队列发送,可以避免流量过大、队列出口拥塞导致的管理报文被随机丢弃的现象;并且设置管理报文的优先级高于业务报文的优先级,可以优先发送管理报文,使得管理报文被优先处理,确保设备可以管理。接下来对本申请进行详细说明。

如图2所示,图2是本申请根据一示例性实施例示出的一种报文控制的方法,可以应用在MAC上,所述方法可以包括以下步骤S201至S203:

在步骤S201中,接收报文,所述报文携带接收所述报文的端口的标识;所述端口包括用于接收管理报文的管理端口和用于接收业务报文的业务端口。

在步骤S202中,基于所述标识判断所述报文的类型。

在步骤S203中,如果所述报文为管理报文,则从第一队列发送所述管理报文至CPU;如果所述报文为业务报文,则从第二队列发送所述业务报文至CPU;所述第一队列的优先级高于第二队列的优先级。

MAC用于接收报文的端口包括业务端口和管理端口,其中,业务端口用于接收业务报文,管理端口用于接收管理报文。业务报文的报头和管理报文的报头分别携带业务端口和管理端口的端口号,该端口号作为端口的标识,也可以用来区分报文的类型。在本申请的实施例中,通过报文的报头所携带的端口号将报文区分为管理报文和业务报文,并将管理报文和业务报文分别从HIGig接口的不同队列发送至CPU。

HIGig接口包括7个队列,cos0至cos7。从cos0到cos7,队列的优先级逐渐升高,优先级高则相应队列的报文会优先发送。本申请的实施例中,将管理报文从第一队列发送,业务报文从第二队列发送,且第一队列的优先级高于第二队列的优先级,可以保证管理报文被优先发送、优先处理。作为一个例子,第一队列可以是cos7,第二队列可以是默认队列cos0,或者其他队列,比如cos1。

其中,发送管理报文和业务报文的队列可以通过ACL规则或QOS预先配置。比如,配置管理报文从cos7发送,业务报文从cos1发送,用户可以通过ACL规则配置管理报文的优先级为7(其中报文的优先级与队列的优先级一一对应,配置报文的优先级即配置该报文从相应优先级的队列发送),配置业务报文的优先级为1即可。当然用户也可以通过QOS分别配置管理报文和业务报文的优先级。ACL规则和QOS的具体配置方法相关领域的技术人员可以参考相关技术得知。

如图3所示,图3是本申请根据一示例性实施例示出的另一种报文控制方法的部分流程图,所述方法在图2所示方法的基础上还可以包括步骤S204至S205:

在步骤S204中,检测是否有软件丢包或硬件丢包;所述软件丢包为CPU软件处理过程中丢弃业务报文,所述硬件丢包为交换芯片MAC硬件处理过程中丢弃业务报文。

在步骤S205中,基于检测结果调节第二队列的带宽。

相关技术中,发送报文的带宽固定,无法满足大流量的需求,也不能保证CPU的使用率。本申请的实施例在将管理报文和业务报文分别从不同队列发送后,基于业务报文发送过程中是否有软件丢包或硬件丢包来调节发送业务报文的队列的带宽,可以满足大流量收发的情况下,在不丢包的同时提高CPU的使用率。其中,硬件丢包是指流量过大时,受发送业务报文的队列的带宽限制,导致出口拥塞,业务报文被MAC硬件丢弃。软件丢包是指CPU软件在处理业务报文的时候,由于CPU软件处理能力不足(CPU使用率达到上限),导致业务报文被丢弃。其中,是否有硬件丢包可以通过MAC中的寄存器统计丢包数据获得,是否有软件丢包可以通过CPU统计丢包数据获得。

在一个可选的实施例中,所述基于检测结果调节第二队列的带宽,可以包括以下任意一种:

如果有软件丢包,则按照预设的时间间隔和调节粒度减小第二队列的最大带宽保证值;

如果有硬件丢包且无软件丢包,则按照预设的时间间隔和调节粒度增大第二队列的最大带宽保证值;

如果没有软件丢包和硬件丢包,则不调节。

通常,正常处理业务报文的过程中不会出现丢弃数业务文的现象,但是,当流量过大时,会出现硬件丢包或软件丢包。因此,可以根据丢包情况动态调节队列带宽,在减少丢包同时提高CPU的使用率。

如果没有软件丢包和硬件丢包,则说明CPU使用率未达到上限且队列带宽足够,则不作调节。

如果有软件丢包,则说明CPU使用率达到上限,需要按照预设的时间间隔和粒度减小第二队列的最大带宽保证值,减少上传至CPU的业务报文,降低CPU的使用率,以减少软件丢包。

如果有硬件丢包且无软件丢包,则说明CPU使用率未达到上限,且业务报文受到出口队列带宽的限制,为了进一步提高CPU的使用率,可以增大最大带宽保证值,以增大带宽,直到开始出现少量软件丢包。当出现软件丢包时,再按照上一个步骤减小最大带宽保证值,从而动态调节队列的带宽,保证在不丢包的情况下提高CPU的使用率。

在一个可选的实现方式中,时间间隔可以由用户预先设置。时间间隔过大可能会调整不及时,导致CPU使用率达到上限,造成业务报文被丢弃;时间间隔过小会可能会由于频繁检测CPU使用率、调节带宽而增加CPU的负担。因此,时间间隔设置要合理,作为一个例子,该时间间隔可以是秒级,比如1秒。

在一个可多选的实现方式中,带宽的调节粒度也可以预先设置。如果带宽的调节粒度过大可能会导致流量突然增加,超过CPU的处理能力,比如,当CPU使用率已经接近上限但未到达上限时,突然大幅度增加带宽可能会导致CPU使用率超过上限,导致业务报文丢包;带宽调节的粒度过小,可能会由于变化细微导致CPU无法感知。因此,调节粒度的设置也要合理,作为一个例子,调节粒度可以是1M。

通过动态调节发送业务报文的队列的带宽,可以使CPU保持最优的报文处理能力,在不丢弃业务报文的情况下尽可能提高CPU的使用率。

图4是本申请根据一示例性实施例示出的一种报文控制的流程图,如图4所示,首先通过ACL规则预先配置报文的发送队列,MAC接收到报文后,区分报文类型,按照预先配置将管理报文和业务报分别cos7、cos0发送。在管理报文和业务报文发送至CPU后,根据软件丢包和硬件丢包情况动态调节队列cos0的带宽,如下:

如果既没有软件丢包,也没有硬件丢包,则不调节;

如果有软件丢包,则每隔1秒减小cos0的带宽1M;

如果有硬件丢包,并且没有软件丢包,则每隔1秒增加cos0的带宽1M。

与前述报文控制的方法的实施例相对应,本申请还提供了报文控制的装置的实施例。

请参考图5a,图5a是本申请根据一示例性实施例示出的一种报文控制的装置50的框图,所述报文控制的装置50包括:

接收模块51,被配置为接收报文,所述报文携带接收所述报文的端口的标识;所述端口包括用于接收管理报文的管理端口和用于接收业务报文的业务端口。

判断模块52,被配置为基于所述标识判断所述报文的类型。

发送模块53,被配置为如果所述报文为管理报文,则从第一队列发送所述管理报文至CPU;如果所述报文为第业务报文,则从第二队列发送所述业务报文至CPU;所述第一队列的优先级高于第二队列的优先级。

在一个实施例中,所述管理报文和业务报文的发送队列通过以下任意一种方式预先配置:

通过访问控制列表ACL规则配配置;或,

通过服务质量QoS配置。

如图5b所示,图5b是本申请根据一示例性实施例示出的一种报文控制的装置的框图,在图5a所述实施例的基础上,所述装置50还可以包括:

检测模块54,被配置为在发送所述管理报文和业务报文至CPU后,检测是否有软件丢包或硬件丢包;所述软件丢包为CPU软件处理过程中丢弃业务报文,所述硬件丢包为交换芯片MAC硬件处理过程中丢弃业务报文。

调节模块55,被配置为基于检测结果调节第二队列的带宽。

在一个可选的实现方式中,调节模块55,具体用于:

如果有软件丢包,则按照预设的时间间隔和调节粒度减小第二队列的最大带宽保证值;

如果有硬件丢包且无软件丢包,则按照预设的时间间隔和调节粒度增大第二队列的最大带宽保证值;

如果没有软件丢包和硬件丢包,则不调节。

上述装置中各个单元的功能和作用的实现过程具体详见上述方法中对应步骤的实现过程,在此不再赘述。

对于装置实施例而言,由于其基本对应于方法实施例,所以相关之处参见方法实施例的部分说明即可。以上所描述的装置实施例仅仅是示意性的,其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的,作为单元显示的部件可以是或者也可以不是物理单元,即可以位于一个地方,或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本申请方案的目的。本领域普通技术人员在不付出创造性劳动的情况下,即可以理解并实施。

以上所述仅为本申请的较佳实施例而已,并不用以限制本申请,凡在本申请的精神和原则之内,所做的任何修改、等同替换、改进等,均应包含在本申请保护的范围之内。

当前第1页1 2 3 
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1