01-03 Local Attack Defense Configuration

S1720, S2700, S5700, and S6720 Series Ethernet
Switches
Configuration Guide - Security 3 Local Attack Defense Configuration
3 Local Attack Defense Configuration
About This Chapter
This chapter describes how to configure local attack defense to limit the rate of
packets reaching the CPU. This function protects device security and ensures
uninterrupted services.
3.1 Overview of Local Attack Defense

3.2 Licensing Requirements and Limitations for Local Attack Defense
3.3 Default Settings for Local Attack Defense
3.4 Configuring CPU Attack Defense
3.5 Configuring Attack Source Tracing
3.6 Configuring Port Attack Defense
3.7 Configuring the User-Level Rate Limiting
3.8 Maintaining Local Attack Defense
3.9 Example for Configuring Local Attack Defense
3.10 Example for Configuring Attack Source Tracing
3.11 Troubleshooting Local Attack Defense
3.12 FAQ About Local Attack Defense
3.13 Attack Defense Packet Types
3.1 Overview of Local Attack Defense
Definition
Local attack defense protects the CPU of a device and prevents service interruption
caused by attacks from a large number of packets or malicious packets.
Issue 12 (2020-11-15) Copyright © Huawei Technologies Co., Ltd. 152

Switches
Device CPUs need to process a large number of packets including valid packets
and malicious attack packets on a network. The malicious attack packets
overwhelm the CPUs, and thus affect services and cause a system breakdown. In
addition, excessive valid packets can also lead to high CPU usage, which degrades
the CPU's performance and interrupts services.
To ensure that the CPU can process services in a timely manner, the device
provides a local attack defense function. When a device is undergoing an attack,
this function ensures uninterrupted service transmission and minimizes the impact
on network services.
Basic Implementation
The device supports four types of local attack defense: CPU attack defense, attack
source tracing, port attack defense, and user-level rate limiting.
● CPU Attack Defense

The device can limit the rate of all packets reaching the CPU, which means
that only a specified number of packets can be sent to the CPU in a specified
period. This protects the CPU and ensures its normal operation.
The core of CPU attack defense is the Control Plane Committed Access Rate
(CPCAR). CPU attack defense provides the dynamic link protection and
blacklist functions.
– CPCAR limits the rate of protocol packets sent to the control plane and
schedules the packets to protect the control plane. CPCAR provides
hierarchical device protection: rate limiting based on protocols, scheduling
and rate limiting based on queues, and rate limiting for all packets, as
shown in Figure 3-1.
Figure 3-1 Rate limiting for packets sent to the CPU

ARP
Queue 1
DHCP
OSPF
Queue 2 All packets
……
……
Queue N
Rate limiting based Rate limiting and scheduling Rate limiting

on protocols based on queues for all packets
If the traffic volume of a protocol is too large, other protocol packets

cannot be processed in a timely manner. The device supports CPCAR to
limit the packet rate of each protocol. CPCAR includes the settings of
Committed Information Rate (CIR) and Committed Burst Size (CBS) for
each protocol. The device discards the protocol packets that exceed the
corresponding rate limit. This ensures that all protocols can be processed
and prevents interference between protocols.

Switches
After rate limits for protocols are set, the device allocates a queue to
each type of protocol. For example, the device allocates a queue to
management protocols such as Telnet and SSH and a queue to routing
protocols. Queues are scheduled based on weights or priorities. Services
with the highest priority are processed first. You can also set a rate limit
for packets in each queue sent to the CPU.
After the rate limits are set for all packets sent to the CPU, the CPU can
process more protocol packets without being overwhelmed.
NOTE
● If all the rate limits in Figure 3-1 are set, the smallest rate limit takes effect.
● CPU attack defense cannot take effect on the packets that the management
interface receives. If the network connected to the management interface
initiates an attack, users may fail to log in to or manage the device through
the management interface. In this situation, it is recommended that you scan
for viruses on all computers located on the connected network or optimize
the networking to mitigate attacks.
● When multiple protocols are running, the protocol packets sent to the CPU
may be dropped because they exceed the CIR/CBS, the maximum rate of
sending packets from queues to CPU, or the maximum number of packets
that can be processed by CPU. When protocol packets are dropped, protocol
flapping occurs.
– Dynamic link protection refers to session-based application data
protection, such as FTP sessions, BGP sessions, and OSPF sessions. This
function ensures normal services continue to run when an attack occurs.
When a session is set up, protocol rate limiting does not take effect. The
device limits the session rate based on the rate set in the dynamic link
protection, ensuring reliability and stability of the session-related services.
– CPU attack defense provides a blacklist function. A blacklist references an
ACL. The device discards all packets that have the characteristics defined
in the blacklist. You can add known attackers to the blacklist.
– CPU attack defense supports user-defined flows defined through ACLs.
The device limits the rate of packets matching the characteristics defined
in user-defined flows sent to the CPU. The characteristics of attack flows
can be flexibly defined in ACL rules, so you can configure user-defined
flows for a network prone to unknown attacks.
● Attack Source Tracing
Attack source tracing protects the CPU against Denial of Service (DoS)
attacks. The device enabled with attack source tracing analyzes packets sent
to the CPU, collects statistics on the packets, and sets a rate threshold for the
packets. The device considers excess packets as attack packets. The device
finds the source user address or interface of the attack packets and generates
logs or alarms for the attack. Accordingly, the network administrator can take
measures to defend against the attacks, for example, discarding packets from
the attack source.
Attack source tracing involves four processes shown in Figure 3-2: packet
parsing, traffic analysis, attack source identification, log & alarm generation
as well as taking punish actions.
a. Parse packets based on IP addresses, MAC addresses, and ports. The ports
are identified by physical port numbers and VLAN IDs.
b. The system counts the number of received protocol packets based on IP
addresses, MAC addresses, or port numbers.

Switches
c. When the rate of packets sent to the CPU exceeds the threshold, the
system considers that an attack has occurred.
d. When detecting an attack, the system reports a log and an alarm, or
takes punish actions. For example, the system discards the packets.
Figure 3-2 Attack source tracing processes
Attack source tracing
Logs and
Attack alarms
Packet Traffic
source
parsing analysis Taking
identification
punish
actions
Chip forwarding
Attack source tracing provides the whitelist function. After an ACL is

configured to permit the packets from a port or a port is added to the
whitelist, the device does not trace the source of the packets from this port.
You can add authorized users or ports to the whitelist to ensure that packets
from these users can be sent to the CPU.
● Port Attack Defense
Port attack defense is an anti-DoS attack method. If a port receives a lot of
protocol packets, the protocol packets occupy bandwidth and the protocol
packets received by other ports cannot be sent to the CPU. The port attack
defense function prevents attacks based on ports.
The process for port attack defense is as follows:
a. Analyze packets received by each port.
b. Count the protocol packets to which port attack defense is applied based
on ports.
c. Consider that an attack has occurred when the rate of packets sent to the
CPU exceeds the rate threshold.
d. Record a log, and move the packets within the protocol rate limit to a
low-priority queue waiting for CPU processing and discard the excess
packets. For a description about protocol rate limiting and queue-based
scheduling, see CPU Attack Defense.
The rate limiting actions taken by port attack defense have a minor
impact compared to the punish actions taken by attack source tracing.
Port attack defense provides a whitelist function. After an ACL is configured to
permit the packets from a port or a port is added to the whitelist, the device
does not trace the source of or limit the rate of the packets from this port.

Switches
You can add authorized users or ports to the whitelist to ensure that packets
from these users can be sent to the CPU.
● User-Level Rate Limiting
User-level rate limiting identifies users based on MAC address, and rates the
limits of specified protocol packets, such as ARP, ND, DHCP Request, DHCPV6
Request, IGMP and HTTPS-SYN. If a user undergoes a DoS attack, other users
are not affected. The core of user-level rate limiting is HOST CAR.
The procedure of user-level rate limiting is as follows:
a. When receiving preceding packets, the switch performs a hash calculation
on the source MAC addresses and places the packets into different
buckets.
b. When the number of packets placed in a bucket within one second
exceeds the rate limit, the bucket discards the packets. The switch counts
the number of discarded packets every 10 minutes. When the number of
discarded packets within 10 minutes exceeds 2000, the switch reports a
packet discard log for this bucket. If the numbers of discarded packets in
many buckets exceed 2000, the switch records the packet discard logs for
the top 10 buckets.
3.2 Licensing Requirements and Limitations for Local

Attack Defense
Involved Network Elements

Other network elements are not required.
Licensing Requirements
Configuration commands of local attack defense are available only after the
S1720GW, S1720GWR, and S1720X have the license (WEB management to full
management Electronic RTU License) loaded and activated and the switches are
restarted. Configuration commands of local attack defense on other models are
not under license control.
For details about how to apply for a license, see S Series Switch License Use
Guide.
Version Requirements
Table 3-1 Products and versions supporting local attack defense
Product Product Software Version

Model
S1700 S1720GFR V200R006C10, V200R009C00, V200R010C00,

V200R011C00, V200R011C10

Switches

Model
S1720GW V200R010C00, V200R011C00, V200R011C10

and
S1720GWR
S1720GW- V200R010C00, V200R011C00, V200R011C10

E and
S1720GWR
-E
S1720X V200R011C00, V200R011C10

and
S1720X-E
Other Models that cannot be configured using commands.

S1700 For details about features and versions, see S1700
models Documentation Bookshelf.
S2700 S2700SI V100R005C01, V100R006(C00&C01&C03&C05)
S2700EI V100R005C01, V100R006(C00&C01&C03&C05)
S2710SI V100R006(C03&C05)
S2720EI V200R006C10, V200R009C00, V200R010C00,

V200R011C10
S2750EI V200R003C00, V200R005C00SPC300, V200R006C00,

V200R007C00, V200R008C00, V200R009C00,
V200R010C00, V200R011C00, V200R011C10
S3700 S3700SI V100R005C01, V100R006(C00&C01&C03&C05)

and
S3700EI
S3700HI V100R006C01, V200R001C00
S5700 S5700LI V200R001C00, V200R002C00,

V200R003(C00&C02&C10), V200R005C00SPC300,
V200R006C00, V200R007C00, V200R008C00,
V200R009C00, V200R010C00, V200R011C00,
V200R011C10
S5700S-LI V200R001C00, V200R002C00, V200R003C00,

V200R005C00SPC300, V200R006C00, V200R007C00,
V200R008C00, V200R009C00, V200R010C00,
V200R011C00, V200R011C10
S5710-C-LI V200R001C00
S5710-X-LI V200R008C00, V200R009C00, V200R010C00,

V200R011C00, V200R011C10
S5700SI V100R005C01, V100R006C00, V200R001C00,

V200R002C00, V200R003C00, V200R005C00

Switches

Model
S5700EI V100R005C01, V100R006(C00&C01),

V200R001(C00&C01), V200R002C00, V200R003C00,
V200R005(C00&C01&C02&C03)
S5710EI V200R001C00, V200R002C00, V200R003C00,

V200R005(C00&C02)
S5720EI V200R007C00, V200R008C00, V200R009C00,

V200R010C00, V200R011C00, V200R011C10
S5720LI V200R010C00, V200R011C00, V200R011C10

and
S5720S-LI
S5720SI V200R008C00, V200R009C00, V200R010C00,

and V200R011C00, V200R011C10
S5720S-SI
S5700HI V100R006C01, V200R001(C00&C01), V200R002C00,

V200R003C00, V200R005(C00SPC500&C01&C02)
S5710HI V200R003C00, V200R005(C00&C02&C03)
S5720HI V200R006C00, V200R007(C00&C10), V200R008C00,

V200R009C00, V200R010C00, V200R011C00,
V200R011C10
S5730SI V200R011C10
S5730S-EI V200R011C10
S6700 S6700EI V100R006C00, V200R001(C00&C01), V200R002C00,

V200R003C00, V200R005(C00&C01&C02)
S6720LI V200R011C00, V200R011C10

and
S6720S-LI
S6720SI V200R011C00, V200R011C10

and
S6720S-SI
S6720EI V200R008C00, V200R009C00, V200R010C00,

V200R011C00, V200R011C10
S6720S-EI V200R009C00, V200R010C00, V200R011C00,

V200R011C10
NOTE
To know details about software mappings, see Hardware Query Tool.

Switches
Feature Limitations
● In V200R011C10 and earlier versions, the attack source tracing function does
not take effect on IPv6 packets.
● The user-level rate limiting is available in the S5720HI of V200R009 and later
versions.
● It is recommended that you disable user-level rate limiting on the network-
side interfaces of an access switch and a gateway switch. The user-level rate
limiting is enabled on interfaces by default.
● The packets destined for the local switch are sent to the CPU. After functions
related to some protocols such as BGP, OSPF, and LACP are enabled, packets
of these protocols are also sent to the CPU. If packets sent to the CPU match
both CPCAR and a traffic classification rule in a traffic policy, but the actions
to be taken conflict with each other, CPCAR or the traffic policy with a higher
precedence takes effect. Table 3-2 describes the precedence between CPCAR
and traffic policies.
Table 3-2 Precedence between CPCAR and traffic policies

Product Model Precedence Details
S1720GFR, S1720GW-E, S1720GWR- Traffic policies take precedence over

E, S1720X-E,S1720GW, S1720GWR, CPCAR.
S1720X, S2720EI, S2750EI, S5700LI, NOTE
S5700S-LI, S5710-C-LI, S5710-X-LI, For ARP packets to be sent to the CPU in
S5720LI, S5720S-LI, S5700SI, the DHCP and NAC authentication
S5720SI, S5720S-SI, S5730SI, services, CPCAR takes precedence over
traffic policies.
S5730S-EI, S6720LI, S6720S-LI,
S6720SI, S6720S-SI, S5700EI, S3700,
S2700EI, S5700HI, S6700EI, S5710EI,
S5710HI, S2710SI
S6720EI, S5720EI, S5720HI, S6720S- CPCAR takes precedence over traffic

EI policies.
NOTE
On the S5720EI running V200R007,
traffic policies take precedence over
CPCAR. On the S5720EI running other
versions, CPCAR takes precedence over
traffic policies.
3.3 Default Settings for Local Attack Defense

Table 3-3, Table 3-4, Table 3-5, and Table 3-6 list the default settings for local
attack defense. The default settings can be modified as required.

Switches
Table 3-3 Default settings for CPU attack defense

Parameter Default Setting
CPU attack defense policy CPU attack defense policy named

default
Blacklist None
User-defined flow None
Type of interfaces sending packets to NNI

the CPU
Type of interfaces sending protocol To check the type of interfaces sending

packets to the CPU protocol packets to the CPU, run the
display cpu-defend configuration
command.
CIR value By default, the device limits the rates

of packets based on the default rate
limits in the default policy. To check
the CIR value, run the display cpu-
defend configuration command.
CPCAR value for BGP, OSPF, FTP, The default CPCAR values vary
HTTPS, IKE, IPSEC-ESP, SSH, TELNET, according to the protocol types of
and TFTP packets used when packets. For details, see 3.4.4
connections are set up Configuring a Rule for Sending
Packets to the CPU.
ALP By default, ALP is enabled on FTP,

HTTPS, IKE, IPSEC-ESP, SSH, TELNET,
and TFTP packets and disabled on BGP
and OSPF packets.
Table 3-4 Default settings for attack source tracing

Attack defense policy Attack defense policy named default
Automatic attack source tracing Enabled
Threshold for attack source tracing 60 pps
Packet sampling ratio for attack source 5

tracing
Attack source tracing mode Based on source IP addresses and

source MAC addresses
Types of traced packets 8021X, ARP, DHCP, IGMP, ICMP, Telnet,

and TCP packets

Switches
Whitelist By default, no whitelist is configured

for attack source tracing. If any of the
following conditions is met, however,
the switch uses the condition as the
whitelist matching rule, regardless of
whether attack source tracing is
enabled. After attack source tracing is
enabled, the switch does not perform
attack source tracing for the packets
matching such rules.
● If an application uses the TCP
protocol and has set up a TCP
connection with the switch, the
switch will not consider TCP packets
with the matching source IP address
as attack packets. If no TCP packets
match a source IP address within 1
hour, the rule that specifies this
source IP address will be aged out.
● If an interface has been configured
as a DHCP trusted interface using
the dhcp snooping trusted
command, the switch will not
consider DHCP packets received
from this interface as attack
packets.
● If an interface has been configured
as a MAC forced forwarding (MFF)
network-side interface using the
mac-forced-forwarding network-
port command, the switch will not
consider ARP packets received from
this interface as attack packets.
Alarm function for attack source Disabled

tracing
Alarm threshold for attack source 60 pps

tracing
Punish function for attack source Disabled

tracing
Table 3-5 Default settings for port attack defense

Attack defense policy Attack defense policy named default

Switches
Port attack defense function Enabled
Types of protocol packets to which ARP Request, ARP Reply, DHCP, ICMP,
port attack defense is applied IGMP, and IP fragment packets
Rate threshold The rate thresholds vary according to

protocol types. For details, see 3.6.4
Setting the Rate Threshold for Port
Attack Defense.
Sampling ratio 5
Aging time 300 seconds
Alarm function Disabled
Whitelist None
Table 3-6 Default settings for user-level rate limiting

User-level rate limiting Enabled
Packet types to which the user-level ARP, ND, DHCP Request, DHCPv6
rate limiting applies Request, and 8021x packets
User-level rate limit 10 pps
User-level rate limiting on interface Enabled
3.4 Configuring CPU Attack Defense

With the CPU attack defense function, the device limits the rate of packets sent to
the CPU to protect the CPU.
Pre-configuration Tasks
Before configuring CPU attack defense, complete the following tasks:
● Connect interfaces and set physical parameters for the interfaces to ensure
that the physical status of the interfaces is Up.
● Configure an ACL for blacklist, if necessary.
Configuration Procedure
Before configuring CPU attack defense, create an attack defense policy. The other
tasks can be performed in any sequence and can be selected as required. An
attack defense policy takes effect only after it is applied to an object. There is no
limitation on when the attack defense policy is applied.

Switches
3.4.1 Creating an Attack Defense Policy

Context
Before configuring the local attack defense function, you must create an attack
defense policy.
Procedure
Step 1 Run system-view
The system view is displayed.
Step 2 Run cpu-defend policy policy-name
An attack defense policy is created and the attack defense policy view is displayed.
The device supports a maximum of 13 attack defense policies, including the
default attack defense policy. By default, the default attack defense policy is
applied to the device and cannot be deleted or modified. The other 12 policies can
be created, modified or deleted.
Step 3 (Optional) Run description text
The description of the attack defense policy is configured.
By default, an attack defense policy does not have a description.
----End
3.4.2 Configuring a Blacklist

Context
A blacklist is a group of users with particular characteristics. The device discards
packets from users in the blacklist. You can apply an ACL to a blacklist.In addition,
for S1720GFR, S1720GW, S1720GWR, S1720X, S1720GW-E, S1720GWR-E, S1720X-
E, S2720EI, S2750EI, S5700LI, S5700S-LI, S5710-X-LI, S5720LI, S5720S-LI, S5720SI,
S5720S-SI, S5730SI, S5730S-EI, S6720LI, S6720S-LI, S6720SI, and S6720S-SI,
packets matching the IPv4 blacklist are sent to the CPU first, and then discarded.
To reduce impact of malicious packets on the CPU usage, you can configure the
switch to discard the packets directly without sending them to the CPU.
Procedure
The attack defense policy view is displayed.
Step 3 Create a blacklist.
● Run the blacklist blacklist-id acl acl-number1 command to create an IPv4
blacklist.

Switches
The ACL referenced by the IPv4 blacklist can be a basic ACL, an advanced ACL,
or a Layer 2 ACL. For details about ACL configuration, see 2 ACL
Configuration.
By default, no IPv4 blacklist is configured.
● Run the blacklist blacklist-id acl ipv6 acl-number2 command to create an
IPv6 blacklist.
Only advanced ACLs can be applied to the IPv6 blacklist. For details about
ACL configuration, see 2 ACL Configuration.
By default, no IPv6 blacklist is configured.
● Run the blacklist blacklist-id acl acl-number3 hard-drop command to create
the blacklist that discards the packets matching ACL rules in the forwarding
chip.
The ACL referenced in this command must be an advanced ACL, and this
command applies to only IPv4 packets. For details about ACL configuration,
see 2 ACL Configuration.
By default, the blacklist that discards the packets matching ACL rules in the
forwarding chip is not configured.
NOTE
● An attack defense policy can contain a maximum of eight blacklists (including IPv4 and IPv6
blacklists and the blacklist that discards the packets matching ACL rules).
● Packets matching the ACL applied to a blacklist are discarded, regardless of whether the ACL
contains a permit or deny rule.
● If an ACL has no rule, the blacklist that references the ACL does not take effect.
● Only the S6720EI, S6720S-EI, S5720HI, and S5720EI support the IPv6 blacklist.
● For the S5720HI, an advanced ACL applied to the IPv6 blacklist can match only the source IP
address.
● Only the S1720GFR, S1720GW, S1720GWR, S1720X, S1720GW-E, S1720GWR-E, S1720X-E,
S2720EI, S2750EI, S5700LI, S5700S-LI, S5710-X-LI, S5720LI, S5720S-LI, S5720SI, S5720S-SI,
S5730SI, S5730S-EI, S6720LI, S6720S-LI, S6720SI, and S6720S-SI support the blacklist that
discards the packets matching ACL rules in the forwarding chip.
● For the S5720EI, S5720HI, S6720EI, and S6720S-EI, when a basic ACL is applied to the
blacklist, the ARP packets matching the ACL are discarded. For the S5720EI, S6720EI, and
S6720S-EI, when an advanced ACL is applied to the blacklist, the ARP packets matching the
ACL are also discarded.
● For the S5720HI, after fast ICMP reply is enabled, the ping detection cannot be blocked by
the blacklist. This is because after the fast ICMP reply function is enabled, the ICMP Echo
Request packets received on an interface of the device are not sent to the protocol stack or
processed by the CPU. Instead, the interface directly processes the packets.
----End
3.4.3 Configuring a User-Defined Flow
Context
You can bind an ACL to a user-defined flow to specify characteristics of attack
flows. When unknown attacks occur on the network, the device can identify attack
data flows and limit the rate of data flows with the specified characteristics.

Switches
NOTE
Only the S5720HI, S5720EI, S6720S-EI, and S6720EI support this function.
If a blacklist and a user-defined flow reference the same ACL, the blacklist takes effect.
Procedure
Step 3 Run user-defined-flow flow-id acl acl-number
A user-defined flow is configured.
The ACL referenced by a user-defined flow can be a basic ACL, an advanced ACL,
or a Layer 2 ACL. For details on how to create an ACL, see 2 ACL Configuration.
By default, no user-defined flow is configured.
NOTE
● An attack defense policy can contain a maximum of eight user-defined flows.

● If the ACL applied to a user-defined flow includes a permit rule, the device uses the default
value 64 kbit/s to limit the rate of packets matching the ACL. If the action for the user-
defined flow is deny, the device discards the packets matching the ACL. If the ACL applied to
a user-defined flow includes a deny rule, the device discards the packets matching the ACL.
● If an ACL has no rule, the user-defined flow that references the ACL does not take effect.
----End
3.4.4 Configuring a Rule for Sending Packets to the CPU

Context
To reduce the number of packets sent to the CPU and prevent interference
between the packets of different types, the switch limits the rate of packets sent
to the CPU in different modes, including rate limiting for protocol packets and rate
limiting for packets after ALP is enabled. ALP packet rate limiting has the highest
priority.

Switches
NOTE
● The default CPCAR value is recommended.

● BGP, FTP, HTTPS, IKE, IPSEC-ESP, OSPF, SSH, TELNET, and TFTP are disabled when the
configuration is initialized. When the protocols are enabled but connections are not set up,
the switch sends packets with the CAR values set using the car command. When connections
are set up and ALP is enabled, the switch sends packets with the CAR values set using the
linkup-car command.
● On the S1720GFR, S1720GW, S1720GWR, S1720X, S1720GW-E, S1720GWR-E, S1720X-E,
S2720EI, S2750EI, S5720SI, S5720S-SI, S5730SI, S5730S-EI, S5710-X-LI, S5720LI, S5720S-LI,
S5700S-LI, S5700LI, S6720LI, S6720S-LI, S6720SI, and S6720S-SI, CIR value for packets sent
to the CPU is expressed in kilobits per second (kbps), but the system limits the rate of
packets in packets per second (pps). The kbps rate is converted to the pps rate using the
following formula: pps = kbps x 1024/packet_length/8, where packet_length indicates the
length of packets sent to the CPU.
Procedure
Step 2 Configure a rule for sending packets to the CPU.
Run cpu-defend policy policy-name
Configure a rate limit on protocol packets or a rate limit after ALP is enabled in
the attack defense policy view.
● Configure rate limits for protocol packets.
The action to be performed on protocol packets sent to the CPU can be car or
deny. When you configure the action to be performed on packets of the same
protocol, the latest configuration takes effect.
– Run car { packet-type packet-type | user-defined-flow flow-id } cir cir-
value [ cbs cbs-value ]
The CIR and CBS values for packets sent to the CPU are set.
By default, the CIR value for user-defined flows is 64 kbit/s. You can run
the display cpu-defend configuration command to check the CAR
values for protocol packets.
– Run deny { packet-type packet-type | user-defined-flow flow-id }
The action taken for the packets sent to the CPU is set to deny.
By default, the switch does not discard packets sent to the CPU. Instead,
the switch limits the rate of user-defined flows and packets sent to the
CPU based on the default rate. You can run the display cpu-defend
configuration command to check the CAR values of each type of
packets.
● Configure a rate limit after ALP is enabled.
a. Run linkup-car packet-type { bgp | ftp | https | ike | ipsec-esp | ospf |
ssh | telnet | tftp } cir cir-value [ cbs cbs-value ]
The CAR values for protocol packets, including the CIR and CBS values,
are set.

Switches
Table 3-7 lists the default CIR and CBS values for the setup of BGP, FTP,
HTTPS, IKE, IPSEC-ESP, OSPF, SSH, TELNET, and TFTP connections.
Table 3-7 Default CIR and CBS values

Product CIR CBS
S1720GFR, S2750EI,
S5700LI, S5700S-LI,
▪ FTP, SSH, TFTP: ▪ FTP, SSH, TFTP:
1024 kbit/s 192512 bytes
S5710-X-LI
▪ TELNET: 64 kbit/s ▪ TELNET: 12032
bytes
S1720GW,
S1720GWR, S1720X,
S1720GW-E,
S1720GWR-E, ▪ OSPF: 512 kbit/s ▪ OSPF: 96256 bytes
S1720X-E, S5720LI,
S5720S-LI, S6720LI, ▪ TELNET: 64 kbit/s ▪ TELNET: 12032
S6720S-LI bytes
S5720SI, S5720S-SI
▪ IKE: 64 kbit/s ▪ IKE: 12032 bytes
▪ IPSEC-ESP: 320 ▪ IPSEC-ESP: 60160

kbit/s bytes

bytes
S2720EI

kbit/s bytes
▪ OSPF: 512 kbit/s ▪ OSPF: 96256 bytes

bytes

Switches
Product CIR CBS
S5730SI, S5730S-EI,
S6720SI, S6720S-SI
▪ BGP: 1024 kbit/s ▪ BGP: 192512 bytes
▪ FTP, SSH, TFTP: ▪ FTP, HTTPS, SSH,

1536 kbit/s TFTP: 288768 bytes

kbit/s bytes

bytes
S5720EI, S6720EI,
S6720S-EI
▪ BGP: 1024 kbit/s ▪ BGP: 192512 bytes
▪ FTP, HTTPS, SSH, ▪ FTP, HTTPS, SSH,

TFTP: 1536 kbit/s TFTP: 288768 bytes

kbit/s bytes

bytes
S5720HI
▪ BGP: 1024kbit/s ▪ BGP: 192512bytes
▪ FTP, HTTPS, SSH, ▪ FTP, HTTPS, SSH,

TFTP: 1536kbit/s TFTP: 288768bytes
▪ IPSEC-ESP: ▪ IPSEC-ESP:
800kbit/s 150400bytes
▪ OSPF: 512kbit/s ▪ OSPF: 96256bytes
▪ TELNET: 64kbit/s ▪ TELNET:

12032bytes

Switches
NOTE
▪ Only the S5730SI, S5730S-EI, S5720EI, S5720HI, S6720SI, S6720S-SI, S6720EI, and
S6720S-EI support the bgp parameter.
▪ Only the S5720EI, S5720HI, S6720EI, and S6720S-EI support the https parameter.
▪ Only the S1720GW, S1720GWR, S1720X, S1720GW-E, S1720GWR-E, S1720X-E,

S2720EI, S5720LI, S5720S-LI, S5720SI, S5720S-SI, S5730SI, S5730S-EI, S5720EI,
S6720LI, S6720S-LI, S6720SI, S6720S-SI, S6720EI, and S6720S-EI support the ike
parameter.
▪ Only the S2720EI, S5720SI, S5720S-SI, S5730SI, S5730S-EI, S5720EI, S5720HI,

S6720SI, S6720S-SI, S6720EI, and S6720S-EI support the ipsec-esp parameter.

S2720EI, S5720LI, S5720S-LI, S5730SI, S5730S-EI, S5720EI, S5720HI, S6720LI,
S6720S-LI, S6720SI, S6720S-SI, S6720EI, and S6720S-EI support the ospf
parameter.
▪ A shared CAR value for packets of FTP, SSH, TFTP connections can be set on
S1720GFR, S1720GW, S1720GWR, S1720X, S1720GW-E, S1720GWR-E, S1720X-E,
S2720EI, S2750EI, S5700LI, S5700S-LI, S5710-X-LI, S5720LI, S5720S-LI, S5720SI,
S5720S-SI, S5730SI, S5730S-EI, S6720LI, S6720S-LI, S6720SI, and S6720S-SI. For
example, the linkup-car packet-type ftp cir cir-value [ cbs cbs-value ] command
specifies the CAR value for FTP packets when an FTP connection is set up, and also
specifies the CAR value for packets of SSH, TFTP connections.
b. Run quit
Return to the system view.
c. Run cpu-defend application-apperceive enable
Globally ALP is enabled.
By default, globally ALP is enabled.
d. Run cpu-defend application-apperceive { bgp | ftp | https | ike | ipsec-
esp | ospf | ssh | telnet | tftp } enable
ALP of protocol packets is enabled.
By default, ALP is enabled on FTP, HTTPS, IKE, IPSEC-ESP, SSH, TELNET,
and TFTP packets and disabled on BGP and OSPF packets.

Switches
NOTE
▪ Only the S5730SI, S5730S-EI, S5720EI, S5720HI, S6720SI, S6720S-SI, S6720EI, and
S6720S-EI support the bgp parameter.

S2720EI, S5720LI, S5720S-LI, S5720SI, S5720S-SI, S5730SI, S5730S-EI, S5720EI,
S6720LI, S6720S-LI, S6720SI, S6720S-SI, S6720EI, and S6720S-EI support the ike
parameter.
▪ Only the S2720EI, S5720SI, S5720S-SI, S5730SI, S5730S-EI, S5720EI, S5720HI,

S6720SI, S6720S-SI, S6720EI, and S6720S-EI support the ipsec-esp parameter.

S2720EI, S5720LI, S5720S-LI, S5730SI, S5730S-EI, S5720EI, S5720HI, S6720LI,
S6720S-LI, S6720SI, S6720S-SI, S6720EI, and S6720S-EI support the ospf
parameter.
▪ After ALP is enabled for HTTPS, the CIR value (transmission rate) is automatically
increased to ensure high-speed file transmission between the web NMS and
switch.
▪ After hardware-based Layer 3 forwarding is enabled for IPv4 packets on an

S2750EI, S5700-10P-LI-AC, or S5700-10P-PWR-LI-AC, this command is not
supported.
----End
3.4.5 (Optional) Configuring Dynamic CPCAR Adjustment for

Protocol Packets
Context
If the default CPCAR settings cannot meet the changing requirements for the
upper limit of the packet sending rate, the dynamic CPCAR adjustment function
can meet these requirements.
If the default CIR value of a protocol has never been modified, a device with this
function enabled can dynamically adjust the default CIR value for the protocol
packets based on service scale (for example, number of dynamic ARP entries) and
CPU usage to meet various service requirements. For details, see Table 3-8.
Table 3-8 Default CPCAR adjustment for ARP packets

Number of ARP Entries Adjusted Default CPCAR
Less than or equal to 512 Unchanged
More than 512 and less than or equal 128 kbit/s (remain unchanged if the
to 1024 default CIR is larger than 128 kbit/s)
More than 1024 and less than or equal 256 kbit/s

to 3072
More than 3072 and less than or equal 512 kbit/s

to 4096

Switches
Number of ARP Entries Adjusted Default CPCAR
More than 4096 512 kbit/s
NOTE
When the number of entries increases, the CIR value is automatically increased. If the CPU
is overloaded, the CIR value is decreased.
The device dynamically adjusts the default CIR value of ARP protocol packets only
when the function is enabled globally and on ARP protocol packets.
This function is only supported by S5720HI, S5720EI, S5720SI, S5720S-SI, S5730SI,

S5730S-EI, S6720LI, S6720S-LI, S6720SI, S6720S-SI, S6720S-EI, and S6720EI.
Procedure
Step 2 Run cpu-defend dynamic-car enable
The dynamic CPCAR adjustment function is enabled globally for protocol packets.
By default, the dynamic CPCAR adjustment function is enabled globally.
Step 3 Run cpu-defend dynamic-car arp enable
The dynamic CPCAR adjustment function is enabled for ARP.
By default, the dynamic CPCAR adjustment function is disabled for ARP.
----End
3.4.6 (Optional) Enabling Alarm Reporting for Packet Loss

Caused by CPCAR Exceeding
Context
To protect the CPU, a switch limits the rate of protocol packets sent to the CPU
based on the CPCAR. If the rate of protocol packets exceeds the CPCAR, excess
protocol packets are dropped. As a result, the corresponding service may not run
normally. To quickly detect packet loss caused by CPCAR exceeding, you can
enable alarm reporting for this event. After this function is enabled, the switch
checks for packet loss caused by CPCAR at 10-minute intervals. If the switch finds
that the number of dropped packets of a protocol increases, the switch reports a
packet loss alarm.
NOTE
This function is only supported by S5720EI, S5720HI, S6720S-EI, or S6720EI.

Switches
Procedure
Step 2 Run cpu-defend trap drop-packet
The system is enabled to report alarms for packet loss caused by CPCAR
exceeding.
----End
3.4.7 Specifying Interface Types for Protocol Packets
Context
Generally, a device uses an ACL to control the protocol packets to be sent to the
CPU. The ACL can only control packets based on protocol types. If protocol packets
are sent to the device, you can run the deny command to discard all the packets
sent to the CPU or run the car (attack defense policy view) command to set a rate
limit for packets. However, packets received by different interfaces cannot be
differentiated.
If an interface is attacked, the attack packets occupy bandwidth and valid protocol
packets cannot be processed. To prevent attack packets, you can disable the device
where the attacked interface is located. However, neither the attacked interface
nor the other interfaces on the device can send packets to the CPU, affecting
communication of the device.
You can configure the device to send different types of protocol packets to the
CPU from different interfaces.
NOTE
The priorities of Network-to-Network Interface (NNI), Enhanced Network Interface (ENI), and
User-to-Network Interface (UNI) are in descending order. If the priority of an interface is higher
or equivalent to the interface priority supported by the protocol packets, the protocol packets
can be sent through this interface. For example, if the type of an interface is ENI and a protocol
packet can take effect on an ENI or UNI interface, the protocol packet can be sent to the CPU
through this ENI interface. However, if the protocol packet can only take effect on an NNI
interface, the protocol packet is discarded by this interface. If the device receives attack packets,
run the blacklist command to configure a blacklist so that the device can discard the attack
packets.
Only the S5720EI, S6720S-EI, and S6720EI support this function.
Procedure
Step 2 Run interface interface-type interface-number
The interface view is displayed.
Step 3 Run port type { uni | eni | nni }

Switches
The interface type is specified. The interface type can be NNI, UNI, or ENI.
By default, the interface type is NNI.
Step 4 Run quit
Return to the system view.
Step 6 Run port-type { uni | eni | nni } packet-type packet-type
The interface type is specified for the packets of a protocol. The interface type can
be NNI, UNI, or ENI.
To view the default types of interfaces sending protocol packets to the CPU, run
the display cpu-defend configuration command.
----End
3.4.8 Applying an Attack Defense Policy
Context
Packets sent to the CPU pass through the switching chip before they reach the
CPU, as shown in Figure 3-3. Therefore, an attack defense policy is usually applied
to the switching chip of a switch by specifying the global keyword.
Figure 3-3 Path of packets sent to the CPU
CPU
Switching Switching
chip chip
Path of packets
sent to CPU
In a stack system shown in Figure 3-4, applying an attack defense policy to the
CPU of the master switch by not specifying the global keyword. If you only limit
packet rates on switching chips of member switches, the CPU of the master switch
may still be overloaded by a large number of protocol packets, because most
protocol packets need to be sent to the CPU of the master switch after being
processed by the CPU of the standby switch or a slave switch. Applying an attack
defense policy to the CPU of the master switch can limit the rates of protocol
packets sent to this CPU, protecting the CPU from attacks.

Switches
Figure 3-4 Path of packets sent to CPUs in a stack system
Switching chip Switching chip
CPU
CPU
Standby
Master switch
switch
CPU CPU
Switching chip Switching chip
Slave Slave
switch switch
Stack cable
Path of packets sent to CPU
Procedure
● Apply a attack defense policy to the CPU.
a. Run the system-view command to enter the system view.
b. Run the cpu-defend-policy policy-name1 command to apply an attack
defense policy.
NOTE
In a stack system, some protocol packets are not sent to the CPU of the master switch. If
you apply an attack defense policy against such protocol packets to the CPU, the system
displays an error message, indicating that the policy cannot be applied.
Only the attack defense policies that limit the rates of packets sent to the CPU can be
applied to the CPU. Other types of attack defense policies are not applicable to the CPU, so
configuring such policies cannot protect the CPU.
● Apply an attack defense policy to the switching chip.
b. Run the cpu-defend-policy policy-name2 global command to apply an
attack defense policy.
----End
3.4.9 Verifying the CPU Attack Defense Configuration
Procedure
● Run the display cpu-defend policy [ policy-name ] command to check the
● Run the display cpu-defend statistics [ packet-type packet-type ] [ all | slot
slot-id ] command to check statistics on packets sent to the CPU.
NOTE
Only the S5720EI, S5720HI, S6720S-EI, and S6720EI support this command.

Switches
● Run the display cpu-defend applied [ packet-type packet-type ] { mcu | slot

slot-id | all } command to check the actual CIR values after protocol packets
are sent to the chip.
● Run the display cpu-defend rate [ packet-type packet-type ] [ all | slot slot-
id ] command to check the rate limit of protocol packets sent to the CPU.
NOTE
● Run the display cpu-defend configuration [ packet-type packet-type ] [ all |
slot slot-id ] command or display cpu-defend configuration [ packet-type
packet-type ] { all | slot slot-id | mcu } command to check the CAR
configuration for protocol packets sent to the CPU.
● Run the display cpu-defend dynamic-car history-record command to check
history records on dynamic adjustment of the default CIR value of protocol
packets.
NOTE
Only the S5720HI, S5720EI, S5720SI, S5720S-SI, S5730SI, S5730S-EI, S6720LI, S6720S-LI,
S6720SI, S6720S-SI, S6720S-EI, and S6720EI support this command.
----End
3.5 Configuring Attack Source Tracing

After attack source tracing is configured on a device, the device analyzes packets
sent to the CPU and sends logs or alarms to notify the administrator of the
potential attack packets so that the administrator can take protective measures.
Before configuring attack source tracing, connect interfaces and set physical
parameters for the interfaces to ensure that the physical status of the interfaces is
Up.
To configure attack source tracing, you must create an attack defense policy. All
other configuration tasks are optional and are not listed in sequence. An attack
defense policy takes effect only after it is applied to an object. There is no
limitation on when the attack defense policy is applied.
Context
defense policy.

Switches
Procedure

----End
3.5.2 Configuring the Threshold for Attack Source Tracing
Context
Attackers may send a large number of packets to attack network devices' CPUs.
You can configure attack source tracing and set an alarm threshold for attack
source tracing so that the device can analyze packets sent to the CPU. If the
number of protocol packets sent from an attack source in a specified period
exceeds the alarm threshold, the device sends logs or alarms to notify the
administrator so that the administrator can take measures to prevent attacks.
Procedure
Step 3 Run auto-defend enable
Attack source tracing is enabled.
By default, attack source tracing is enabled.
Step 4 Run auto-defend threshold threshold
The checking threshold for attack source tracing is set.
By default, the checking threshold for attack source tracing is 60 pps.
----End

Switches
3.5.3 Setting the Packet Sampling Ratio for Attack Source

Tracing
Context
Attack source tracing identifies attacks by sampling received packets. A proper
packet sampling ratio can reduce the errors in attack packet identification and
packet rate calculation. A small sampling ratio makes the attack source tracing
result accurate, but increases CPU usage.
For example, when the sampling ratio is set to 1, the attack source tracing result is
accurate, but the CPU usage is high because every packet is analyzed. Therefore,
balance between the attack defense precision and CPU usage when setting a
sampling ratio.
Procedure
Step 4 Run auto-defend attack-packet sample sample-value
The sampling ratio for attack source tracing is set.
By default, the packet sampling ratio is 5.
----End
3.5.4 Configuring an Attack Source Tracing Mode
Context
After attack source tracing is enabled, you need to set a mode in which the device
traces attack sources. The device supports the following attack source tracing
modes:
● Source IP address-based tracing: prevents Layer 3 attack packets.
● Source MAC address-based tracing: prevents Layer 2 attack packets with a
fixed source MAC address.
● Tracing based on a combination of source port and VLAN: prevents Layer 2
attack packets with different source MAC addresses.

Switches
Procedure
Step 4 Run auto-defend trace-type { source-ip | source-mac | source-portvlan } *
The attack source tracing mode is specified.

By default, attack source tracing is based on source IP addresses and source MAC
addresses.
NOTE
When the attack source tracing mode is source-ip and action is error-down, if multiple
interfaces receive the attack packets with the same source IP address and the packet rate
exceeds the threshold, the switch shuts down only one interface, and then checks packet
rate again. If the packet rate is still higher than the threshold, the switch shuts down
another interface. The switch repeats the operations until the packet rate falls below the
threshold.
----End
3.5.5 Configuring the Types of Traced Packets

Context
When an attack occurs, the device traces packets of all types, and the
administrator cannot identify the type of attack packets. You can specify the types
of packets that the device traces.
Procedure
Step 4 Run auto-defend protocol { all | { 8021x | arp | dhcp | icmp | igmp | tcp | telnet |
ttl-expired | udp }* }

Switches
The type of traced packets is specified.

By default, the device traces sources of 8021X, ARP, DHCP, ICMP, IGMP, TCP, Telnet.
----End
3.5.6 Configuring a Whitelist for Attack Source Tracing

Context
Attack source tracing locates attack sources and takes punish actions on the
attack sources. If some users do not need to be traced regardless of whether they
might initiate attacks, add the users to a whitelist.
NOTE
● Before referencing an ACL in a whitelist, create the ACL and configure rules.
● To specify a protocol type in the ACL referenced by the whitelist, ensure that this protocol
supports the attack source tracing function. You can run the display auto-defend
configuration command to view the protocols supported by attack source tracing. If a
protocol is not supported by attack source tracing, you can run the auto-defend protocol
command to configure attack source tracing to support the protocol.
● The whitelist may fail to be applied because ACL resources are insufficient.
● All the packets matching an ACL referenced by a whitelist are considered to be valid packets
regardless of whether the ACL rule is permit or deny.
If an ACL has no rule, the whitelist that references the ACL does not take effect.
Procedure
Step 4 Run auto-defend whitelist whitelist-number { acl acl-number | interface
interface-type interface-number }
A whitelist is configured.
By default, no whitelist is configured for attack source tracing. If any of the
following conditions is met, however, the device uses the condition as the whitelist
matching rule, regardless of whether attack source tracing is enabled. After attack
source tracing is enabled, the device does not perform attack source tracing for
the packets matching such rules.
● If an application uses the TCP protocol and has set up a TCP connection with
the switch, the switch will not consider TCP packets with the matching source
IP address as attack packets. If no TCP packets match a source IP address
within 1 hour, the rule that specifies this source IP address will be aged out.

Switches
● If an interface has been configured as a DHCP trusted interface using the

dhcp snooping trusted command, the device will not consider DHCP packets
received from this interface as attack packets.
● If an interface has been configured as a MAC forced forwarding (MFF)
network-side interface using the mac-forced-forwarding network-port
command, the device will not consider ARP packets received from this
interface as attack packets.
For the preceding conditions, the device supports a maximum of 16 whitelist

matching rules based on source IP addresses and interfaces, and a maximum of 8
whitelist matching rules based on source IP addresses of TCP packets.
----End
3.5.7 Configuring Event Reporting Function
Context
This function sends an event report to the administrator when the rate of packets
of a specified protocol sent by an attack source exceeds the configured threshold,
so that the administrator can take measures in time to protect the device.
Procedure
Step 4 Configure the event reporting function for attack source tracing.
1. Run auto-defend alarm enable
The event reporting function for attack source tracing is enabled.
By default, the event reporting function for attack source tracing is disabled.
2. Run auto-defend threshold threshold
The event reporting threshold for attack source tracing is set.
By default, the event reporting threshold for attack source tracing is 60 pps.
----End

Switches
3.5.8 Configuring Attack Source Punish Actions
Context
A device with the punish actions configured identifies the attack source and
performs punish actions on the attack source to protect the device. The punish
actions include:
● Discard the packets from the attack source.
● Change the status of the interface receiving attack packets to shutdown.
NOTICE
If the device changes the inbound interface status to shutdown, services of

authorized users on the interface are also interrupted. Exercise caution when you
configure the device to shut down the interface.
Procedure
Step 4 Run auto-defend action { deny [ timer time-length ] | error-down }
The punish function is enabled and a punish action is configured.
By default, the punish function is disabled.
NOTE
The device does not trace the source of users in the whitelist.
----End
Context
After an attack defense policy is created, you must apply the policy in the system
view. Otherwise, the attack defense policy does not take effect.

Switches
Procedure
● Apply an attack defense policy.
b. Run the cpu-defend-policy policy-name global command to apply an
----End
3.5.10 Verifying the Attack Source Tracing Configuration
Procedure
● Run the display auto-defend attack-source [ history [ begin begin-date
begin-time ] [ slot slot-id ] | [ slot slot-id ] [ detail ] ] command to check
attack sources.
● Run the display auto-defend configuration [ cpu-defend policy policy-
name ] command to check the configuration of attack source tracing in an
● Run the display cpu-defend policy [ policy-name ] command to check the
● Run the display auto-defend whitelist [ slot slot-id ] command to check
information about the attack source tracing whitelist.
----End
3.6 Configuring Port Attack Defense

Port attack defense can trace the source and limit the rate of packets sent to the
CPU based on ports, protecting the CPU against DoS attacks.
NOTE
Only the S1720GFR, S2750, S5700LI, and S5700S-LI do not support this function.
Before configuring port attack defense, complete the following tasks:
● Connect interfaces and set physical parameters for the interfaces to ensure
that the physical status of the interfaces is Up.
● Configure ACL if the whitelist needs to reference an ACL.
Before configuring the functions related to port attack defense, create an attack
defense policy and enable the port attack defense function. The other tasks are
performed in any sequence and can be selected as required. An attack defense
policy takes effect only after it is applied to an object. There is no limitation on
when the attack defense policy is applied.

Switches

Context
defense policy.
Procedure
----End
3.6.2 Enabling Port Attack Defense

Context
If an attacker connected to a port initiates a DoS attack, a large number of attack
packets sent from this port to the CPU occupy bandwidth. As a result, the CPU
cannot process the protocol packets sent from other ports, and services are
interrupted.
The port attack defense function effectively limits the number of packets sent to
the CPU, and prevents DoS attacks targeting at the CPU.
This function is enabled by default. Before configuring the functions related to
port attack defense, enable the port attack defense function.
Procedure
Step 3 Run auto-port-defend enable
Port attack defense is enabled.

Switches
By default, the port attack defense function is enabled.
----End
3.6.3 Specifying the Protocols to Which Port Attack Defense Is

Applied
Context
By default, the device calculates the rate of all protocol packets, including ARP
Request, ARP Reply, DHCP, ICMP, IGMP, and IP fragment packets, received by a
port, and traces the source and limits the rate of attack packets. If the packets
exceeding rate threshold contain only a few attack packets, you can cancel port
attack defense for unneeded protocol types. If the device limits the rate of too
many protocols, services are affected. Therefore, you need to specify the protocols
to which port attack defense is applied.
Procedure
Step 3 Run auto-port-defend protocol { all | { arp-request | arp-reply | dhcp | icmp |
igmp | ip-fragment } * }
The protocols to which port attack defense is applied are specified.
By default, port attack defense is applicable to ARP Request, ARP Reply, DHCP,
ICMP, IGMP, and IP fragment packets.
----End
3.6.4 Setting the Rate Threshold for Port Attack Defense

Context
After port attack defense is enabled on a port, the device calculates the rate of
affected protocol packets received by the port. If the packet rate exceeds the
threshold, the device considers that an attack occurs. Then the device traces the
source and limits the rate of attack packets on the port, and records a log. The
device moves the packets within the protocol rate limit to a low-priority queue
waiting for CPU processing and discards the excess packets. (The protocol rate
limit is the CPCAR in an attack defense policy. For description about CPCAR, see
3.4.4 Configuring a Rule for Sending Packets to the CPU.)
You need to set an appropriate rate threshold for port attack defense according to
service requirements. If the CPU fails to process many protocol packets promptly
after port attack defense is enabled, set a large packet rate threshold. If the CPU is
busy processing the packets of a protocol, set a small rate threshold for this
protocol to avoid impact on other services.

Switches
Procedure
Step 3 Run auto-port-defend protocol { all | arp-request | arp-reply | dhcp | icmp |

igmp | ip-fragment } threshold threshold
The protocol rate threshold for port attack defense is set.
The following table lists the default protocol rate thresholds for different
protocols.
Packet Type Rate Threshold
arp-request 60 pps for the S5720EI, S6720S-EI, and

S6720EI, 120 pps for the S5720HI, and
30 pps for other switch models
arp-reply 60 pps for the S5720EI, S6720S-EI, and

dhcp 60 pps for the S5720EI, S6720S-EI, and

icmp 120 pps for the S5720HI and 60 pps

for other switch models
igmp 120 pps for the S5720HI and 60 pps

for other switch models
ip-fragment 30 pps
----End
3.6.5 Setting the Sampling Ratio for Port Attack Defense
Context
A device with port attack defense enabled identifies attacks by analyzing sampled
packets. A proper packet sampling ratio can reduce the errors in attack packet
identification and packet rate calculation.
A small sampling ratio improves attack defense accuracy, but consumes more CPU
resources. For example, when the sampling ratio is set to 1, the device analyzes
every packet. The attack packets can be detected quickly, but CPU usage becomes
high and services are affected. Therefore, balance between the attack defense
precision and CPU usage when setting a sampling ratio.

Switches
Procedure
Step 3 Run auto-port-defend sample sample-value
The protocol packet sampling ratio for port attack defense is set.
By default, the protocol packet sampling ratio for port attack defense is 5. That is,
one packet is sampled when every 5 packets are received.
----End
3.6.6 Setting the Aging Time for Port Attack Defense
Context
After a device with port attack defense function enabled detects an attack on a
port, the device traces the source and limits the rate of the attack packets on the
port within the aging time (T seconds). When the aging time expires, the device
calculates the protocol packet rate on the port again. If the rate is still above the
protocol rate threshold, the device keeps tracing the source and limits the rate of
the attack packets; otherwise, the device stops tracing the source.
If the aging time is too short, the device frequently starts packet rate detection on
ports, which consumes CPU resources. If the aging time is too long, protocol
packets cannot be promptly processed by the CPU, which affects services.
Therefore, balance between the service operation status and CPU usage when
setting an aging time.
Procedure
Step 3 Run auto-port-defend aging-time time
The aging time for port attack defense is set.
By default, the aging time for port attack defense is 300 seconds.
----End

Switches
3.6.7 (Optional) Configuring the Whitelist for Port Attack

Defense
Context
By default, a device calculates the rates of protocol packets received by all
interfaces, and traces the source as well as limits the rate of attack packets.
Sometimes, network-side interfaces need to receive a lot of valid protocol packets.
You should add these interfaces or network nodes that connect to these interfaces
to the whitelist. The device does not trace the source or limit the rate of protocol
packets received by the interfaces in the whitelist.
Procedure
Step 3 Run auto-port-defend whitelist whitelist-number { acl acl-number | interface
interface-type interface-number }
The whitelist is configured.
A maximum of 16 whitelists can be configured on the device.
The ACL referenced by a whitelist can be a basic ACL, an advanced ACL, or a Layer
2 ACL. For details about ACL configuration, see 2 ACL Configuration.
By default, no whitelist is configured for port attack defense. After a port is
configured as a DHCP trusted port using the dhcp snooping trusted command,
the device automatically delivers whitelist matching rules regardless of whether
the port attack defense function is enabled. A maximum of 16 rules based on
source IP addresses and interfaces can be delivered. The device will not perform
port attack defense actions on the DHCP packets received on interfaces.
NOTE
All the packets matching an ACL referenced by a whitelist are considered to be valid packets
regardless of whether the ACL rule is permit or deny.
If an ACL has no rule, the whitelist that references the ACL does not take effect.
----End
3.6.8 Configuring the Report of Port Attack Defense Events

Context
If a port undergoes a DoS attack, the malicious attack packets sent from this port
to the CPU occupy bandwidth. As a result, the CPU cannot process the protocol
packets sent from other ports, and services are interrupted. In this situation, you
can enable the report of port attack defense events. When the rate of protocol

Switches
packets on a port exceeds the check threshold, the switch reports an event to
notify the network administrator, so that the administrator can promptly take
measures to protect the switch.
Procedure
Step 3 Run auto-port-defend enable
Port attack defense is enabled.
By default, the port attack defense function is enabled.
Step 4 Configure the report of port attack defense events.
1. Run auto-port-defend alarm enable
The report of port attack defense events is enabled.
By default, port attack defense events are not reported.
2. Run auto-port-defend protocol { all | arp-request | arp-reply | dhcp | icmp |
igmp | ip-fragment } threshold threshold
The rate threshold for port attack defense is set.
The following table lists the default rate thresholds for different protocols in
port attack defense.
Packet Type Rate Threshold
arp-request 60 pps for S5720EI, S6720S-EI, and

S6720EI; 120 pps for the S5720HI;
arp-reply 60 pps for S5720EI, S6720S-EI, and

dhcp 60 pps for S5720EI, S6720S-EI, and

icmp 120 pps for S5720HI and 60 pps for

other switch models
igmp 120 pps for S5720HI and 60 pps for

other switch models
ip-fragment 30 pps
----End

Switches
Context
After an attack defense policy is created, you must apply the policy in the system
view. Otherwise, the attack defense policy does not take effect.
Procedure
● Apply an attack defense policy.
b. Run the cpu-defend-policy policy-name global command to apply an
----End
3.6.10 Verifying the Port Attack Defense Configuration
Procedure
● Run the display auto-port-defend attack-source [ slot slot-id ] command to
view source tracing information on interfaces.
● Run the display auto-port-defend configuration command to view port
attack defense configuration on interfaces.
● Run the display auto-port-defend whitelist [ slot slot-id ] command to view
the port attack defense whitelist.
● Run the display auto-port-defend statistics [ slot slot-id ] command to view
packet statistics on port attack defense.
----End
3.7 Configuring the User-Level Rate Limiting
Before configuring the user-level rate limiting, connect interfaces and set physical
parameters for the interfaces to ensure that the physical status of the interfaces is
Up.
Before configuring the user-level rate limiting options, enable the user-level rate
limiting function first (enabled by default). The other tasks are performed in any
sequence and can be selected as required. By default, the user-level rate limiting is
enabled on interfaces. You can disable it on the interfaces where this function is
not required.

Switches
NOTE
● Only the S5720HI supports this function.

● It is recommended that you disable user-level rate limiting on the network-side
interfaces of an access switch and a gateway switch. The user-level rate limiting is
enabled on interfaces by default.
3.7.1 Enabling the User-Level Rate Limiting

Context
User-side hosts are prone to virus attacks. Infected hosts may send a large number
of protocol packets to network devices, causing a high CPU usage and degraded
performance on the devices and affecting services. You can configure the user-
level rate limiting to resolve this problem. User-level rate limiting identifies users
by user MAC addresses and limits the rates of specified packets (ARP, ND, DHCP
Request, DHCPv6 Request, IGMP, 802.1X, and HTTPS-SYN packets) for both wired
and wireless users. By default, the threshold for each user MAC address is 10 pps.
The user-level rate limiting is more precise than CPCAR (based on device) and port
attack defense (based on interface) because it is user-specific and has little impact
on online users.
Procedure
Step 2 Run cpu-defend host-car enable
The user-level rate limiting is enabled.
By default, the user-level rate limiting is enabled.
----End
3.7.2 Configuring the User-Level Rate Limit

Context
User-level rate limiting identifies users by user MAC addresses and limits the rates
of specified packets (ARP, ND, DHCP Request, DHCPv6 Request, IGMP, 802.1X, and
HTTPS-SYN packets) for both wired and wireless users. By default, the user-level
rate limit is 10 pps. You can set a rate limit based on user.
Procedure

Switches
Step 3 Run cpu-defend host-car [ mac-address mac-address | car-id car-id ] pps pps-
value
The user-level rate limit is set.
By default, the user-level rate limit is 10 pps.
----End
3.7.3 Specifying the Packet Types to Which the User-Level

Rate Limiting Applies
Context
By default, the switch limits the rates of the ARP, ND, DHCP Request, DHCPv6
Request, and 8021x packets received from user MAC addresses, and discards
excessive packets when the packet rates exceed the rate limit. If you need to limit
the rate of only IGMP and HTTPS-SYN packets or packets of the specified types,
specify the packet type.
Procedure
Step 3 Run cpu-defend host-car { { arp | dhcp-request | dhcpv6-request | igmp | nd |

8021x | https-syn } * | all }
The packet types to which the user-level rate limiting applies is specified.
By default, the user-level rate limiting can apply to ARP Request, ARP Reply, ND,
DHCP Request, DHCPv6 Request, and 8021x packets, but does not apply to IGMP
and HTTPS-SYN packets.
----End
3.7.4 Disabling User-Level Rate Limiting on Interface
Context
By default, the switch performs user-level rate limiting on the users connecting to
all interfaces. If you are sure that the users connecting to an interface are secure,
you can disable user-level rate limiting on this interface.

Switches
Procedure
Step 2 Run interface interface-type interface-number
The interface view is displayed.
Step 3 Run host-car disable
User-level rate limiting is disabled on the interface.
By default, the user-level rate limiting is enabled on all interfaces.
----End
3.7.5 Verifying the User-Level Rate Limiting Configuration

Procedure
● Run the display cpu-defend host-car [ mac-address mac-address ] statistics
[ slot slot-id ] command to view the number of packets discarded in user-
level rate limiting.
----End
3.8 Maintaining Local Attack Defense
3.8.1 Clearing Attack Source Information
Context
Before collecting updated statistics on attack sources, run the following command
in the system view to clear the existing statistics.
NOTICE
The cleared attack source information cannot be restored. Exercise caution when
you use the command.
Procedure
Step 1 Run the system-view command to enter the system view.
Step 2 Run the reset auto-defend attack-source [ history ] [ slot slot-id ] command to
clear information about the attack sources.
Step 3 Run the reset auto-defend attack-source trace-type { source-mac [ mac-
address ] | source-ip [ ip-address ] | source-portvlan [ interface interface-type

Switches
interface-number vlan-id vlan-id [ cvlan-id cvlan-id ] ] } [ slot slot-id ] command

to clear statistics on attack source tracing based on source MAC addresses, source
IP addresses, or a combination of source ports and VLANs.
----End
3.8.2 Clearing Statistics About Packets Sent to the CPU
Context
Before collecting updated statistics on packets sent to the CPU, run the following
command in the user view to clear the existing statistics.
NOTE
NOTICE
The cleared statistics cannot be restored. Exercise caution when you use the
command.
Procedure
Step 1 Run the reset cpu-defend statistics [ packet-type packet-type ] { all | slot slot-
id } command to clear statistics about packets sent to the CPU.
----End
3.8.3 Clearing History Records on Dynamic Adjustment of

Default CIR Values of Protocol Packets
Context
If you want to view the history records on dynamic adjustment of default CIR
values of protocol packets in a specified period, run the following command in the
user view to clear the previous records.
NOTE
Only the S5720HI, S5720EI, S5720SI, S5720S-SI, S5730SI, S5730S-EI, S6720LI, S6720S-LI,
S6720SI, S6720S-SI, S6720S-EI, and S6720EI support this command.
NOTICE
The history records cannot be restored after they are cleared. Exercise caution
when you run this command.

Switches
Procedure
Step 1 Run the reset cpu-defend dynamic-car history-record command to clear history
records on dynamic adjustment of default CIR values of protocol packets.
----End
3.8.4 Deleting Packet Statistics on Port Attack Defense
Context
Before collecting port attack defense statistics, run the following command in any
view to clear the existing statistics.
NOTE
NOTICE
Packet statistics cannot be restored after they are deleted. Exercise caution when
Procedure
Step 1 Run the reset auto-port-defend statistics [ all | slot slot-id ] command to delete
packet statistics about port attack defense.
----End
3.8.5 Clearing Packet Statistics in User-Level Rate Limiting
Context
Before collecting packet statistics in user-level rate limiting, run the following
command in the user view to clear the existing statistics.
NOTE
Only the S5720HI supports this function.
NOTICE
Packet statistics cannot be restored after they are deleted. Exercise caution when

Switches
Procedure
Step 1 Run the reset cpu-defend host-car [ mac-address mac-address ] statistics [ slot
slot-id ] command to clear packet statistics in user-level rate limiting.
----End
3.9 Example for Configuring Local Attack Defense
Networking Requirements
As shown in Figure 3-5, users on different network segments access the Internet
through the Switch. Because a large number of users connect to the Switch, the
Switch's CPU will receive a lot of protocol packets. If attackers send a lot of
malicious attack packets to the Switch, CPU usage will increase to affect services.
The network administrator has the following requirements:
● The network administrator wants to monitor CPU status. When the CPU is
attacked, the Switch can promptly notify the administrator and take measures
to protect the CPU.
● When the Switch receives a lot of ARP Request packets, the CPU usage of the
Switch greatly increases. The administrator wants to reduce CPU usage to
avoid impacting services.
● Users on Net1 often initiate attacks, so the administrator wants to reject
access by Net1 users.Net2 users are fixed authorized users.
● The administrator wants to upload files to the Switch through FTP, so data
transmission between the administrator's computer and the Switch must be
reliable and stable.
Figure 3-5 Networking diagram of local attack defense
Net1: 10.1.1.0/24
GE0/0/1
Internet
Net2: 10.2.2.0/24 Switch
Net3: 10.3.3.0/24
Configuration Roadmap
The configuration roadmap is as follows:

Switches
1. Configure attack source tracing, alarms, and punish function so that the
device can send an alarm to the administrator when detecting an attack
source and automatically take punish actions.
2. Add Net2 users to the whitelist to exclude them from attack source tracing
analysis and punishment.
3. Set the protocol rate threshold so that the Switch can limit the rate of
protocol packets based on ports and record a log. (Port attack defense is
enabled by default, so it does not need to be enabled again.)
4. Set the CPCAR for ARP Request packets to limit the rate of ARP Request
packets sent to the CPU. This reduces the impact of ARP Request packets on
the CPU.
5. Add Net1 users to the blacklist to reject their access.
6. Set the rate limit for the FTP packets sent to the CPU to ensure reliability and
stability of data transmission between the administrator's computer and the
Switch. (ALP is enabled for FTP by default, so it does not need to be enabled
again.)
Procedure
Step 1 Configure the rule for filtering packets sent to the CPU.
# Define ACL rules.
<HUAWEI> system-view
[HUAWEI] sysname Switch
[Switch] acl number 2001
[Switch-acl-basic-2001] rule permit source 10.1.1.0 0.0.0.255
[Switch-acl-basic-2001] quit
[Switch] acl number 2002
[Switch-acl-basic-2002] rule permit source 10.2.2.0 0.0.0.255
[Switch-acl-basic-2002] quit
Step 2 Configure an attack defense policy.

# Create an attack defense policy.
[Switch] cpu-defend policy policy1
# Configure attack source tracing.

[Switch-cpu-defend-policy-policy1] auto-defend enable
# Enable the alarm function for attack source tracing.

[Switch-cpu-defend-policy-policy1] auto-defend alarm enable
# Configure a whitelist for attack source tracing.
NOTE
Add the IP addresses of valid servers, interconnected interfaces, and IP address of network
management device to the whitelist.
[Switch-cpu-defend-policy-policy1] auto-defend whitelist 1 acl 2002
# Set the punish action to discard.

NOTE
Before configuring the punish action, ensure that the device is undergoing an attack; otherwise,
the punish action may discard a lot of valid protocol packets.

Switches
[Switch-cpu-defend-policy-policy1] auto-defend action deny
# Set the rate threshold to 40 pps. (Port attack defense is enabled by default, so it
does not need to be enabled again.)
[Switch-cpu-defend-policy-policy1] auto-port-defend protocol arp-request threshold 40
# Add the network-side interface GE0/0/1 to the whitelist so that the CPU can
promptly process the packets from the network-side interface.
[Switch-cpu-defend-policy-policy1] auto-port-defend whitelist 1 interface gigabitethernet 0/0/1
# Set the CPCAR of ARP Request packets to 120 kbit/s.

[Switch-cpu-defend-policy-policy1] car packet-type arp-request cir 120
Warning: Improper parameter settings may affect stable operating of the system. Use this command under
assistance of Huawei engineers. Continue? [Y/N]:y
# Configure the blacklist for CPU attack defense.

[Switch-cpu-defend-policy-policy1] blacklist 1 acl 2001
# Set the CIR of FTP packets sent to the CPU to 5000 kbit/s.
[Switch-cpu-defend-policy-policy1] linkup-car packet-type ftp cir 5000
[Switch-cpu-defend-policy-policy1] quit
Step 3 Apply the attack defense policy globally.

[Switch] cpu-defend-policy policy1 global
[Switch] quit
Step 4 Verify the configuration.

# Display the configuration of attack source tracing.
<Switch> display auto-defend configuration
----------------------------------------------------------------------------
Name : policy1
Related slot : <0>
auto-defend : enable
auto-defend attack-packet sample : 5
auto-defend threshold : 60 (pps)
auto-defend alarm : enable
auto-defend trace-type : source-mac source-ip
auto-defend protocol : arp icmp dhcp igmp tcp telnet 8021x
auto-defend action : deny (Expired time : 300 s)
auto-defend whitelist 1 : acl number 2002
----------------------------------------------------------------------------
# Display the configuration of port attack defense.

<Switch> display auto-port-defend configuration
----------------------------------------------------------------------------
Name : policy1
Related slot : <0>
Auto-port-defend : enable
Auto-port-defend sample :5
Auto-port-defend aging-time : 300 second(s)
Auto-port-defend arp-request threshold : 40 pps(enable)
Auto-port-defend arp-reply threshold : 30 pps(enable)
Auto-port-defend dhcp threshold : 30 pps(enable)
Auto-port-defend icmp threshold : 30 pps(enable)
Auto-port-defend igmp threshold : 60 pps(enable)
Auto-port-defend ip-fragment threshold : 30 pps(enable)
Auto-port-defend alarm : disable
----------------------------------------------------------------------------
# Display the configuration of the attack defense policy.

<Switch> display cpu-defend policy policy1
Related slot : <0>
Configuration :

Switches
Blacklist 1 ACL number : 2001

Car packet-type arp-request : CIR(120) CBS(22560)
Linkup-car packet-type ftp : CIR(5000) CBS(940000)
# Display the CPCAR setting.

<Switch> display cpu-defend configuration packet-type arp-request slot 0
Car configurations on slot 0.
----------------------------------------------------------------------
Packet Name Status Cir(Kbps) Cbs(Byte) Queue Port-Type
----------------------------------------------------------------------
arp-request Enabled 120 22560 3 UNI
----------------------------------------------------------------------
----End
Configuration Files
Switch configuration file
#
sysname Switch
#
acl number 2001
rule 5 permit source 10.1.1.0 0.0.0.255
acl number 2002
#
cpu-defend policy policy1
blacklist 1 acl 2001
car packet-type arp-request cir 120 cbs 22560
linkup-car packet-type ftp cir 5000 cbs 940000
auto-defend alarm enable
auto-defend action deny
auto-defend whitelist 1 acl 2002
auto-port-defend protocol arp-request threshold 40
auto-port-defend whitelist 1 interface GigabitEthernet0/0/1
#
cpu-defend-policy policy1 global
#
return
Related Content
Videos
Configure Attack Source Tracing
3.10 Example for Configuring Attack Source Tracing
Networking Requirements
As shown in Figure 3-6, users on different network segments access the Internet
through SwitchA. Because there are a large number of access users, SwitchA often
processes a large number of ARP packets, leading to a high CPU usage and hence
affecting services. The administrator requires that the device analyze the ARP
packets sent to the CPU, identify the packets whose rate exceeds the threshold as
attack packets, find out the attack source user or source interface, and send logs
and alarms to notify the administrator so that the administrator can take security
measures to protect the CPU. Users on Net2 are fixed authorized users, so the

Switches
administrator needs to ensure that ARP packets of these users can be sent to the
CPU.
Figure 3-6 Networking diagram of attack source tracing
Net1: 10.1.1.0/24
GE0/0/1
Internet
Net2: 10.2.2.0/24 SwitchA RouterA
Net3: 10.3.3.0/24
Configuration Roadmap
1. Configure the attack source tracing function, threshold, and type of the
packets to be defended against, and enable the device to trace and analyze
the ARP packets whose rate exceeds the threshold.
2. Configure the attack source tracing mode based on the source IP address and
source MAC address.
3. Configure the attack source tracing alarm function so that the device can
send an alarm to the administrator when detecting an attack source.
Configure the attack source tracing punishment function and specify the
punishment action to discard attack packets.
4. Add users on Net2 to the whitelist to exclude them from attack source tracing
analysis and punishment.
Procedure
Step 1 Configure an attack defense policy.
# Create an attack defense policy.
<HUAWEI> system-view
[HUAWEI] sysname SwitchA
[SwitchA] cpu-defend policy policy1
# Configure attack source tracing.

[SwitchA-cpu-defend-policy-policy1] auto-defend enable
# Configure the attack source tracing threshold.

[SwitchA-cpu-defend-policy-policy1] auto-defend threshold 60
# Configure the type of packets to which attack source tracing is applied.

[SwitchA-cpu-defend-policy-policy1] auto-defend protocol arp

Switches
# Configure the attack source tracing mode.

[SwitchA-cpu-defend-policy-policy1] auto-defend trace-type source-ip source-mac
# Enable the alarm function for attack source tracing.

[SwitchA-cpu-defend-policy-policy1] auto-defend alarm enable
# Enable the punishment function for attack source tracing.
NOTE
Before configuring the punishment action, ensure that the device is under attack; otherwise, the
device may discard a lot of valid protocol packets according to the configured punishment
action.
[SwitchA-cpu-defend-policy-policy1] auto-defend action deny timer 300
[SwitchA-cpu-defend-policy-policy1] quit
# Configure a whitelist for attack source tracing.
NOTE
You are advised to add the IP addresses of valid servers, interconnected interfaces, and IP
address of the network management device to the whitelist.
[SwitchA] acl number 2001
[SwitchA-acl-basic-2001] rule permit source 10.2.2.0 0.0.0.255
[SwitchA-acl-basic-2001] quit
[SwitchA] cpu-defend policy policy1
[SwitchA-cpu-defend-policy-policy1] auto-defend whitelist 1 acl 2001
[SwitchA-cpu-defend-policy-policy1] quit
Step 2 Apply the attack defense policy globally.

[SwitchA] cpu-defend-policy policy1 global
[SwitchA] quit
Step 3 Verify the configuration.

# Display the configuration of attack source tracing.
<SwitchA> display auto-defend configuration
----------------------------------------------------------------------------
Name : policy1
Related slot : <0>
auto-defend : enable
auto-defend attack-packet sample : 5
auto-defend threshold : 60 (pps)
auto-defend alarm : enable
auto-defend trace-type : source-mac source-ip
auto-defend protocol : arp
auto-defend action : deny (Expired time : 300 s)
auto-defend whitelist 1 : acl number 2001
----------------------------------------------------------------------------
# Display information about the attack source after a period of time.

<SwitchA> display auto-defend attack-source
Attack Source User Table (slot 0):
-----------------------------------------------------------------------------
MacAddress InterfaceName Vlan:Outer/Inner TotalPackets
-----------------------------------------------------------------------------
0000-c103-0102 GigabitEthernet0/0/1 10 1395
-----------------------------------------------------------------------------
Total: 1
Attack Source Port Table (slot 0):

------------------------------------------------------------
InterfaceName Vlan:Outer/Inner TotalPackets

Switches
------------------------------------------------------------
GigabitEthernet0/0/1 10 605
------------------------------------------------------------
Total: 1
----End
Configuration Files
SwitchA configuration file
#
sysname SwitchA
#
acl number 2001
#
cpu-defend policy policy1
auto-defend alarm enable
auto-defend protocol arp
auto-defend action deny
auto-defend whitelist 1 acl 2001
#
cpu-defend-policy policy1 global
#
return
Related Content
Videos
Configure Attack Source Tracing
3.11 Troubleshooting Local Attack Defense
3.11.1 Attack Source Tracing Does Not Take Effect
Fault Description
Attack source tracing does not take effect after attack source tracing is configured.
Common Causes
Possible causes are as follows:
● The attack defense policy is not applied to any object.
● The checking threshold for attack source tracing is large.
Procedure
Step 1 Determine whether the attack defense policy configured with attack source tracing
is applied.
1. Run the display this command in the system view to check whether the cpu-
defend-policy command has been configured.

Switches
2. Or run the display auto-defend configuration command to check the name

of the attack defense policy and the slot ID to which the policy is applied.
3. If the policy is not configured, run the cpu-defend-policy command in the
system view to configure the policy. If the policy is configured, go to the next
step.
Step 2 Check whether the checking threshold for attack source tracing is large.
Run the display auto-defend configuration command to check the value in the
auto-defend threshold field. If the value is large, run the auto-defend threshold
command in the attack defense policy view to reduce the value.
----End
3.11.2 Protocol Packets Are Not Sent to the CPU
Fault Description
Protocol packets are not sent to the CPU after CPU attack defense is configured.
Common Causes
● A blacklist has been configured or a rule is configured to discard the specified
protocol packets.
● The CPU is attacked by invalid packets.
Procedure
Step 1 Check whether a rule has been configured to discard protocol packets on the
device.
1. Run the display this command in the system view to check the configured
2. Run the display cpu-defend policy [ policy-name ] command to check
whether a blacklist, or rule is configured in an attack defense policy to discard
protocol packets.
– If a blacklist is configured, run the display acl command to check
whether protocol packets match the rules in the blacklist. If protocol
packets match the rules, adjust the rules as required. Otherwise, go to the
next step.
– If the action taken on the protocol packets sent to the CPU is deny, run
the car command in the attack defense policy view to set the rate limit.
– If no blacklist is configured, and the action taken on the protocol packets
sent to the CPU is not deny, go to step 2.
Step 2 Check statistics for packets sent to the CPU.
Run the display cpu-defend statistics [ packet-type packet-type ] [ all | slot
slot-id ] command to check statistics on packets sent to the CPU. If a large
number of protocol packets are being discarded, check whether these packets are
invalid attack packets using the attack source tracing function. If they are invalid

Switches
attack packets, use the configured blacklist or traffic policy to prevent these
packets from being sent to the CPU.
----End
3.11.3 The Blacklist Does Not Take Effect
Fault Description
The configured blacklist does not take effect.
Common Causes
● Packets do not match the rules in the blacklist.
● ACL resources are insufficient.
Procedure
Step 1 Run the display cpu-defend policy policy-name command to check the attack
defense policy.
Step 2 Check the ACL of the blacklist in the displayed attack defense policy information,
and run the display acl acl-number command to check whether service packets
match the ACL rule.
Step 3 If service packets do not match the ACL rule, run the rule command in the ACL
view to modify the ACL rule. If service packets match the ACL rule, the blacklist
may fail to be applied because ACL resources are insufficient.
----End
3.12 FAQ About Local Attack Defense
3.12.1 How Can the CPU Be Protected from DHCPv6

Messages?
Run the display cpu-defend statistics command to check the statistics on CPCAR
packets. If a large number of DHCPv6 messages are discarded, check whether IPv6
is required. If IPv6 is not required, configure an attack defense policy to directly
discard DHCPv6 messages.
Run the undo dhcp snooping enable ipv6 command to disable DHCPv6 snooping
on the switch in V200R001 and later versions.
3.12.2 What Is the Effect of Excess ARP Reply Packets on the

CPU?
If excess ARP Reply packets are sent to the CPU, the CPU may be overloaded. Run
the display cpu-defend configuration packet-type arp-reply all and display

Switches
cpu-defend statistics packet-type arp-reply all commands to whether excess

ARP Reply packets are sent to the CPU.
In the display cpu-defend statistics packet-type arp-reply all command output.

if the value of the Drop (Bytes) field is large, excess ARP Reply packets are sent to
the CPU.
In this case, adjust the CIR value for the ARP Reply packet. If the CPU is attacked,
obtain the packet header or enable the debugging to trace the attack source and
add the attack source to the blacklist.
NOTICE
Improper CPCAR settings will affect services on your network. If you need to
adjust CPCAR settings, you are advised to contact technical support personnel for
help.
3.12.3 How Can I Identify an Attack and How Can I Prevent

Attacks?
You can detect common attacks as follows:
1. Clear statistics on the packets sent to the CPU.

2. Wait for one minute and check the number of packets sent to the CPU and
discarded protocol packets, such as ICMP, TTL, Expired, SSH, and FTP. If there
are a lot of packets sent to the CPU or discarded, an attack, such as ICMP
attack, TTL Expired attack, SSH attack, or FTP attack, may occur.
3. Find out the attack source through IP source trail or attack source tracing.
After locating the attack source, run the cpu-defend policy command to
configure the blacklist to prevent the packets from this source entering the control
plane. Alternatively, you can configure the penalty action in auto-defend to
discard attack packets.
Additionally, the device can restrict the rate of ICMP packets from the source, or
use traffic policy to discard SSH and FTP attack packets.
3.13 Attack Defense Packet Types

The listed attack defense packet types are only for your reference. To view the
attack defense packet types supported by the switch, run the display cpu-defend
configuration slot slot-id command.
S1720GFR
Packet Type Explanation
8021x 802.1X packet
arp-reply ARP reply packet

Switches
arp-request ARP Request packet
bpdu BPDU packet
bpdu-tunnel BPDU Tunnel packet
dhcp-client DHCP client packet
dhcp-server DHCP server packet
eth-ring SMLK RRPP SEP ERPS packet
fib-hit Host route hit packet
ftp FTP packet
https HTTPS packet
icmp ICMP packet
igmp IGMP packet
lacp LACP packet
ldt LDT packet
lnp LNP packet
nd IPv6 ND packet
ospf OSPF packet
pppoe PPPOE packet
rip RIP packet
stp STP packet
telnet Telnet packet
vbst VBST packet
vbst-trunk VBST packet for Eth-trunk
vrrp VRRP packet
S1720X/S1720X-E
8021x 802.1X packet

Switches
bfd BFD packet
bgp BGP packet
bpdu BPDU packet
ftp FTP packet
https HTTPS packet
icmp ICMP packet
igmp IGMP packet
isis ISIS packet
lacp LACP packet
ldt LDT packet
lnp LNP packet
nd IPv6 ND packet
ospf OSPF packet
pim PIM packet
pppoe PPPOE packet
rip RIP packet
stp STP packet
udp-helper UDP helper packet
vbst VBST packet
vrrp VRRP packet

Switches
S2720EI
8021x 802.1X packet
bpdu BPDU packet
capwap-ctrl CAPWAP control packet
ftp FTP packet
https HTTPS packet
icmp ICMP packet
igmp IGMP packet
lacp LACP packet
ldt LDT packet
lnp LNP packet
nd IPv6 ND packet
ospf OSPF packet
pppoe PPPOE packet
rip RIP packet
stp STP packet
vbst VBST packet
vrrp VRRP packet

Switches
S2750EI
8021x 802.1X packet
bpdu BPDU packet
dhcpv6-reply DHCPv6 reply packet
dhcpv6-request DHCPv6 request packet
ftp FTP packet
https HTTPS packet
icmp ICMP packet
igmp IGMP packet
lacp LACP packet
ldt LDT packet
lnp LNP packet
nd IPv6 ND packet
pppoe PPPOE packet
rip RIP packet
stp STP packet
vbst VBST packet

Switches
S5700LI/S5700S-LI
8021x 802.1X packet
bpdu BPDU packet
ftp FTP packet
https HTTPS packet
icmp ICMP packet
igmp IGMP packet
lacp LACP packet
ldt LDT packet
lnp LNP packet
nd IPv6 ND packet
pppoe PPPOE packet
rip RIP packet
stp STP packet
vbst VBST packet

Switches
S5710-X-LI
8021x 802.1X packet
bpdu BPDU packet
ftp FTP packet
https HTTPS packet
icmp ICMP packet
igmp IGMP packet
lacp LACP packet
ldt LDT packet
lnp LNP packet
nd IPv6 ND packet
pppoe PPPOE packet
rip RIP packet
stp STP packet
vbst VBST packet

Switches
S1720GW/S1720GWR/S1720GW-E/S1720GWR-E
8021x 802.1X packet
bpdu BPDU packet
ftp FTP packet
https HTTPS packet
icmp ICMP packet
igmp IGMP packet
lacp LACP packet
ldt LDT packet
lnp LNP packet
nd IPv6 ND packet
ospf OSPF packet
pppoe PPPOE packet
rip RIP packet
stp STP packet
vbst VBST packet
vrrp VRRP packet

Switches
S5720LI/S5720S-LI
8021x 802.1X packet
bpdu BPDU packet
ftp FTP packet
https HTTPS packet
icmp ICMP packet
igmp IGMP packet
lacp LACP packet
ldt LDT packet
lnp LNP packet
nd IPv6 ND packet
ospf OSPF packet
pppoe PPPOE packet
rip RIP packet
stp STP packet
vbst VBST packet
vrrp VRRP packet

Switches
S5720SI/S5720S-SI
8021x 802.1X packet
bfd BFD packet
bgp BGP packet
bpdu BPDU packet
ftp FTP packet
https HTTPS packet
icmp ICMP packet
igmp IGMP packet
isis ISIS packet
lacp LACP packet
ldt LDT packet
lnp LNP packet
nd IPv6 ND packet
ospf OSPF packet
pim PIM packet
pppoe PPPOE packet
rip RIP packet
stp STP packet
vbst VBST packet

Switches
vrrp VRRP packet
S5720EI
8021x 802.1X packet
8021x-ident 802.1X identity packet
8021x-start 802.1X start packet
arp-mff MFF ARP packet
arp-miss ARP MISS packet
asdp ASDP packet
asdp-port ASDP port packet
bfd BFD packet
bgp BGP packet
bgp4plus BGP4PLUS packet
bpdu BPDU packet
cdp CDP packet
dldp DLDP packet
dns DNS packet
easy-operation Easy operation packet
eoam-1ag Eth-OAM 1ag packet

Switches
eoam-1ag-lblt Eth-OAM 1ag lblt packet
eoam-3ah Eth-OAM 3ah packet
erps-port ERPS port packet
fib-miss Host route miss packet
ftp FTP packet
gre-keepalive GRE keepalive packet
gvrp GVRP packet
hopbyhop IPv6 hopbyhop packet
hop-limit HOPLIMIT packet
http HTTP packet
https HTTPS packet
hw-tacacs HW-TACACS packet
icmp ICMP packet
icmp-ttl-expired ICMP TTL expired packet
icmpv6 ICMPv6 packet
igmp IGMP packet
ike Internet Key Exchange packet
ip-cloud NETCONF packet
ipsec-ah IPSec ah packet
ipsec-esp IPSec esp packet
isis ISIS packet
lacp LACP packet
ldt LDT packet
lldp LLDP packet
lnp LNP packet
loopbacktest Loopback-test packet
mad MAD packet
mdns MDNS packet
mld MLD packet

Switches
mpls-fib-hit Route hit packet after MPLS label

terminated
mpls-ldp MPLS LDP packet
mpls-one-label MPLS label-alert packet
mpls-ping MPLS PING packet
mpls-rsvp MPLS RSVP packet
mpls-ttl-expired MPLS TTL expired packet
mpls-vccv-ping MPLS VCCV PING packet
nac-arp-reply ARP reply packet for NAC
nac-arp-request ARP Request packet for NAC
nac-dhcpv6 DHCPV6 packet for NAC
nac-nd ND packet for NAC
nd IPv6 ND packet
ntdp NTDP packet
ntp NTP packet
ospf OSPF packet
ospf-hello OSPF Hello packet
ospfv3 OSPFv3 packet
pim PIM packet
pimv6 PIMv6 packet
portal Portal packet
pppoe PPPOE packet
radius RADIUS packet
rip RIP packet
ripng RIPng packet
rrpp RRPP packet
sep-global SEP global packet
sep-port SEP port packet
smart-link Smart link packet
snmp SNMP packet

Switches
ssh SSH packet
stp STP packet
tcp TCP packet
ttl-expired IPv4 TTL expired packet
twamp TWAMP packet
vbst VBST packet
vcmp VCMP packet
vpls-igmp IGMP packet over VPLS
vrrp VRRP packet
vrrp6 VRRP6 packet
y1731 Y.1731 packet
S5720HI
8021x 802.1X packet
8021x-ident-wlan 802.1X identity wlan packet
8021x-start-wlan 802.1X start wlan packet
8021x-wireless 802.1X wireless packet
asdp ASDP packet
bfd BFD packet

Switches
bgp BGP packet
bpdu BPDU packet
capwap-ap-auth Authentication packet sent by a

remote unit (RU) when registering
with a central AP
capwap-association CAPWAP association packet
capwap-disassoc CAPWAP disassoc packet
capwap-discov-bc CAPWAP-discovery-broadcast packet
capwap-discov-uc CAPWAP-discovery-unicast packet
capwap-echo CAPWAP echo packet
capwap-keepalive CAPWAP keepalive packet
capwap-regular-rep Packet reported by an AP regularly
capwap-rf-neighbor CAPWAP radio calibration packet
capwap-smart-roam CAPWAP packets transmitted during

smart roaming
capwap-other CAPWAP-OTHER packet
cdp CDP packet
dldp DLDP packet
dns DNS packet
eap-key EAP-KEY packet used in WPA/WPA2

PSK mode

Switches
fib6-hit IPv6 FIB HIT packet
ftp FTP packet
gvrp GVRP packet
hopbyhop IPv6 hopbyhop packet
http HTTP packet
https HTTPS packet
https-other HTTPS-OTHER packet
https-syn HTTPS-SYN packet
icmp ICMP packet
igmp IGMP packet
ipfpm IPFPM packet
isis ISIS packet
lacp LACP packet
ldt LDT packet
lldp LLDP packet
lnp LNP packet
lync LYNC packet
mad MAD packet
mdns MDNS packet

Switches
mld MLD packet

terminated
nac-http HTTP packet for NAC
nd IPv6 ND packet
nd-miss ND MISS packet
ntdp NTDP packet
ntp NTP packet
ospf OSPF packet
pim PIM packet
pimv6 PIMv6 packet
pppoe PPPOE packet
rip RIP packet
ripng RIPng packet
rrpp RRPP packet

Switches
snmp SNMP packet
ssh SSH packet
stp STP packet
tcp TCP packet
twamp TWAMP packet
udp-helper VCMP packet
vbst VBST packet
vcmp VCMP packet
vpls-arp ARP packet over VPLS
vpls-dhcp-reply DHCP reply packet over VPLS
vpls-dhcp-request DHCP request packet over VPLS
vrrp VRRP packet
vrrp6 VRRP6 packet
wapi WAPI packet
y1731 Y.1731 packet
S6720LI/S6720S-LI
8021x 802.1X packet
bpdu BPDU packet

Switches
ftp FTP packet
https HTTPS packet
icmp ICMP packet
igmp IGMP packet
lacp LACP packet
ldt LDT packet
lnp LNP packet
nd IPv6 ND packet
ospf OSPF packet
pppoe PPPOE packet
rip RIP packet
stp STP packet
vbst VBST packet
vrrp VRRP packet
S6720SI/S6720S-SI/S5730SI/S5730S-EI
8021x 802.1X packet
bfd BFD packet
bgp BGP packet

Switches
bpdu BPDU packet
ftp FTP packet
https HTTPS packet
icmp ICMP packet
igmp IGMP packet
isis ISIS packet
lacp LACP packet
ldt LDT packet
lnp LNP packet
nd IPv6 ND packet
ospf OSPF packet
pim PIM packet
pppoe PPPOE packet
rip RIP packet
stp STP packet
vbst VBST packet
vrrp VRRP packet

Switches
S6720EI/S6720S-EI
8021x 802.1X packet
asdp ASDP packet
asdp-port ASDP port packet
bfd BFD packet
bgp BGP packet
bpdu BPDU packet
cdp CDP packet
dldp DLDP packet
dns DNS packet

Switches
ftp FTP packet
gvrp GVRP packet
http HTTP packet
https HTTPS packet
icmp ICMP packet
igmp IGMP packet
ipsec-ah IPSec ah packet
isis ISIS packet
lacp LACP packet
ldt LDT packet
lldp LLDP packet
lnp LNP packet
mad MAD packet
mdns MDNS packet
mld MLD packet

terminated

Switches
nd IPv6 ND packet
ntdp NTDP packet
ntp NTP packet
ospf OSPF packet
pim PIM packet
pimv6 PIMv6 packet
pppoe PPPOE packet
rip RIP packet
ripng RIPng packet
rrpp RRPP packet
snmp SNMP packet
ssh SSH packet
stp STP packet
tcp TCP packet
twamp TWAMP packet

Switches
vbst VBST packet
vcmp VCMP packet
vrrp VRRP packet
vrrp6 VRRP6 packet
y1731 Y.1731 packet

01-03 Local Attack Defense Configuration

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

01-03 Local Attack Defense Configuration

Uploaded by

Copyright:

Available Formats

S1720, S2700, S5700, and S6720 Series Ethernet

3 Local Attack Defense Configuration

About This Chapter

3.1 Overview of Local Attack Defense

3.1 Overview of Local Attack Defense

Issue 12 (2020-11-15) Copyright © Huawei Technologies Co., Ltd. 152

● CPU Attack Defense

Figure 3-1 Rate limiting for packets sent to the CPU

Rate limiting based Rate limiting and scheduling Rate limiting

If the traffic volume of a protocol is too large, other protocol packets

Issue 12 (2020-11-15) Copyright © Huawei Technologies Co., Ltd. 153

Issue 12 (2020-11-15) Copyright © Huawei Technologies Co., Ltd. 154

Figure 3-2 Attack source tracing processes

Attack source tracing

Attack source tracing provides the whitelist function. After an ACL is

Issue 12 (2020-11-15) Copyright © Huawei Technologies Co., Ltd. 155

3.2 Licensing Requirements and Limitations for Local

Involved Network Elements

Table 3-1 Products and versions supporting local attack defense

Product Product Software Version

S1700 S1720GFR V200R006C10, V200R009C00, V200R010C00,

Issue 12 (2020-11-15) Copyright © Huawei Technologies Co., Ltd. 156

Product Product Software Version

S1720GW V200R010C00, V200R011C00, V200R011C10

S1720GW- V200R010C00, V200R011C00, V200R011C10

S1720X V200R011C00, V200R011C10

Other Models that cannot be configured using commands.

S2700 S2700SI V100R005C01, V100R006(C00&C01&C03&C05)

S2700EI V100R005C01, V100R006(C00&C01&C03&C05)

S2720EI V200R006C10, V200R009C00, V200R010C00,

S2750EI V200R003C00, V200R005C00SPC300, V200R006C00,

S3700 S3700SI V100R005C01, V100R006(C00&C01&C03&C05)

S3700HI V100R006C01, V200R001C00

S5700 S5700LI V200R001C00, V200R002C00,

S5700S-LI V200R001C00, V200R002C00, V200R003C00,

S5710-X-LI V200R008C00, V200R009C00, V200R010C00,

S5700SI V100R005C01, V100R006C00, V200R001C00,

Issue 12 (2020-11-15) Copyright © Huawei Technologies Co., Ltd. 157

Product Product Software Version

S5700EI V100R005C01, V100R006(C00&C01),

S5710EI V200R001C00, V200R002C00, V200R003C00,

S5720EI V200R007C00, V200R008C00, V200R009C00,

S5720LI V200R010C00, V200R011C00, V200R011C10

S5720SI V200R008C00, V200R009C00, V200R010C00,

S5700HI V100R006C01, V200R001(C00&C01), V200R002C00,

S5710HI V200R003C00, V200R005(C00&C02&C03)

S5720HI V200R006C00, V200R007(C00&C10), V200R008C00,

S6700 S6700EI V100R006C00, V200R001(C00&C01), V200R002C00,

S6720LI V200R011C00, V200R011C10

S6720SI V200R011C00, V200R011C10

S6720EI V200R008C00, V200R009C00, V200R010C00,

S6720S-EI V200R009C00, V200R010C00, V200R011C00,

Issue 12 (2020-11-15) Copyright © Huawei Technologies Co., Ltd. 158

Table 3-2 Precedence between CPCAR and traffic policies

S1720GFR, S1720GW-E, S1720GWR- Traffic policies take precedence over

S6720EI, S5720EI, S5720HI, S6720S- CPCAR takes precedence over traffic

3.3 Default Settings for Local Attack Defense

Issue 12 (2020-11-15) Copyright © Huawei Technologies Co., Ltd. 159

Table 3-3 Default settings for CPU attack defense

CPU attack defense policy CPU attack defense policy named

User-defined flow None

Type of interfaces sending packets to NNI

Type of interfaces sending protocol To check the type of interfaces sending

CIR value By default, the device limits the rates