发明内容
针对现有技术中存在的缺陷,本发明解决的技术问题为:如何通过数据平面的软件方式,实现链路可靠性检测。
为达到以上目的,本发明提供的用于多核处理器的通信设备的链路检测方法,包括以下步骤:在多核处理器中指定专用CPU用于收发链路检测报文,以所有专用CPU处理资源时能够达到负载均衡作为选取条件,将通信设备收到的链路检测报文传输至相应的专用CPU;通信设备的数据平面根据链路处理信息在链路信息表中获取对应的链路信息后,根据链路处理信息对获取的链路信息进行更新,链路处理信息包括通信设备的控制平面下发的链路信息、以及专用CPU传输的链路检测报文。
在上述技术方案的基础上,所述根据链路处理信息对获取的链路信息进行更新的流程包括:
当链路处理信息为控制平面下发的链路添加信息时,在链路信息表中创建与链路添加信息对应的链路信息;当链路处理信息为控制平面下发的链路删除信息时,在链路信息表中删除与链路删除信息对应的链路信息;
当链路处理信息为专用CPU传输的链路检测报文时,确定链路信息表中与链路检测报文的对应的链路信息、以及链路检测报文的状态信息:
若状态信息为对端主动终止当前链路检测,则将链路信息中的链路状态设置为停止检测状态;
若状态信息为对端主动发送链路检测请求,则将链路信息中的链路状态设置为开始接收状态,将链路信息中的收包计数清零;
若链路检测报文的状态信息为对端响应本端发送的链路检测请求,则将链路信息中的链路状态设置为收到应答状态并将收包计数清零;
若收到的指定数量的链路检测报文的状态信息均为响应本端发送的链路检测请求,则将链路信息中的链路状态设置为正在检测。
在上述技术方案的基础上,该方法还包括以下步骤:
按照专用CPU的定时器的数量,对链路信息表中的所有链路信息进行分区,将每个定时器与一个分区关联;当每个定时器达到指定时长后,数据平面遍历该定时器关联的分区中的每一条链路信息,获取遍历到的链路信息中的链路检测模式:
若为主动模式或被动模式,则进入报文监测流程;
若为回声模式、且定时器的值达到回声探测报文的发包时间,则发送回声探测报文,该报文中的目的Mac地址为终点设备的Mac地址,目的IP地址为本端IP地址;将链路信息中的发包计数加1后,若发包计数大于收包个数,将链路信息中的链路状态设置为停止检测状态;
报文监测流程包括:
获取链路信息中的链路状态:
若链路状态为停止检测状态、且为主动模式、且定时器的值达到状态信息为主动发送链路检测请求的链路检测报文的发包时间,则向发送该链路检测报文;
若链路状态为开始接收状态、且定时器的值达到状态信息为响应对端发送的链路检测请求的链路检测报文的发包时间,则发送该链路检测报文,将链路信息中的发包计数加1后,若发包计数大于收包个数,则将链路信息中的链路状态设置为停止检测状态;
若链路状态为收到应答状态、且定时器的值达到最小发包时间,则发送状态信息为响应对端发送的链路检测请求的链路检测报文后,若定时器的值已经达到最小收包时间,则将链路信息中的发包计数加1;若发包计数大于收包个数,则将当前链路信息中的链路状态设置为停止检测状态。
在上述技术方案的基础上,所述以所有专用CPU处理资源时能够达到负载均衡作为选取条件,将通信设备收到的链路检测报文传输至相应的专用CPU的流程包括:判断所有正在使用的专用CPU的负载率是否均达到阈值,若是,则增加专用CPU作为待接收链路检测报文的CPU;否则选择负载率最低的专用CPU作为待接收链路检测报文的CPU。
在上述技术方案的基础上,所述链路信息表为哈希表,该表中的哈希值根据链路处理信息中的链路目的地址和源地址运算得到;每个哈希值下均包括至少一个哈希成员,每个哈希成员均存储有对应的链路处理信息的链路信息;
在此基础上,所述数据平面根据链路处理信息在链路信息表中获取对应的链路信息的流程包括:数据平面根据链路处理信息的链路目的地址和源地址,计算得到哈希值后,获取哈希值中与链路处理信息的链路目的地址和源地址相同的哈希成员。
本发明提供的用于多核处理器的通信设备的链路检测系统,包括调度器、专用CPU、以及设置于数据平面上的链路检测模块;
调度器用于:以所有专用CPU处理资源时能够达到负载均衡作为选取条件,将通信设备收到的链路检测报文传输至相应的专用CPU;
专用CPU用于:接收调度器发送的链路检测报文,将链路检测报文发送至链路检测模块;
链路检测模块用于:根据链路处理信息在链路信息表中获取对应的链路信息后,根据链路处理信息对获取的链路信息进行更新,链路处理信息包括通信设备的控制平面下发的链路信息、以及专用CPU传输的链路检测报文。
在上述技术方案的基础上,所述链路检测模块根据链路处理信息对获取的链路信息进行更新的流程包括:
当链路处理信息为控制平面下发的链路添加信息时,在链路信息表中创建与链路添加信息对应的链路信息;当链路处理信息为控制平面下发的链路删除信息时,在链路信息表中删除与链路删除信息对应的链路信息;
当链路处理信息为专用CPU传输的链路检测报文时,确定链路信息表中与链路检测报文的对应的链路信息、以及链路检测报文的状态信息:
若状态信息为对端主动终止当前链路检测,则将链路信息中的链路状态设置为停止检测状态;
若状态信息为对端主动发送链路检测请求,则将链路信息中的链路状态设置为开始接收状态,将链路信息中的收包计数清零;
若链路检测报文的状态信息为对端响应本端发送的链路检测请求,则将链路信息中的链路状态设置为收到应答状态并将收包计数清零;
若收到的指定数量的链路检测报文的状态信息均为响应本端发送的链路检测请求,则将链路信息中的链路状态设置为正在检测。
在上述技术方案的基础上,该系统还包括链路信息分区模块和专用CPU的定时器;
链路信息分区模块用于:按照专用CPU的定时器的数量,对链路信息表中的所有链路信息进行分区,将每个定时器与一个分区关联;
定时器用于:周期性的向链路检测模块发送检测信号;
所述链路检测模块还用于:收到检测信号后,遍历对应定时器关联的分区中的每一条链路信息,获取遍历到的链路信息中的链路检测模式:
若为主动模式或被动模式,则进入报文监测流程;
若为回声模式、且定时器的值达到回声探测报文的发包时间,则发送回声探测报文,该报文中的目的Mac地址为终点设备的Mac地址,目的IP地址为本端IP地址;将链路信息中的发包计数加1后,若发包计数大于收包个数,将链路信息中的链路状态设置为停止检测状态;
报文监测流程包括:
获取链路信息中的链路状态:
若链路状态为停止检测状态、且为主动模式、且定时器的值达到状态信息为主动发送链路检测请求的链路检测报文的发包时间,则向发送该链路检测报文;
若链路状态为开始接收状态、且定时器的值达到状态信息为响应对端发送的链路检测请求的链路检测报文的发包时间,则发送该链路检测报文,将链路信息中的发包计数加1后,若发包计数大于收包个数,则将链路信息中的链路状态设置为停止检测状态;
若链路状态为收到应答状态、且定时器的值达到最小发包时间,则发送状态信息为响应对端发送的链路检测请求的链路检测报文后,若定时器的值已经达到最小收包时间,则将链路信息中的发包计数加1;若发包计数大于收包个数,则将当前链路信息中的链路状态设置为停止检测状态。
在上述技术方案的基础上,所述调度器的工作流程包括:当所有正在使用的专用CPU的负载率均达到阈值时,增加专用CPU作为待接收链路检测报文的CPU;当存在负载率未达到阈值的专用CPU时,选择负载率最低的专用CPU作为待接收链路检测报文的CPU。
在上述技术方案的基础上,所述链路信息表为哈希表,该表中的哈希值根据链路处理信息中的链路目的地址和源地址运算得到;每个哈希值下均包括至少一个哈希成员,每个哈希成员均存储有对应的链路处理信息的链路信息;
在此基础上,所述链路检测模块根据链路处理信息在链路信息表中获取对应的链路信息的流程包括:根据链路处理信息的链路目的地址和源地址,计算得到哈希值后,获取哈希值中与链路处理信息的链路目的地址和源地址相同的哈希成员。
与现有技术相比,本发明的优点在于:
(1)与现有技术中采用硬件设备进行链路检测相比,本发明采用数据平面的软件方式,在实现链路可靠性检测上具有更好的灵活性,同时检测链路的规格数量不像硬件实现的方案那样固化,软件在实现的链路检测的规格上具有较大的伸缩性,可灵活配置链路数量(1k条~10k条)和收发报文的时间间隔(3.3ms~10s),进而显著提高了提高链路检测报文的规格。与此同时,与采用需要花费额外的成本费用硬件相比,本发明的成本较低。
(2)与现有技术中采用控制平面进行链路检测相比,本发明由数据平面接收链路检测报文,不会在控制平面与数据平面之间的通道内产生大量的数据报文,随之就不会造成对通道带宽的挤占。与此同时,本发明由数据平面处理链路检测报文,不会产生大量的数据报文送入控制平面,这很好的分担了控制平面的处理压力;而且本发明通过指定的专用CPU来收发链路检测报文,链路检测报文不会对控制平面的CPU造成影响,进而显著提高了链路检测报文的收发速度。
(3)本发明以所有专用CPU处理资源时能够达到负载均衡作为选取条件,为收发链路检测报文选取相应的专用CPU,通过多个专用CPU能够避免链路检测报文收发时因负荷较大而受到影响和阻塞,这样不仅使得链路检测报文能够按照对应的收发时长发送,而且能够对多条链路同时进行检测;这会使得收发链路检测报文更加及时,从而提高了链路检测装置的可靠性。
参见(1)至(3)可知,本发明能够显著扩大链路检测报文的规格,同时大幅度提高了链路检测报文的收发速度,非常适于推广。
具体实施方式
以下结合附图及实施例对本发明作进一步详细说明。
本发明实施例中的用于多核处理器的通信设备的链路检测方法,包括以下步骤:
在多核处理器中指定专用CPU用于收发链路检测报文,通信设备接口收到链路检测报文后,以所有专用CPU处理资源时能够达到负载均衡作为选取条件,将链路检测报文传输至相应的专用CPU;通信设备的数据平面根据链路处理信息在预先存储的链路信息表中获取对应的链路信息后,根据链路处理信息对获取的链路信息进行更新,链路处理信息包括通信设备的控制平面下发的链路信息、以及专用CPU传输的链路检测报文;数据平面根据链路检测报文的发送周期,定时将链路检测报文通过专用CPU发送至对端。
由此可知,本发明通过数据平面进行链路检测,进而使得链路检测报文不仅不用上送控制平面,不会占用控制通道的带宽,很好的分担了控制平面的处理压力;而且本发明通过指定的专用CPU来收发链路检测报文,链路检测报文不会对控制平面的CPU造成影响。
与此同时,以所有专用CPU处理资源时能够达到负载均衡作为选取条件,为收发链路检测报文选取相应的专用CPU、并通过多个专用CPU能够避免链路检测报文收发时因负荷较大而受到影响和阻塞,这样不仅使得链路检测报文能够按照对应的收发时长发送,而且能够对多条链路同时进行检测;进而显著扩大了链路检测报文的规格的同时,大幅度提高了链路检测报文的收发速度。通过测试得知,本发明能够达到3.3ms的高速度发包间隔和10k条链路同时检测的规格能力。
下面对上述方法进行具体说明。
参见图1所示,典型的基于多核处理器的通信设备(例如交换机、路由器、防火墙、BRAS等网络设备)的分层结构为:控制平面处于设备的顶层,是整个设备的管理中心,处于控制平面之下的是数据平面,控制平面与数据平面之间一般是通过socket方式传递信息,数据平面将需要上送的报文和信息由socket接口送入到控制平面,其中就包含数据平面链路监控的异常状态监控信息等;控制平面则将配置信息和控制信息通过socket接口送入到数据平面。
参见图1所示,数据平面通过一组带有多个核的CPU(所有CPU共享内存)进行报文的收取、处理和发送,前端接口进入的报文会根据报文的类型进行分组:对于控制平面的控制报文会送入控制平面处理核(即主控CPU);对于链路检测报文则送入专用CPU,专用CPU为BareMetal,即不需要安装操作系统;对于数据转发报文则送入数据转发CPU。
优选的,为了提高数据平面检测机制的健壮性和适应性,根据链路检测应用负载(检测频率、检测规格)的需求,本发明让主控CPU实时监控用于运行链路检测功能专用CPU的负载率,进而动态灵活分配的专用CPU的数量,以保证专用CPU处理资源能达到负载均衡,达到最佳处理效果。参见图2所示,以所有专用CPU处理资源时能够达到负载均衡作为选取条件,将链路检测报文传输至相应的专用CPU的具体流程包括:
通过一个调度器将接入的链路检测报文分发至主控CPU选取的待接收CPU,主控CPU选取待接收CPU的流程包括:主控CPU实时判断所有正在使用的专用CPU的负载率是否均达到阈值(该阈值可根据需要自定义设置,每次分发链路检测报文之前主控CPU都会进行判断),若是,则增加专用CPU作为待接收CPU并告知调度器;否则选择负载率最低的专用CPU作为待接收CPU并告知调度器。
优选的,参见图3所示,本实施例中的链路信息表为带有互斥锁(Lock)的哈希表,该表是一张数组表,该表中的哈希值根据链路处理信息中的链路目的地址和源地址运算得到。哈希表的头部指针(Head)指向与哈希值对应的哈希成员,每个哈希成员均存储有对应的链路处理信息的链路信息。因为哈希值根据链路处理信息的链路目的地址和源地址运算得到,所以会出现一个哈希值对应多个哈希成员的情况。
在此基础上,通信设备的数据平面根据链路处理信息在预先存储的链路信息表获取对应的链路信息的流程包括:数据平面根据链路处理信息的链路目的地址和源地址,计算得到哈希值后,获取哈希值中与链路处理信息的链路目的地址和源地址相同的哈希成员,该哈希成员即为与链路处理信息对应的链路信息。哈希值的计算流程可以为:将链路处理信息的链路目的地址和源地址作为哈希的Key值,对Key值进行CRC计算得到计算值,将计算值与哈希成员总数进行取模(计算值mod哈希成员总数),取模后的值即为哈希值。
优选的,根据链路处理信息对获取的链路信息进行更新的流程包括:
(1)当链路处理信息为控制平面下发的链路添加信息时:
判断链路信息表中是否存在与链路添加信息对应的链路信息,若是,说明当前链路添加信息已处理,返回已处理信息至控制平面;否则在链路信息表中创建与链路添加信息对应的链路信息。
(2)当链路处理信息为控制平面下发的链路删除信息时:
判断链路信息表中是否存在与链路删除信息对应的链路信息,若是,则删除该链路信息、并向对端发送对应的链路删除信息;否则说明需要删除的链路不存在,返回删除成功信息至控制平面;
(3)当链路处理信息为专用CPU传输的链路检测报文时:
判断链路信息表中是否存在与链路检测报文对应的链路信息,若不是,则向对端返回错误信息;若是,获取该链路信息、并确定链路检测报文的状态信息:
若链路检测报文的状态信息为对端主动终止当前链路检测,则将链路信息中的链路状态设置为停止检测状态;
若链路检测报文的状态信息为对端主动发送链路检测请求,则将链路信息中的链路状态设置为开始接收状态、并将收包计数清零;
若链路检测报文的状态信息为对端响应本端发送的链路检测请求,则将链路信息中的链路状态设置为收到应答状态并将收包计数清零;
若收到的指定数量的链路检测报文的状态信息均为响应本端发送的链路检测请求,则表明链路检测机制已经建立起来了,正在进行链路故障探测,此时将链路信息中的链路状态设置为正在检测。
需要说明的是,上述流程每次收到链路检测报文后都会进行,若新收到的链路检测报文的状态信息与对应链路信息不对应,则根据新收到的链路检测报文的状态信息,对应修改链路信息中的链路状态。
优选的,数据平面根据链路检测报文的发送周期,定时将链路检测报文通过专用CPU发送至对端的流程原理为:
链路检测作为一种毫秒级的链路检测机制,对定时器的精度和性能要求非常高;因此该流程需要实现:
(1)在两端的链路检测机制建立起来之后,两端均收到对端的up报文,此时可以任意修改两端的收发包间隔,已达到合理利用资源的目的。
(2)所有链路的发包都是由定时器触发,当定时器中断来临,会对链路信息表中所有的链路信息进行“扫描”,对达到发包要求的链路信息,根据相应的字段组包后向对应的链路发送报文。同时由于CPU的硬件定时器数量有限,本发明会将所有链路信息进行分区,每个分区采用一个硬件定时器对分区内的链路信息进行扫描和处理。这样利用多个硬件定时器以及分区的设计可以满足定时精度和链路信息容量的要求。
进一步,参见图4所示,数据平面根据链路检测报文的发送周期,定时将链路检测报文通过专用CPU发送至对端的流程包括:
S101:按照专用CPU的硬件定时器的数量,对链路信息表中的所有链路信息进行分区,将每个定时器与一个分区关联;当每个定时器达到指定时长后,遍历该定时器关联的分区中的每一条链路信息,获取遍历到的链路信息中的链路检测模式,若链路检测模式为主动模式或被动模式,转到S102,若链路检测模式为回声模式,转到S106。
S102:获取链路信息中的链路状态:若链路状态为停止检测状态、且为主动模式,转到S103;若链路状态为停止检测状态、且为被动模式,此时不主动向对端发包直接结束(图中未示出该分支);若链路状态为开始接收状态,无论主动模式还是被动模式,均转到S104;若链路状态为收到应答状态,无论主动模式还是被动模式,均转到S105。
S103:根据定时器的值,判断是否达到状态信息为主动发送链路检测请求的链路检测报文的发包时间,定时器的值与指定的发包间隔时长取模(定时器的值mod发包间隔)为0代表达到发包时间;若是,向对端发送该链路检测报文,否则表明发包时间还未到,结束。
S104:根据定时器的值,判断是否达到状态信息为响应对端发送的链路检测请求的链路检测报文的发包时间,定时器的值与指定的发包间隔时长取模(定时器的值mod发包间隔)为0代表达到发包时间;
若是,向对端发送该链路检测报文,将链路信息中的发包计数加1后,若发包计数大于收包个数,则表明在规定的时间间隔内没有收到对端的响应报文,将当前链路信息中的链路状态设置为停止检测状态;
否则表明发包时间还未到,结束。
S105:根据定时器的值,判断是否达到最小发包时间,定时器的值与指定的最小发包间隔时长取模(定时器的值mod最小发包间隔)为0代表达到最小发包时间;
若是,向对端发送状态信息为响应对端发送的链路检测请求的链路检测报文后,若定时器的值已经达到最小收包时间(定时器的值mod指定的最小收包间隔为0代表达到),将链路信息中的发包计数加1;若发包计数大于收包个数,则表明在规定的时间间隔内没有收到对端的响应报文,将当前链路信息中的链路状态设置为停止检测状态;
否则表明发包时间还未到,结束。
S106:根据定时器的值,判断是否达到回声探测报文的发包时间,定时器的值与指定的发包间隔时长取模(定时器的值mod发包间隔)为0代表达到发包时间;
若是,发送回声探测报文,该报文中的目的Mac地址为终点设备的Mac地址,目的IP地址为本端IP地址(回声探测报文中的源IP等于目的IP);将链路信息中的发包计数加1后,若发包计数大于收包个数,则表明在规定的时间间隔内没有收到自己发出去的回声探测报文,将当前链路信息中的链路状态设置为停止检测状态;
否则表明发包时间还未到,结束。
上述指定的所有发包间隔和收包间隔均可按照需要设置,各具体数值可相同也可不同。
由此可知,本发明在定时器处理上,对于每个分区的链路采用一个独立的定时器,这样不仅合理利用了资源,而且很好的解决了数据平面无法提供大规格的定时器用于链路定时收发报文的技术瓶颈。
下面通过一个具体实施例说明本发明的方法。
初始化流程:
(1)对哈希表和互斥锁进行初始化,为哈希表申请内存,本实施例中的哈希表中包括2000个哈希成员。
(2)专用CPU的硬件定时器进行初始化,定时器的中断定时间隔时间为3.3ms,每次中断时间到来,系统会对哈希表中的所有哈希成员进行状态扫描。
参见图3所示,本实施例中每个哈希成员中存储的字段包括:
计数标志位(flag),用于记录当前会话的发包个数;
状态位(state),用于表示当前链路的状态;
轮询标志(P):1比特,如果比特为1,表明发送节点请求检查连接状态或参数变化,并希望收到F比特为1的应答;如果为0,表明发送节点不请求任何检查;
结束标志(F):1比特,如果此比特为1,表明此消息是发送节点对P比特为1的检测包的应答;如果为0,表明不是发送节点对P比特为1包的应答;
控制平面无关(C):1比特,如果此比特为1,则发送节点的检测报文实现与控制平面分离,即检测功能在转发平面上实现,即使控制平面出现故障检测功能也能继续工作;如果此比特为0,则发送节点的检测功能实现与控制平面在一起;
认证标志(A):1比特,为1,表明存在认证部分,会话需要认证;
按需标志(D):1比特,如果此比特为1,则发送节点工作在按需模式(即节点希望执行按需模式操作,要求邻居停止发送检测控制报文)。如果此比特为0,发送节点未工作在按需模式;
多点标志(M):1比特,为检测功能的点到多点扩展预留,发送和接收都必须为0;
session位(session_id),表示当前链路的session_id;
自我识别位(my_dis),表示当前链路的本地标识符;
对端识别位(your_dis),表示当前链路的远端标识符;
对端报文类型(remote_diag),表示当前链路的对端报文类型;
对端状态位(remote_state),表示当前链路的对端状态;
min_tx:表示当前链路在初始状态下的最小发包间隔;
min_rx:表示当前链路在初始状态下的最小收包间隔;
min_echo:表示当前链路回声报文的收发包间隔;
detect_mult:表示当前链路的收包个数;
auth_type:表示当前链路的认证类型;
auth_keylen:表示当前链路密钥的有效长度;
auth_keyid:表示当前链路的密钥ID号;
auth_key:表示当前链路的密钥,最大支持32个字节;
srcmac:表示当前链路的源Mac地址;
dstmac:表示当前链路的目的Mac地址;
srcIP:表示当前链路的源IP地址;
dstIP:表示当前链路的目的IP地址;
bfd_ifindex:表示当前链路的索引号,用于向上层通告;
src_port:表示当前链路的源端口号;
dst_port:表示当前链路的目的端口号;
vlan_id:表示当前链路的外层vlan号;
vlan_inid:表示当前链路的内层vlan号;
port:表示当前链路的发包端口号;
slot:表示当前链路的发包槽位号;
mod:表示当前链路的检测模式,检测模式为主动、被动或回声;
consult_tx:表示当前链路的协商最小发包间隔;
consult_rx:表示当前链路的协商最小收包间隔;
ip_ttl:表示当前链路发送三层报文的TTL值;
ip_tos:表示当前链路发送三层报文的TOS值;
family:表示当前链路是IPv4还是Ipv6类型;
consult_flag:协商标志位,表示是否需要发起协商请求;
virtual_num:表示当前链路的虚拟端口号,用于虚拟端口收发包;
sequence:表示当前链路的本地随机序列号,用于MD5认证;
remote_seq:表示当前链路的远端随机序列号,用于MD5认证;
next:结构体指针,指向下一个会话的地址。
链路创建流程:控制平面通过Socket通道将需要创建的链路添加信息下发到数据平面,数据平面根据链路添加信息的目的地址和源地址计算得到哈希值(计算方法上文已经描述)后:
若哈希值下不存在哈希成员(哈希表的头部指针下为空),或者存在哈希成员(哈希表的头部指针不为空)、且不与链路添加信息对应(链路目的地址和源地址均相同),则申请与链路添加信息对应的哈希成员的空间,在哈希值下创建该哈希成员;
若哈希值下存在哈希成员、且与链路添加信息对应,则说明当前链路添加信息已处理,返回已处理信息至控制平面。
上述流程适用于主动模式、被动模式和回声模式,区别仅在于创建的哈希成员的mod字段(检测模式字段)不同。
链路删除流程:控制平面通过Socket通道将链路删除信息下发至数据平面,数据平面根据链路删除信息的目的地址和源地址计算得到哈希值(计算方法上文已经描述)后:
若哈希值下不存在哈希成员,或者存在哈希成员、且不与链路删除信息对应,则说明需要删除的链路不存在,返回删除成功信息至控制平面;
若哈希值下存在哈希成员、且与链路删除信息对应,则删除该哈希成员、并向对端发送与对应的哈希成员删除信息;删除该哈希成员的流程包括:
当该哈希成员为哈希值下的头部节点时,用下一个哈希成员将头部节点覆盖;
当该哈希成员为哈希值下的中间节点时,删除该哈希成员后,将该哈希成员的前一个节点的next指针指向它的下一个节点。
链路状态变迁流程:链路的状态变迁主要取决于对端链路检测报文的状态,通过数据平面的链路检测处理模块来执行,具体为:
数据平面根据链路检测报文的目的地址和源地址计算得到哈希值(计算方法上文已经描述)后:
若哈希值下存在哈希成员、且该哈希值下头部的哈希成员的session ID为0,则代表当前链路检测报文需要控制平面处理,直接送入控制平面;若哈希值不存在哈希成员,或者若哈希值下存在哈希成员、且不与链路检测报文对应,则向对端返回错误信息。
若哈希值下存在与链路检测报文对应的哈希成员,则确定链路检测报文的状态信息(即state字段):
若state为0,代表对端主动终止当前链路检测,将哈希成员中的链路状态(一样使用state字段)设置为停止检测状态(down),并通告控制平面将当前链路的状态置为down;
若state为1,代表对端主动发送链路检测请求,将哈希成员中的state字段设置为开始接收状态(init),并将收包计数(flag字段)置零,以避免超时;通告控制平面将当前链路的状态置为init;
若state为2,代表对端响应本端发送的链路检测请求,将哈希成员中的state字段设置为收到应答状态(up),并将flag字段置零,以避免超时;通告控制平面将当前链路的状态置为up;
若state为3,则代表之前收到的指定数量(3条)的链路检测报文的state均为2,表明链路检测机制已经建立起来了,正在进行链路故障探测;此时将哈希成员中的state字段设置为正在检测状态。
链路的定时处理流程:以一个硬件定时器还该定时器处理的分区哈希成员为例进行说明,具体步骤包括:
S101a:当定时器达到指定时长中断后,遍历每个哈希值中的每个session ID为非0的哈希成员,获取遍历到的哈希成员中的链路检测模式(即mod字段),若mod字段为1(表明是主动模式)或2(表明是被动模式),转到S102a;若mod字段为4(表明是回声模式),转到S106a。
S102a:获取哈希成员中的state字段:若state字段为down、且为主动模式,转到S103a;若state字段为down、且为被动模式,此时不主动向对端发包直接结束;若state字段为init,无论主动模式还是被动模式,均转到S104a;若state字段为up,无论主动模式还是被动模式,均转到S105a;
S103a:用定时器的值与1000毫秒(down与init报文的发包间隔)取模,判断取模后的值是否为0,若是,向对端发送init报文,否则表明发包时间还未到,结束。
S104a:用定时器的值与1000毫秒(init和up报文的发包间隔)取模,判断取模后的值是否为0:
若是,向对端发送up报文,将哈希成员的flag字段加1后,若flag字段大于收包个数(detect_mult),则表明在规定的时间间隔内没有收到对端的响应报文,将当前哈希成员的state字段设置为down、并通知控制平面;
否则表明发包时间还未到,结束。
S105a:用定时器的值与当前哈希成员中的最小发包间隔(consult_tx)取模,判断取模后的值是否为0:
若是,向对端发送up报文,然后定时器的值与最小收包间隔(consult_rx)取模,若取模后的值为0则表明已经达到最小收包时间,将哈希成员的flag字段加1后,若flag字段大于detect_mult,则表明在规定的时间间隔内没有收到对端的响应报文,将当前哈希成员的state字段设置为down、并通知控制平面;
否则表明发包时间还未到,结束。
S106a:用定时器的值与1000毫秒(回声探测报文的发包间隔)取模,判断取模后的值是否为0:
若是,发送回声探测报文,该报文中的目的Mac地址为终点设备的Mac地址,目的IP地址为本端IP地址(回声探测报文中的源IP等于目的IP);将哈希成员的flag字段加1后,若flag字段大于detect_mult,将当前哈希成员的state字段设置为down、并通知控制平面;
否则表明发包时间还未到,结束。
本发明实施例中的用于多核处理器的通信设备的链路检测系统,包括调度器、专用CPU、以及设置于数据平面上的链路检测模块。
调度器用于:以所有专用CPU处理资源时能够达到负载均衡作为选取条件,将通信设备收到的链路检测报文传输至相应的专用CPU;具体工作流程包括:当所有正在使用的专用CPU的负载率均达到阈值时,增加专用CPU作为待接收链路检测报文的CPU;当存在负载率未达到阈值的专用CPU时,选择负载率最低的专用CPU作为待接收链路检测报文的CPU。
专用CPU用于:接收调度器发送的链路检测报文,将链路检测报文发送至链路检测模块。
链路检测模块用于:根据链路处理信息在链路信息表中获取对应的链路信息后,根据链路处理信息对获取的链路信息进行更新,链路处理信息包括通信设备的控制平面下发的链路信息、以及专用CPU传输的链路检测报文。
链路信息表为哈希表,该表中的哈希值根据链路处理信息中的链路目的地址和源地址运算得到;每个哈希值下均包括至少一个哈希成员,每个哈希成员均存储有对应的链路处理信息的链路信息。
在此基础上,链路检测模块根据链路处理信息在链路信息表中获取对应的链路信息的流程包括:根据链路处理信息的链路目的地址和源地址,计算得到哈希值后,获取哈希值中与链路处理信息的链路目的地址和源地址相同的哈希成员。
链路检测模块根据链路处理信息对获取的链路信息进行更新的流程包括:
当链路处理信息为控制平面下发的链路添加信息时,在链路信息表中创建与链路添加信息对应的链路信息;当链路处理信息为控制平面下发的链路删除信息时,在链路信息表中删除与链路删除信息对应的链路信息;
当链路处理信息为专用CPU传输的链路检测报文时,确定链路信息表中与链路检测报文的对应的链路信息、以及链路检测报文的状态信息:
若状态信息为对端主动终止当前链路检测,则将链路信息中的链路状态设置为停止检测状态;
若状态信息为对端主动发送链路检测请求,则将链路信息中的链路状态设置为开始接收状态,将链路信息中的收包计数清零;
若链路检测报文的状态信息为对端响应本端发送的链路检测请求,则将链路信息中的链路状态设置为收到应答状态并将收包计数清零;
若收到的指定数量的链路检测报文的状态信息均为响应本端发送的链路检测请求,则将链路信息中的链路状态设置为正在检测。
该系统还包括链路信息分区模块和专用CPU的定时器。
链路信息分区模块用于:按照专用CPU的定时器的数量,对链路信息表中的所有链路信息进行分区,将每个定时器与一个分区关联;
定时器用于:周期性的向链路检测模块发送检测信号;
所述链路检测模块还用于:收到检测信号后,遍历对应定时器关联的分区中的每一条链路信息,获取遍历到的链路信息中的链路检测模式:
若为主动模式或被动模式,则进入报文监测流程;
若为回声模式、且定时器的值达到回声探测报文的发包时间,则发送回声探测报文,该报文中的目的Mac地址为终点设备的Mac地址,目的IP地址为本端IP地址;将链路信息中的发包计数加1后,若发包计数大于收包个数,将链路信息中的链路状态设置为停止检测状态;
报文监测流程包括:
获取链路信息中的链路状态:
若链路状态为停止检测状态、且为主动模式、且定时器的值达到状态信息为主动发送链路检测请求的链路检测报文的发包时间,则向发送该链路检测报文;
若链路状态为开始接收状态、且定时器的值达到状态信息为响应对端发送的链路检测请求的链路检测报文的发包时间,则发送该链路检测报文,将链路信息中的发包计数加1后,若发包计数大于收包个数,则将链路信息中的链路状态设置为停止检测状态;
若链路状态为收到应答状态、且定时器的值达到最小发包时间,则发送状态信息为响应对端发送的链路检测请求的链路检测报文后,若定时器的值已经达到最小收包时间,则将链路信息中的发包计数加1;若发包计数大于收包个数,则将当前链路信息中的链路状态设置为停止检测状态。
需要说明的是:本发明实施例提供的系统在进行模块间通信时,仅以上述各功能模块的划分进行举例说明,实际应用中,可以根据需要而将上述功能分配由不同的功能模块完成,即将系统的内部结构划分成不同的功能模块,以完成以上描述的全部或者部分功能。
进一步,本发明不局限于上述实施方式,对于本技术领域的普通技术人员来说,在不脱离本发明原理的前提下,还可以做出若干改进和润饰,这些改进和润饰也视为本发明的保护范围之内。本说明书中未作详细描述的内容属于本领域专业技术人员公知的现有技术。