CN116319578B - 一种基于dpaa的网络风暴防御方法 - Google Patents

Abstract

本发明提供一种基于DPAA的网络风暴防御方法，包括以下步骤：步骤S1：确定协议类型，基于协议类型编写硬件编码解析器FMAN，FMAN中的协议包括专有协议、已知协议和其他协议；步骤S2：基于FMAN的以太网接口制定linux_fman_policy策略，linux_fman_policy策略通过FMAN中的协议解析对网络帧进行分类；步骤S3：将分类后的网络帧发送给Linux协议栈，在发送过程中，采用两速三色标记算法对进入Linux协议栈的网络帧进行上色标记，丢弃红色标记的数据帧。基于DPAA平台实现了网络数据包的协议解析分类和流量监控限速的方法，在数据链路层丢弃无用数据包的方法来实现网络风暴的防御。

Description

一种基于DPAA的网络风暴防御方法

技术领域

本发明涉及一种网络风暴防御方法，尤其涉及一种基于DPAA的网络风暴防御方法。

背景技术

网络风暴就是大量数据报文在链路形成，导致网络雍塞甚至瘫痪。产生的原因有很多，最简单就是由于网络拓扑的设计和连接问题。整个传输流程中，只有广播报文在网段内产生大量复制，交叉传递。一个数据帧或包被传输到本地网段(由广播域定义)上的每个节点就是广播；由于网络拓扑的设计和连接问题，或其他原因导致广播在网段内大量复制，传播数据帧，导致网络性能下降，甚至网络瘫痪，这就是广播风暴。广播风暴指数据帧形成环路，而帧头中无ttl的结构，所以帧始终有效，由于广播没有特定目标00地址，所以hub/swtich会永远转发下去。

针对网络中的用户设备（不包括交换机、路由器等网络设备）在网络风暴发生时会产生一连串的连锁反应。首先设备的网络处于瘫痪状态，但更严重的是由于网络风暴中大量的网络帧一起涌向用户设备的网卡，与此同时网卡会产生大量中断。大量中断导致CPU频繁响应并处理无用的网络包，从而导致CPU过负荷。从现场经验来看，发生网络风暴以后通过top指令查看CPU占有率均在95%以上。这样CPU上原有的正常业务便不能响应甚至崩溃。一旦出现这种情况，即使网络风暴消失以后，用户设备也无法回到正常状态，从而造成严重故障。

广播风暴的产生有多种原因，如蠕虫病毒、交换机端口故障、网卡故障、链路冗余没有启用生成树协议、网线线序错误或受到干扰等。从目前来看，蠕虫病毒和arp攻击是造成网络广播风暴最主要的原因。目前大多数厂商都支持风暴抑制的相关配置，可以在一定程度上减少网络风暴的产生。例如划分vlan、通过端口控制网络广播风暴等。但是随着网络拓扑越来越复杂，硬件故障甚至是人为原因，不可避免的还是会有网络风暴的产生。

从用户设备的主动防御来看，有些方案是通过Netfilter进行网络包的过滤，阻止过多无用的数据包进入系统。Netfilter 是 Linux 内核中进行数据包过滤，连接跟踪（Connect Track），网络地址转换（NAT）等功能的主要实现框架；该框架在网络协议栈处理数据包的关键流程中定义了一系列钩子点（Hook 点），并在这些钩子点中注册一系列函数对数据包进行处理。这些注册在钩子点的函数即为设置在网络协议栈内的数据包通行策略，也就意味着，这些函数可以决定内核是接受还是丢弃某个数据包。利用这个原理可以防止大量无用的数据包进入到系统，从而抑制网络风暴对设备本身的冲击。但是该技术存在一个问题。如图1所示，OSI模型中将网络划分为七层，但在目前实际广泛使用的 TCP/IP协议框架体系内，我们一般将网络划分为五层，从下到上依次为物理层，链路层，网络层，传输层以及应用层。在TCP/IP协议框架体系的五层网络模型中，每一层负责处理的数据包协议或类型均存在差异，物理层主要负责在物理载体上的数据包传输，如WiFi，以太网，光纤，电话线等；数据链路层主要负责链路层协议解析（主要为以太网帧，其他类型此处暂不考虑），网络层主要负责IP协议（包括IPv4和IPv6）解析，传输层负责传输层协议解析（主要为TCP，UDP 等），而传输层以上我们均归类为应用层，主要包括各类应用层协议，如我们常用的HTTP，FTP，SMTP，DNS，DHCP等。在Linux内核中，Netfiler通过在网络层设置多个Hook点，来完成数据包的过滤和抓取。由此可见，如果要使用Netfiler的过滤工具，那么数据包就需要经过物理层、数据链路层和网络层的多层处理，最后在网络层丢掉数据包。这些处理本身已经对CPU的性能造成了损耗。所以该方案可以达到对网络风暴的抑制作用，但是也是以损失部分CPU的性能为代价，实际效果不是太理想。也有一些类似的检测和过滤方案，它们的原理相差不大，区别是在不同的层进行处理。

发明内容

针对上述问题，本发明提供一种基于DPAA的网络风暴防御方法，通过在数据链路层做数据包的分析和过滤来阻止数据包向上穿过协议栈，在进入CPU之前拦截数据包，使设备抵御网络风暴的冲击，在网络风暴消失以后，操作系统及各项应用稳定运行。

为实现上述目的，本发明公开了一种基于DPAA的网络风暴防御方法，包括以下步骤：

步骤S1：确定协议类型，基于协议类型编写硬件编码解析器FMAN，FMAN中的协议包括专有协议、已知协议和其他协议；

步骤S2：基于FMAN的以太网接口制定linux_fman_policy策略，linux_fman_policy策略通过FMAN中的协议解析对网络帧进行分类；

步骤S3：将分类后的网络帧发送给Linux协议栈，在发送过程中，采用两速三色标记算法对进入Linux协议栈的网络帧进行上色标记，丢弃红色标记的数据帧。

进一步的，所述已知协议包括：Ethernet、IEEE802.3、VLAN、PPPoE、MPLS、IPv4、IPv6、GRE、IPSec、TCP、UDP、SCTP、DCCP。

进一步的，所述两速三色标记算法将网络帧分为三个颜色，

绿色的数据帧为符合承诺信息速率的流量，在没有任何限制的情况下通过网络；

黄色的数据帧为超过承诺信息速率但在峰值信息速率范围内的流量，相较于绿色的数据帧具有更低的优先级；

红色的数据帧为超过峰值信息速率的流量，不允许红色的数据帧通过网络，并将红色的数据帧丢弃。

进一步的，所述步骤S2中，针对每一个所需的业务，基于FMAN的以太网接口制定linux_fman_policy策略，linux_fman_policy策略通过FMAN中的协议解析对网络帧进行分类的方法包括：在linux_fman_policy策略中定义所需业务网络帧对应的类型，各网络帧类型对应一个协议类型，网络帧经过相应的协议解析和验证后被归类为linux_fman_policy策略中与该协议类型对应的网络帧类型。

本发明的一种基于DPAA的网络风暴防御方法的有益效果为：基于DPAA平台实现了网络数据包的协议解析分类和流量监控限速的方法，在数据链路层丢弃无用数据包的方法来实现网络风暴的防御。

附图说明

下面结合附图和具体实施方式对本发明作进一步详细的说明。

图1是本发明的网络分层模型示意图。

图2是本发明的DPAA网络架构原理示意图。

图3是本发明的硬件解码原理示意图。

具体实施方式

下面结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述。在下面的描述中阐述了很多具体细节以便于充分理解本发明，但是本发明还可以采用其他不同于在此描述的其它方式来实施，本领域技术人员可以在不违背本发明内涵的情况下做类似推广，因此本发明不受下面公开的具体实施例的限制。

本发明的实施例公开了一种基于DPAA的网络风暴防御方法，包括以下步骤：

步骤S1：确定协议类型，基于协议类型编写硬件编码解析器FMAN，FMAN中的协议包括专有协议、已知协议和其他协议；

步骤S2：基于FMAN的以太网接口制定linux_fman_policy策略，linux_fman_policy策略通过FMAN中的协议解析对网络帧进行分类；

步骤S3：将分类后的网络帧发送给Linux协议栈，在发送过程中，采用两速三色标记算法对进入Linux协议栈的网络帧进行上色标记，丢弃红色标记的数据帧。

为进一步优化上述技术方案，已知协议包括：Ethernet、IEEE802.3、VLAN、PPPoE、MPLS、IPv4、IPv6、GRE、IPSec、TCP、UDP、SCTP、DCCP。

为进一步优化上述技术方案，两速三色标记算法将网络帧分为三个颜色，

绿色的数据帧为符合承诺信息速率的流量，在没有任何限制的情况下通过网络；

黄色的数据帧为超过承诺信息速率但在峰值信息速率范围内的流量，相较于绿色的数据帧具有更低的优先级；

红色的数据帧为超过峰值信息速率的流量，不允许红色的数据帧通过网络，并将红色的数据帧丢弃。

为进一步优化上述技术方案，步骤S2中，针对每一个所需的业务，基于FMAN的以太网接口制定linux_fman_policy策略，linux_fman_policy策略通过FMAN中的协议解析对网络帧进行分类的方法包括：在linux_fman_policy策略中定义所需业务网络帧对应的类型，各网络帧类型对应一个协议类型，网络帧经过相应的协议解析和验证后被归类为linux_fman_policy策略中与该协议类型对应的网络帧类型。

本发明基于NXP的DPAA架构，1G的网卡，Linux 4.19内核。DPAA（Data PathAcceleration Architecture）是一种用于加速数据处理和网络包转发的硬件加速器。DPAA利用硬件和软件协同工作，实现高速数据包处理和转发，提高系统的性能和可靠性。

如图2所示，DPAA从系统构成上可以分为五大部分：

基础组件：QMAN、BMAN

网络I/O：FMAN

硬件加速器：SEC、PME

内核CPU。

FMAN外部与serdes总线相连，用来控制phy芯片进行数据收发，包括10Gbps和1Gbps两种以太网接口。FMAN完成网络数据包的解析和转发功能。它负责将物理层收发的数据进行解析、分类和分发。最终把大量杂乱的以太网帧分成多个可以区分的队列（如图2中的FD1-FD3队列），并将不同队列分发给对应的目的CPU处理。FMAN内部与CPU系统总线相连，这样可以保证FMAN可以使用外部内存和使用CPU来进行配置。针对本发明而言，CPU配置FMAN的目的主要是使它按照用户需求去进行分流和分发（比如将以太网帧分为TCP数据流和UDP数据流）。FMAN还通过DPAA的内部与QMAN与BMAN相连。QMAN完成队列管理，网络接口及其硬件加速器之间的数据处理，通过硬件的方式管理软件队列，还完成如拥塞管理、数据帧的优先级安排，对系统处理过的数据进行重新排队等。BMAN主要为软件和其它硬件模块提供快捷的内存申请和释放功能。其主要思想就是利用硬件来完成内存的分配和释放，提高内存管理效率，从而减轻软件的负载。

1、协议解析和分流处理

本发明的核心处理在FMAN单元，它在TCP/IP模型上属于数据链路层。在网络传输中，两个端之间的传输可以视为一个流，流的处理包括流的接收，以及处理后向下发送。FMAN是一个硬件帧加速器，其内部逻辑如图3所示。它支持对数据包的线速剖析，初始化分类，完成基于QOS的数据包分发，然后送往CPU进行下一步处理。这个过程称为PCD（parse,classify and distribute，解析、分类和分发）。首先FMAN内部按照TCP/IP的分层理论分为Layer2、Layer3、Layer4。每一层的解析器用来解析TCP/IP协议栈对应层的数据头。如Layer2对应数据链路层协议主要有Ethernet、IEEE802.3、VLAN、PPPoE、MPLS，Layer3对应网络层协议包括IPv4、IPv6、GRE、IPSec，Layer4对应传输层协议包括TCP、UDP、SCTP、DCCP。对于这些已知且稳定的协议，使用硬编码解析器函数，按照数据流的方向，对各层固定的位置，执行协议头解析和验证。因为这些已知协议已经通过硬件编码的方式实现了，这样就可以提高系统的处理速度。这种方式也成为硬接线解析功能，如图3中的硬接线连接图。硬接线解析功能也可以通过用户编程的解析功能来补充，以支持硬接线功能不支持的协议，包括专有协议和在其他已知协议之间插入的填充头，如图3中的Other L3 Shell和Other L4Shell（是指人为定义图3中没有的协议，实现用户定制化）。协议解析是分流操作的基础，只有通过协议解析才能将不同的网络帧梳理和归类，将我们需要数据填充到同一队列，从而形成同一类型的数据流（如TCP数据流）。

首先将业务需要的协议单独制定一个策略，使用独立的流量进行传输，以已知协议IPv4、TCP、UDP协议为例，具体实现如下：

首先我们基于这个1G的以太网接口制定一个linux_fman_policy的策略，该策略将所有进入到该网口的网络帧分为三类，它们的名字分别为udpeth、tcpeth和garbage_dist。接着我们定义三类网络帧的解析器如下：udpeth类型指定协议解析器为Layer3的IPv4以及Layer4的UDP，也就是说网络帧经过这两个硬编码解析器的协议头解析和验证以后，可以归类为“udpeth”distribution，也就是我们业务需要的UDP协议流。同理，tcpeth就是业务需要的TCP协议流。最后，网口中的网络帧除去UDP和TCP以后，剩余的网络帧统一归类为“garbage_dist”distribution。这其中就包括网络风暴中的广播包、生成树协议，也包括平时用到的arp和icmp等协议。

实现方法为：

<policy name="linux_fman_policy">

<dist_order>

<distributionref name="udpeth"/>

<distributionref name="tcpeth"/>

<distributionref name="garbage_dist"/>

</dist_order>

</policy>

<distribution name="udpeth">

<queue count="128" base="0x3900"/>

<key>

<fieldref name="ipv4.src"/>

<fieldref name="ipv4.dst"/>

<fieldref name="ipv4.nextp"/>

<fieldref name="udp.sport"/>

<fieldref name="udp.dport"/>

</key>

<action name="policer_mid" type="policer"/>

</distribution>

<distribution name="tcpeth">

<queue count="128" base="0x3900"/>

<key>

<fieldref name="ipv4.src"/>

<fieldref name="ipv4.dst"/>

<fieldref name="ipv4.nextp"/>

<fieldref name="tcp.sport"/>

<fieldref name="tcp.dport"/>

</key>

<action name="policer_high" type="policer"/>

</distribution>

<distribution name="garbage_dist">

<queue count="1" base="0x3900"/>

<action name="policer_low" type="policer"/>

</distribution>

这部分就是协议分类的实现。当前指定的三个策略仅仅是一部分示例，我们也可以制定我们需要的其它策略。策略的制定就是根据自己的业务需求，将数据流分为已知稳定的协议（如上例中的UDP/TCP或者是SCTP、DCCP等）和专有协议。对于已知协议，按照硬接线解析功能，逐层确定硬编码解析器。例如上例中制定了一个IPv4的UDP协议，如果我们将Layer2的硬编码解析器变为IPv6，则可以制定一个IPv6的UDP协议流。对于专有协议，则要求用户自己去编写一个解析器，去定义专有协议的数据头以及相应字段的内容。

2、制定限速策略

有了对应的协议分类以后，需要针对每个分类后的协议制定限速方案。原则是不能影响正常业务的流量，保证正常的网络功能。同时限制网络风暴的广播包等无用协议的流量。使用FMC对mac层的数据包进行协议分流，对发给Linux协议栈的网络帧进行流量监控。采用两速三色标记算法（TRTCM）对进入协议栈的数据上色，扔掉红色标记的数据包（即数据帧）。

两速三色标记算法（TRTCM）是一种用于限制和标记通过网络流量的流量控制机制。它定义在RFC 2698中，是早期的双色标记算法（TCM）的扩展。本发明与传统实现的区别是：本发明基于FMAN硬件框架实现，将算法参数通过限速策略传递给硬件。相比于传统的软件算法，极大的节省了CPU的开销。

TRTCM通过将网络流量分为三个类别或颜色来工作：

绿色流量（即绿色的数据帧）：这是符合承诺信息速率（CIR）的流量，可以在没有任何限制的情况下通过网络。

黄色流量（即黄色的数据帧）：这是超过CIR但在峰值信息速率（PIR）范围内的流量，因此被标记为“黄色”。允许黄色流量通过网络，但比绿色流量具有更低的优先级。

红色流量（即红色的数据帧）：这是超过PIR的流量，因此被标记为“红色”。不允许红色流量通过网络，并被丢弃或作为拥塞的指示发送回源。

TRTCM算法使用两个令牌桶来管理流量：CIR桶和PIR桶。 CIR桶的填充速率为每秒CIR个令牌，而PIR桶的填充速率为每秒PIR个令牌。当流量到达网络时，它会针对CIR桶中的令牌进行检查。如果有足够的令牌，则将流量标记为绿色并允许通过网络。如果没有足够的令牌，则会检查PIR桶中的令牌。如果PIR桶中有足够的令牌，则将流量标记为黄色，并允许通过网络，但具有较低的优先级。如果两个桶中都没有足够的令牌，则将流量标记为红色并丢弃或发送回源。

CIR（Committed Information Rate）：指网络管理员向运营商承诺的最大带宽速率，表示在特定时间内网络可以提供的最低带宽。EIR（Excess Information Rate）：指超出CIR的流量速率。如果没有特殊处理，这些流量可能会导致网络拥塞。CBS（Committed BurstSize）：指CIR在一段时间内可用的最大令牌数。当到达的数据包请求通过网络时，每个数据包需要消耗一个令牌。因此，CBS确定了在特定时间内可以传输多少数据包而不超过CIR。EBS（Excess Burst Size）：指在CIR外的流量速率EIR下最大允许的突发流量大小。与CBS类似，每个数据包需要消耗一个令牌，EBS决定了在超过CIR的速率下可以传输多少个数据包。

具体实现如下：

<policer name="policer_high">

<algorithm>rfc2698</algorithm>

<color_mode>color_blind</color_mode>

<CIR>59152</CIR>

<EIR>88300</EIR>

<CBS>59152</CBS>

<EBS>88300</EBS>

<unit>byte </unit>

<action condition="on-red" type="drop"/>

</policer>

<policer name="policer_mid">

<algorithm>rfc2698</algorithm>

<color_mode>color_blind</color_mode>

<CIR>31768</CIR>

<EIR>63536</EIR>

<CBS>31768</CBS>

<EBS>63536</EBS>

<unit>byte </unit>

<action condition="on-red" type="drop"/>

</policer>

<policer name="policer_low">

<algorithm>rfc2698</algorithm>

<color_mode>color_blind</color_mode>

<CIR>7192</CIR>

<EIR>15384</EIR>

<CBS>192</CBS>

<EBS>15384</EBS>

<unit>byte </unit>

<action condition="on-red" type="drop"/>

</policer>

设定三种限速策略policer_high、policer_mid、policer_low的限速大小依次从大到小。正常业务中TCP占用带宽最多，所以TCP使用policer_high，其次是UDP，使用policer_mid。而像ARP、ICMP、生成树这类的协议，虽然是有用协议，但正常情况下只会使用少量的带宽，所以这里只分配最小的带宽policer_low。而一旦发生网络风暴，大量的无用数据包被分流到garbage_dist，这时policer_low策略生效，只允许少量的无用数据包进入Linux协议栈，这样对系统的影响可以忽略不计。当网络风暴小时消失以后，系统不会受到任何影响。

在未采取本发明方案之前，设备在遭遇到网络风暴时，由于CPU负荷过重导致业务进程异常。在网络风暴过去以后，业务进程无法自动恢复，最后只能重启设备。而在工控现场，设备重启的代价可能相当大，以至于造成不必要的损失。而本发明在实际应用中，系统检测到了多次网络风暴的发生，但一直处于正常运行状态，未出现异常。

显然，所描述的实施例仅仅是本发明的一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

Claims (2)

1.一种基于DPAA的网络风暴防御方法，其特征在于，包括以下步骤：

步骤S1：确定协议类型，基于协议类型编写硬件编码解析器FMAN，FMAN中的协议包括专有协议、已知协议和其他协议；

步骤S2：基于FMAN的以太网接口制定linux_fman_policy策略，linux_fman_policy策略通过FMAN中的协议解析对网络帧进行分类，具体的：针对每一个所需的业务，在linux_fman_policy策略中定义所需业务网络帧对应的类型，各网络帧类型对应协议类型，网络帧经过相应的协议解析和验证后被归类为linux_fman_policy策略中与该协议类型对应的网络帧类型，其中，网络帧类型包括udpeth、tcpeth和garbage_dist，

所述udpeth包括UDP协议，所述tcpeth包括TCP协议，所述garbage_dist包括除UDP协议和TCP协议的其他协议；

步骤S3：将分类后的网络帧发送给Linux协议栈，设定三种限速策略，policer_high、policer_mid、policer_low的限速大小依次从大到小；

设定tcpeth使用policer_high，设定udpeth使用policer_mid，设定garbage_dist使用policer_low，在发送过程中，采用两速三色标记算法对进入Linux协议栈的网络帧进行上色标记，丢弃红色标记的数据帧，具体的policer_high的CIR与EIR大于policer_mid的CIR与EIR，policer_mid的CIR与EIR大于policer_low的CIR与EIR，所述两速三色标记算法将网络帧分为三个颜色，

绿色的数据帧为符合承诺信息速率的流量，在没有任何限制的情况下通过网络；

黄色的数据帧为超过承诺信息速率但在峰值信息速率范围内的流量，相较于绿色的数据帧具有更低的优先级；

红色的数据帧为超过峰值信息速率的流量，不允许红色的数据帧通过网络，并将红色的数据帧丢弃。

2.基于权利要求1所述的一种基于DPAA的网络风暴防御方法，其特征在于，所述已知协议包括：Ethernet、IEEE802.3、VLAN、PPPoE、MPLS、IPv4、IPv6、GRE、IPSec、TCP、UDP、SCTP、DCCP。