This post highlights the Attack Defense for S series switches as part of the All About Switches section. Please have a look below for more details.

Huawei S Series switches

Contents

1 Attack Processing for S Series Switches

1.1 Attack Defense Overview

1.2Determining the Attack Type

1.3 Defense Measures for Different Types of Attacks

1.3.1 ARP Attack

1.3.1.1 ARP Flood

1.3.1.2 ARP Spoofing

1.3.2 ARP Miss Attack

1.3.2.1 Network Scanning Attack

1.3.3 DHCP Attack

1.3.3.1 Bogus DHCP Server Attack

1.3.3.2 DHCP Flooding Attack

1.3.3.3 DHCP Server DoS Attack

1.3.3.4 DHCP Packets Incorrectly Sent to the CPU

1.3.3.5 DHCP Spoofing

1.3.4 ICMP Attack

1.3.5 TTL Attack

1.3.6 TCP Attack

1.3.7 OSPF Attack

1.3.8 TC Attack

1.3.9SSH/Telnet Attack

1.3.10 VRRP Attack

1.3.11 IGMP Attack

1.3.12 PIM Attack

2 Recommended Local Attack Defense Configuration

2.1 Modular Switches

2.2 Fixed Switches

3 A Appendix

3.1 Applying the Attack Defense Policy

1 Attack Processing for S Series Switches

1.1 Attack Defense Overview

On networks, there are many risks that may cause overload on the control plane. For example, a large number of viruses and hacker tools are flooded on networks. These viruses and hacker tools may attack network devices, resulting in network breakdown. Address Resolution Protocol (ARP) and Internet Control Message Protocol (ICMP) attacks are often initiated. Attackers use viruses and hacker tools to preempt resources of attacked devices, causing service interruption on the attacked devices. If switches respond to ICMP and ARP packets unconditionally, the CPU usage becomes high when the switches are attacked by viruses. Signaling protocols on the control plane may fail or even switches fail to respond to valid ARP Request packets. Consequently, the switches may break down, causing service interruption.

To solve the preceding problem, switches provide security functions and the functions are increasingly optimized. As a main security function on switches, the central processor committed access rate (CPCAR) function allows switches to classify packets sent to the control plane, limit the rate of these packets, and schedule the packets in queues to ensure security of the control plane.

Figure 1-1 shows the local attack defense process. The forwarding plane and control plane of the device are protected on hardware and software.

Figure 1-1 Local attack defense

Local attack defense is implemented based on the following levels:

l Level 1: Identify packets to be sent to the control plane, limit the rate of packets, or discard packets. The attack defense methods include the CPCAR, blacklist, access control list (ACL), and traffic suppression.

l Level 2: Adjust and shape various protocol packets using queues. The attack defense methods include the protocol queue adjustment, CPU interface rate limiting, and CPU queue rate limiting (fixed switches).

l Level 3: Limit the rate of various protocol packets, use anti-spoofing functions, and identify attack sources using auto-defend. This level is located on the control plane. The attack defense methods include protocol security, ARP anti-spoofing, attack source tracing, and traffic rate limiting.

1.2 Determining the Attack Type

When a switch is attacked, the following problems may occur:

l Users cannot obtain ARP information.

l The CPU usage of the switch is high.

l Users connected to the switch can hardly get online.

l Some users cannot access the network.

l If the problem is severe, all users connected to the switch cannot access the network.

When the preceding situations occur on many users or all users connected to an interface, check whether an attack occurs.

Step 1 Run the display cpu-usage command to check the CUP usage on the switch, which is specified by the CPU Usagefield. The TaskName field indicates the name of a task that is running.

<HUAWEI> display cpu-usage
CPU Usage Stat. Cycle: 60 (Second)
CPU Usage            : 11% Max: 94%
CPU Usage Stat. Time : 2017-06-19 15:18:54
CPU utilization for five seconds: 11%: one minute: 11%: five minutes: 11%
Max CPU Usage Stat. Time : 2017-06-06 06:57.

TaskName        CPU Runtime(CPU Tick High/Tick Low) Task Explanation
VIDL                 89%         e/eb7733fe       DOPRA IDLE
OS                    8%         1/57529fff       Operation System
bcmRX                20%         0/ 17a14c       bcmRX
FTS                  20%         0/   ff707       FTS
SOCK                 20%         0/ 26ac89       SOCKPacket sched
                                                  ule and process
VPR                   0%         0/ 16e3600       VPR VP Receive

If the CPU usage is continuously high and the CPU usage of the bcmRX, FTS, SOCK, or VPR task is high (typically caused by an attack of a specified type of protocol packets), the switch may receive a large number of packets. Then go to step 2 to check the protocol packet type.

A switch is considered running normally if its long-term average CPU usage does not exceed 80% and its highest temporary CPU usage does not exceed 95%.

Step 2 Run the display cpu-defend statistics allcommand to check whether a large number of protocol packets are discarded and whether the CPCAR value of a specified protocol is increased on the live network. If a large number of packets of a specified protocol are discarded because the rate of these protocol packets exceeds the CPCAR value, an attack has been initiated on the live network. Take attack defense measures based on the type of the discarded protocol packets. Table 1-1 lists the possibly discarded protocol packets.

<HUAWEI> display cpu-defend statistics all
Statistics on mainboard:
--------------------------------------------------------------------------------
Packet Type          Pass(Packet/Byte)   Drop(Packet/Byte) Last-dropping-time
--------------------------------------------------------------------------------
arp-mff                              0                   0    -
                                     0                   0
arp-miss                             0                   0    -
                                     0                   0
arp-reply                            0                   0   -
                                     0                   0
arp-request                       8423                1284    2017-06-06 06:57
...

Table 1-1 Possibly discarded protocol packets and attack types

Packet Type	Attack Type
arp-reply, arp-request	1.3.1 ARP Attack, 1.3.8 TC Attack
arp-miss	1.3.2 ARP Miss Attack
dhcp-client, dhcp-server, dhcpv6-reply, dhcpv6-request	1.3.3 DHCP Attack
icmp	1.3.4 ICMP Attack
ttl-expired	1.3.5 TTL Attack
tcp	1.3.6 TCP Attack
ospf	1.3.7 OSPF Attack
ssh, telnet	1.3.9 SSH/Telnet Attack
vrrp	1.3.10 VRRP Attack
igmp	1.3.11 IGMP Attack
pim	1.3.12 PIM Attack

Switches running V200R003 and later versions support port attack defense. Even if the value of Drop does not increase, attacks may still exist on these switches. Therefore, go to step 3 to further check the type of discarded protocol packets for switches running V200R003 and later versions.

Step 3 Use either of the following methods to check the type of discarded protocol packets.

Method 1: Run the display auto-port-defend statistics [ slot slot-id ] command in the diagnostic view to check whether protocol packets of a specified type are discarded. Table 1-2 lists the possibly discarded protocol packets.

[HUAWEI-diagnose] display auto-port-defend statistics
Statistics on MPU:
--------------------------------------------------------------------------------
Protocol     Vlan Queue Cir(Kbps) Pass(Packet/Byte) Drop(Packet/Byte)
--------------------------------------------------------------------------------
arp-request NA   2     256        0                  0
                                   NA                 NA
arp-reply    NA   2     256        0                  0
                                   NA                 NA
dhcp         NA   2     1024       0                  0
                                   NA                 NA
igmp         NA   2     768        0                  0
                                   NA                 NA
icmp         NA   2     256        23095              3
                                   NA                 NA
--------------------------------------------------------------------------------

Table 1-2 Possibly discarded protocol packets and attack types

Protocol	Attack Type
arp-reply, arp-request	1.3.1 ARP Attack, 1.3.8 TC Attack
arp-miss	1.3.2 ARP Miss Attack
dhcp-client, dhcp-server, dhcpv6-reply, dhcpv6-request	1.3.3 DHCP Attack
icmp	1.3.4 ICMP Attack
ttl-expired	1.3.5 TTL Attack
tcp	1.3.6 TCP Attack
ospf	1.3.7 OSPF Attack
ssh, telnet	1.3.9 SSH/Telnet Attack
vrrp	1.3.10 VRRP Attack
igmp	1.3.11 IGMP Attack
pim	1.3.12 PIM Attack

Method 2: Check logs for a port attack. In the log, AttackProtocol indicates the protocol type of attack packets.

SECE/4/PORT_ATTACK_OCCUR:Auto port-defend started.(SourceAttackInterface=[STRING], AttackProtocol=[STRING])

SECE/6/PORT_ATTACK_END:Auto port-defend stop.(SourceAttackInterface=[STRING], AttackProtocol=[STRING])

----End

1.3 Defense Measures for Different Types of Attacks

1.3.1 ARP Attack

1.3.1.1 ARP Flood

Attack Overview

In the following figure, LAN users access the Internet by connecting to the gateway through SwitchA and SwitchB. If a large number of ARP packets are forwarded on the network, the CPU of the gateway is overloaded and cannot process other services. If the ARP packets consume a lot of bandwidth, network congestion may occur, affecting network communication.

Symptom

l The CPU usage of a network device is high. User devices cannot learn ARP entries and cannot access the network.

l A ping fails.

l Network devices cannot be managed.

Troubleshooting Roadmap

Fault Location Method	Command	Models and Versions
View temporary ARP entries.	display arp	V100R006C05 and later versions
View statistics on ARP Request packets.	display cpu-defend statistics packet-type arp-request all	V100R006C05 and later versions
View the attack source tracing result.	display auto-defend attack-source [ slot slot-id ]	V200R003 and later versions

Step 1 Run the display arp command to check whether the affected users learn ARP entries properly.

If the value of MAC ADDRESS is displayed as Incomplete, the users do not learn ARP entries. This may be caused by an ARP attack. Go to the next step.

<HUAWEI> display arp
IP ADDRESS     MAC ADDRESS     EXPIRE(M) TYPE        INTERFACE   VPN-INSTANCE
VLAN/CEVLAN
------------------------------------------------------------------------------------------------------
10.137.222.139 00e0-fc01-4422            I -         Eth0/0/0

50.1.1.3        Incomplete      1         D-0         GE5/0/0
500/-
50.1.1.2        Incomplete      1         D-0         GE5/0/0
500/-
6.1.1.2         00e0-fc01-4422            I -         Vlanif6
10.0.0.139      00e0-fc01-4422            I -         Vlanif10

Step 2 Run the display cpu-defend statistics packet-type arp-request all command to view statistics on ARP Request packets sent to the CPU. The following command output shows that a large number of ARP Request packets are discarded on the card in slot 4.

<HUAWEI> display cpu-defend statistics packet-type arp-request all
Statistics on mainboard:
------------------------------------------------------------------------------------------------------------------
Packet Type          Pass(Packet/Byte)   Drop(Packet/Byte) Last-dropping-time
------------------------------------------------------------------------------------------------------------------
arp-request                    18265                    0
                             4164330                    0
------------------------------------------------------------------------------------------------------------------
Statistics on slot 4:
------------------------------------------------------------------------------------------------------------------
Packet Type          Pass(Packet/Byte)   Drop(Packet/Byte) Last-dropping-time
------------------------------------------------------------------------------------------------------------------
arp-request                       2132               3748 2017-06-06 06:57
                                272896             479744
------------------------------------------------------------------------------------------------------------------

This command can be executed multiple times, for example, at an interval of 1 second. If the Drop(Packets) counter increases fast, for example, an increment of 100 per second, the switch is undergoing an ARP attack. When the rate of ARP packets exceeds the CPCAR settings on the switch, the attack packets may occupy resources of valid ARP packets. As a result, the switch fails to learn some ARP entries.

Step 3 Identify the attack source by the attack source tracing function.

Create an attack defense policy policy1in the system view.

[HUAWEI] cpu-defend policy policy1
[HUAWEI-cpu-defend-policy-policy1] auto-defend enable
[HUAWEI-cpu-defend-policy-policy1] auto-defend attack-packet sample 5
[HUAWEI-cpu-defend-policy-policy1] auto-defend threshold 30
[HUAWEI-cpu-defend-policy-policy1] undo auto-defend trace-type source-portvlan //After the auto-defend enable command is configured, the device traces attack sources based on the source IP address, source MAC address, and source interface plus VLAN by default. Because the source interface plus VLAN is not precise enough, disable attack source tracing based on the source interface plug VLAN.
[HUAWEI-cpu-defend-policy-policy1] undo auto-defend protocol dhcp icmp igmp tcp telnet ttl-expired udp //After the auto-defend enable command is configured, the device traces attack sources for many protocols by default. Here, the device is configured to trace sources of only ARP packets in attack source tracing. If attack source tracing is required for other protocols, do not specify the protocols in the undo auto-defend protocol command.

Apply the attack defense policy policy1. For details, see 3.1 Applying the Attack Defense Policy.

Run the display auto-defend attack-source slot 4 command to view the MAC address of the attack source.

<HUAWEI> display auto-defend attack-source slot 4
Attack Source User Table (slot 4):
------------------------------------------------------------------------------------------------
MacAddress       InterfaceName      Vlan:Outer/Inner      TOTAL
------------------------------------------------------------------------------------------------
0000-0000-0001   GigabitEthernet4/0/22         193           416

Attack Source IP Table (slot 4):
-------------------------------------
IPAddress        TOTAL Packets
-------------------------------------
198.19.1.2        245
50.1.1.2        125
-------------------------------------
Total: 2

The MAC address of the gateway or the connected network device should be excluded from the suspicious attack sources.

----End

Root Cause

1. A terminal is infected with viruses and sends a large number of ARP packets.

2. A loop occurs on the network attached to the gateway. As a result, a large number of ARP packets are sent.

Procedure

Step 1 Configure ARP entry limiting on interfaces.

The S series switches support ARP entry limiting on interfaces. If the number of ARP entries learnt by an interface exceeds the maximum value, the system stops learning new ARP entries, and does not delete the learned ARP entries. Instead, the system prompts you to delete the excess ARP entries.

The configuration commands are as follows:

<HUAWEI> system-view
[HUAWEI] interface gigabitethernet 1/0/1
[HUAWEI-GigabitEthernet1/0/1] arp-limit vlan 10 maximum 20

Step 2 Suppress the rate of ARP packets with a specified source IP address.

If the number of ARP packets with a specified source IP address received by a switch in a period exceeds the specified threshold, the switch does not process the excess ARP Request packets.

<HUAWEI> system-view
[HUAWEI] arp speed-limit source-ip 10.0.0.1 maximum 50

By default, the rate of ARP packets is limited to 5 pps through timestamp-based suppression. That is, five ARP packets are processed per second.

Step 3 Add the MAC address of the attack source to a blacklist to filter out ARP packets sent from the attack source.

[HUAWEI] acl 4444
[HUAWEI-acl-L2-4444] rule permit l2-protocol arp source-mac 0-0-1 vlan-id 3
[HUAWEI-acl-L2-4444] quit
[HUAWEI] cpu-defend policy policy1
[HUAWEI-cpu-defend-policy-policy1] blacklist 1 acl 4444
[HUAWEI-cpu-defend-policy-policy1] quit

Apply the attack defense policy policy1. For details, see 3.1 Applying the Attack Defense Policy.

Step 4 If the problem persists, for example, if a user connected to an access device sends the ARP packets with different source MAC or IP addresses, configure a rate limiting policy on the access device to prevent users connected to the access device from affecting the network.

[HUAWEI] acl 4445
[HUAWEI-acl-L2-4445] rule permit l2-protocol arp
[HUAWEI-acl-L2-4445] quit
[HUAWEI] traffic classifier policy1
[HUAWEI-classifier-policy1] if-match acl 4445
[HUAWEI-classifier-policy1] quit
[HUAWEI] traffic behavior policy1
[HUAWEI-behavior-policy1] car cir 32
[HUAWEI-behavior-policy1] quit
[HUAWEI] traffic policy policy1
[HUAWEI-trafficpolicy-policy1] classifier policy1 behavior policy1
[HUAWEI-trafficpolicy-policy1] quit
[HUAWEI] interface GigabitEthernet 1/0/1
[HUAWEI-GigabitEthernet1/0/1] traffic-policy policy1 inbound

----End

1.3.1.2 ARP Spoofing

Attack Overview

In Figure 1-2, LAN users access the Internet by connecting to the gateway through the switch.

Figure 1-2 Networking of ARP spoofing

After UserA, UserB, and UserC go online and exchange ARP packets, the users and gateway generate corresponding ARP entries. If an attacker initiates an attack by sending bogus ARP packets in the broadcast domain, the gateway or UserA, UserB, and UserC will modify their ARP entries. In this situation, the attacker can easily obtain information about UserA, UserB, and UserC or prevent them from accessing the Internet.

Symptom

LAN users are frequently disconnected from the network. Network devices are out of management, and the gateway prints a large number of address conflict alarms.

Troubleshooting Roadmap

Fault Location Method	Command	Models and Versions
View log information.	display logbuffer	V100R006C05 and later versions

l When the ARP packets sent by a bogus gateway pass the switch that functions as a gateway, the packets are sent to the CPU of the switch. The switch can detect the gateway collision and record a log.

Run the display logbuffer command to view log information. The log is as follows. MacAddress indicates the MAC address of the attacker.

ARP/4/ARP_DUPLICATE_IPADDR:Received an ARP packet with a duplicate IP address from the interface. (IpAddress=[IPADDR], InterfaceName=[STRING], MacAddress=[STRING])

Search the MAC address table according to the recorded attacker's MAC address for the port connected to the attacker. Check the network to find out the attack source and whether a terminal is infected by a virus.

l If the ARP packets sent by a bogus gateway do not pass the switch that functions as a gateway, but are directly forwarded to user devices, check the downstream network. For example, use a packet parser (such as Wireshark) to parse ARP Reply packets sent by the gateway. If the parsed MAC address is not the gateway's, a terminal is attacked and this parsed MAC address is the attacker's MAC address. If the parsed MAC address is the gateway's but the parsed IP address is not the gateway's, the attacker simulates the gateway's MAC address to initiate an attack. In this case, MAC address flapping occurs on the access switch. Therefore, locate the attack source based on the interface on which MAC address flapping occurs.

Root Cause

1. A terminal is affected by a virus.

2. The attacker sets the host address to the gateway's address.

Procedure

Method	Advantage	Disadvantage
Configure a blacklist.	Packets sent to the CPU are discarded based on the blacklist.	The attack source needs to be found first.
Configure a blackhole MAC address.	All packets sent from the attack source, including those forwarded by the attack source, are discarded.	The attack source needs to be found first.
Configure ARP gateway anti-conflict.	Packets with the same source MAC address are directly discarded.	The local device functions as a gateway.

l Method 1: Configure a blacklist to filter packets with the attacker's MAC address (this operation must have the customer's permission).

[HUAWEI] acl 4444
[HUAWEI-acl-L2-4444] rule permit l2-protocol arp source-mac 1-1-1
[HUAWEI-acl-L2-4444] quit
[HUAWEI] cpu-defend policy policy1
[HUAWEI-cpu-defend-policy-policy1] blacklist 1 acl 4444

Apply the attack defense policy policy1. For details, see 3.1 Applying the Attack Defense Policy.

l Method 2: Add the attacker's MAC address to a blackhole MAC address entry to prevent the attacker from going online.

[HUAWEI] mac-address blackhole 1-1-1 vlan 3

l Configure the gateway anti-collision function on the switch that functions as a gateway. After this function is configured, the switch generates an ARP attack defense entry to discard the packets with the same source MAC address, preventing the ARP packets sent by the bogus gateway from being broadcast in the VLAN.

[HUAWEI] arp anti-attack gateway-duplicate enable

1.3.2 ARP Miss Attack

1.3.2.1 Network Scanning Attack

Attack Overview

When a switch forwards a Layer 3 packet, if the destination address of the packet is directly connected to the switch and no ARP entry matching the destination address exists on the switch, an ARP Miss packet is triggered. The switch sends an ARP Request packet to the destination address of the Layer 3 packet. After the ARP entry is learned, the switch directly forwards the Layer 3 packet to the correct destination address.

Network segment scanning triggers generation of a large number of ARP Miss packets. As a result, the system is busy processing ARP Miss packets and cannot process other services, suffering a scanning attack.

Symptom

When a switch suffers an ARP Miss attack, the CPU usage of the switch is high and a large number of temporary ARP entries are generated on the switch. ARP Miss packets are discarded by CPCAR, there is a delay in response to the ping operation, or the ping fails. Some user devices are disconnected, user's network access speed is slow, or the switch is out of management.

Troubleshooting Roadmap

Fault Location Method	Command	Models and Versions
View statistics on packets sent to the CPU.	display cpu-defend statistics packet-type arp-miss { all \| slot slot-id }	V100R006C05 and later versions
View temporary ARP entries.	display arp	V100R006C05 and later versions

1. Clear statistics on the ARP Miss packets sent to the CPU.

<HUAWEI> reset cpu-defend statistics packet-type arp-miss all

2. Wait for one minute and view statistics on the ARP Miss packets sent to the CPU again.

<HUAWEI> display cpu-defend statistics packet-type arp-miss slot 2
Statistics on slot 2:
------------------------------------------------------------------------------------------------------------------
Packet Type Pass(Packet/Byte) Drop(Packet/Byte) Last-dropping-time
------------------------------------------------------------------------------------------------------------------
arp-miss 40800 357680 2017-06-06 06:57
------------------------------------------------------------------------------------------------------------------

View the number of passing and discarded packets. If the number of discarded packets is greater than the number of passing packets, an ARP Miss attack may occur.

3. Check whether a large number of temporary ARP entries are generated on the switch. If the value of MAC ADDRESS is Incompletein 15 or more temporary entries, an ARP Miss attack occurs.

<HUAWEI> display arp all
IP ADDRESS      MAC ADDRESS     EXPIRE(M) TYPE        INTERFACE   VPN-INSTANCE
                                          VLAN/CEVLAN
------------------------------------------------------------------------------
10.137.217.202 00e0-0987-7890            I -         Eth0/0/0
10.137.216.1    0000-5e00-0149 20        D-0         Eth0/0/0
10.1.1.2        00e0-0987-7899            I -         GE6/1/1
10.1.20.1       00e0-0987-789a            I -         GE6/1/2
10.1.10.6       00e0-0987-789b            I -         GE6/1/3
10.1.11.6       00e0-0987-789c            I -         GE6/1/4
192.168.11.1    00e0-0987-789c            I -         Vlanif11
192.168.11.254 Incomplete      12        D-0         Eth-Trunk1
                                            11/-
192.168.11.253 Incomplete      16        D-0         Eth-Trunk1
                                            11/-
------------------------------------------------------------------------------
Total:9         Dynamic:3       Static:0     Interface:6

Root Cause

A switch receives a large number of ARP Miss packets commonly for the following reasons:

1. A network scanning attack occurs. You can obtain packets or run the display arp anti-attack arpmiss-record-info command to view the attack source.

2. The switch receives TC packets and then ages out ARP entries, causing a large number of ARP Miss messages. For details about the measures for defending against an ARP Miss attack caused by TC messages, see 1.3.8 TC Attack.

Procedure

Method	Advantage	Disadvantage
Decrease the CPCAR value for ARP Miss packets.	The number of packets sent to the CPU is decreased quickly.	Normal ARP Miss packets may be discarded.
Set the aging time o fake ARP entries.	Packets sent to a specified destination address are suppressed, and no ARP Miss packet is triggered during the aging time.	A proper aging time must be set.
Configure ARP Miss suppression.	Packets sent from a specified source address are suppressed, and no ARP Miss packet is sent to the CPU during the block time.	A whitelist needs to be configured to prevent the network-side device from being punished.
Configure a blacklist to discard packets sent from a specified attack source.	The blacklist can be applied on the switch or a specified card to drop attack packets.	1. The blacklisted source cannot access the switch after the attack is eliminated.

l Decrease the CPCAR value for ARP Miss packets to resolve the high CPU usage problem.

<HUAWEI> system-view
[HUAWEI] cpu-defend policy policy1
[HUAWEI-cpu-defend-policy-policy1] car packet-type arp-miss cir 64
[HUAWEI-cpu-defend-policy-policy1] quit
[HUAWEI] cpu-defend-policy policy1 global

This method cannot resolve the problem that users' network access speed is slow.

l Increase the aging time of fake ARP entries to resolve the high CPU usage problem. When an IP packet triggers the generation of an ARP Miss packet, the switch sends an ARP Request packet and generates a temporary ARP entry. The switch then directly discards the data packets destined for this IP address to protect the CPU. When the switch receives an ARP Reply packet, it modifies the temporary ARP entry. If the switch does not receive an ARP Reply packet within the specified period, it deletes the temporary entry. The later packets from this IP address can still trigger the generation of ARP Miss packets.

<HUAWEI> system-view
[HUAWEI] interface Vlanif 500
[HUAWEI-Vlanif500] arp-fake expire-time 30 //The default aging time of fake ARP entries is 30 seconds.

A long fake entry aging time will cause a delay in ARP entry learning and loss of data packets.

l Configure source IP address-based ARP Miss rate limiting. The switch will automatically identify the source IP address from which the packet rate exceeds the limit and deliver an ACL. By default, the ARP Miss suppression limit for all source IP addresses is 30 pps, and the punishment time is 5 seconds. It is recommended to allow packets from the network-side device to pass, preventing it from being punished.

<HUAWEI> system-view
[HUAWEI] arp-miss speed-limit source-ip maximum 10 //The ARP Miss rate limit for each source IP address is set to 10 pps. The default limit is 30 pps.
[HUAWEI] arp-miss speed-limit source-ip 1.1.1.1 maximum 200 //Allow packets from the network-side device to pass, preventing it from being punished.

Run the display arp anti-attack arpmiss-record-info command to view the attack source.

[HUAWEI] display arp anti-attack arpmiss-record-info
Interface IP address Attack time Block time Aging-time
----------------------------------------------------------------------------------------------------------------
GigabitEthernet5/0/0 10.0.0.1 2017-06-06 06:57 2017-06-06 06:57 50
----------------------------------------------------------------------------------------------------------------
There are 1 records in Arp-miss table

The switch will automatically deliver an ACL to match the ARP Miss packets from the specified source IP address. If these packets do not need to be sent to the control plane, run the cpu-defend policy command with a blacklist configured to block the attack source.

1.3.3 DHCP Attack

1.3.3.1 Bogus DHCP Server Attack

Attack Overview

Due to the lack of an authentication mechanism between DHCP servers and clients, a DHCP server newly configured on a network can allocate IP addresses and other network parameters to DHCP clients. If the allocated IP addresses and network parameters are incorrect, network services may be interrupted.

In Figure 1-3, authorized and unauthorized DHCP servers can receive DHCP Discover packets broadcast by DHCP clients.

Figure 1-3 DHCP client sending DHCP Discover packets

If a bogus DHCP server sends a fake response packet including an incorrect gateway address, domain name system (DNS) server, and IP address to a DHCP client, as shown in Figure 1-4, the DHCP client cannot obtain the correct IP address and required information. Authorized users then fail to access the network and user information security is affected.

Figure 1-4 Bogus DHCP server attack

Symptom

DHCP clients cannot obtain correct IP addresses and thereby cannot access the network.

Troubleshooting Roadmap

Defense against bogus DHCP server attacks is typically configured during service deployment, instead of in the case of those attacks. If such a bogus DHCP server attack occurs, you can check DHCP information on the clients to locate the cause.

Root Cause

A DHCP client broadcasts DHCP Request packets to DHCP servers to obtain an IP address. As shown in Figure 1-4, a bogus DHCP server intercepts the DHCP Request packet sent from the client and allocates an IP address to the client.

Procedure

Method	Advantage	Disadvantage
Configure DHCP snooping.	It is easy to configure and commonly used.	Packets are sent to the CPU, which may result in high CPU usage.
Configure a traffic policy.	Packets are not sent to the CPU.	The configuration is complex and ACL resources are required.

Method 1: Configure DHCP snooping to control the exchange of DHCP Request and Response packets. This function prevents bogus DHCP servers from allocating IP addresses and other configurations to DHCP clients.

l Configure DHCP snooping globally.

<HUAWEI> system-view
[HUAWEI] dhcp enable
[HUAWEI] dhcp snooping enable

l Configure DHCP snooping on the user-side interface. You can configure DHCP snooping on an interface or in a VLAN based on the site requirements.

[HUAWEI] interface GigabitEthernet 8/0/1
[HUAWEI-GigabitEthernet8/0/1] dhcp snooping enable

l Configure the interface connected to the DHCP server as a trusted interface.

[HUAWEI] interface GigabitEthernet 8/0/10
[HUAWEI-GigabitEthernet8/0/10] dhcp snooping trusted

Method 2: DHCP snooping prevents bogus DHCP server attacks by controlling the forwarding of DHCP packets. You can also configure traffic policies to achieve the same purpose. Forward DHCP Request packets only to trusted interfaces, and allow only the trusted interfaces to receive and forward DHCP Response packets.

1. Configure an ACL to match DHCP Response packets.

[HUAWEI] acl 3001
[HUAWEI-acl-adv-3001] rule permit udp destination-port eq bootpc

Configure two traffic policies. One is for discarding DHCP Response packets and applied to a VLAN. The other is for allowing DHCP Response packets to be forwarded and applied to the interface that connects to the DHCP server. The traffic policy applied to the interface has a higher priority than that applied to the VLAN, so that the interface can receive and forward DHCP Response packets sent from the DHCP server.

[HUAWEI] traffic classifier bootpc_dest
[HUAWEI-classifier-bootpc_dest] if-match acl 3001
[HUAWEI-classifier-bootpc_dest] quit
[HUAWEI] traffic behavior deny
[HUAWEI-behavior-deny] deny
[HUAWEI-behavior-deny] quit
[HUAWEI] traffic behavior permit
[HUAWEI-behavior-permit] permit
[HUAWEI-behavior-permit] quit
[HUAWEI] traffic policy bootpc_dest_permit
[HUAWEI-trafficpolicy-bootpc_dest_permit] classifier bootpc_dest behavior permit   //Configure a traffic policy to allow DHCP Response packets to be forwarded.
[HUAWEI-trafficpolicy-bootpc_dest_permit] quit
[HUAWEI] traffic policy bootpc_dest_deny
[HUAWEI-trafficpolicy-bootpc_dest_deny] classifier bootpc_dest behavior deny       //Configure a traffic policy to discard DHCP Response packets.
[HUAWEI-trafficpolicy-bootpc_dest_deny] quit
[HUAWEI] interface GigabitEthernet 8/0/10
[HUAWEI-GigabitEthernet8/0/10] traffic-policy bootpc_dest_permit inbound //Apply the traffic policy with the permit behavior to the trusted interface.
[HUAWEI-GigabitEthernet8/0/10] quit
[HUAWEI] vlan 172
[HUAWEI-vlan172] traffic-policy bootpc_dest_deny inbound   //Apply the traffic policy with the deny behavior to the VLAN.
[HUAWEI-vlan172] quit

2. The following configurations are optional.

Configure an ACL to match DHCP Request packets.

[HUAWEI] acl 3000
[HUAWEI-acl-adv-3000] rule permit udp source-port eq bootpc

Configure two traffic policies. One is for discarding DHCP Request packets and applied to a VLAN. The other is for allowing DHCP Request packets to be forwarded and applied to the interface that connects to the DHCP server. The traffic policy applied to the interface has a higher priority than that applied to the VLAN, so that DHCP Request packets can only be sent to the DHCP server.

[HUAWEI] traffic classifier bootpc_src
[HUAWEI-classifier-bootpc_src] if-match acl 3000
[HUAWEI-classifier-bootpc_src] quit
[HUAWEI] traffic behavior deny
[HUAWEI-behavior-deny] deny
[HUAWEI-behavior-deny] quit
[HUAWEI] traffic behavior permit
[HUAWEI-behavior-permit] permit
[HUAWEI-behavior-permit] quit
[HUAWEI] traffic policy bootpc_src_permit
[HUAWEI-trafficpolicy-bootpc_src_permit] classifier bootpc_src behavior permit   //Configure a traffic policy to allow DHCP Request packets to be forwarded.
[HUAWEI-trafficpolicy-bootpc_src_permit] quit
[HUAWEI] traffic policy bootpc_src_deny
[HUAWEI-trafficpolicy-bootpc_src_deny] classifier bootpc_src behavior deny    //Configure a traffic policy to discard DHCP Request packets.
[HUAWEI-trafficpolicy-bootpc_src_deny] quit
[HUAWEI] interface GigabitEthernet 8/0/10
[HUAWEI-GigabitEthernet8/0/10] traffic-policy bootpc_src_permit outbound     //Apply the traffic policy with the permit behavior to the trusted interface in the outbound direction.
[HUAWEI-GigabitEthernet8/0/10] quit
[HUAWEI] vlan 172
[HUAWEI-vlan172] traffic-policy bootpc_src_deny outbound   //Apply the traffic policy with the deny behavior to the VLAN in the outbound direction.
[HUAWEI-vlan172] quit

1.3.3.2 DHCP Flooding Attack

Attack Overview

A flooding attack is also called a Denial of Service (DoS) attack. It aims to occupy resources of a device by sending numerous connection requests. As a result, the device cannot provide functions properly or even crash. DoS attacks target a server, making the server deny requests of authorized users.

Symptom

When the DHCP snooping, DHCP relay, or DHCP server service is deployed on a switch, the CPU usage of the switch is high and users' network access speed is slow.

Troubleshooting Roadmap

Fault Location Method	Command	Models and Versions
View the CPU usage.	display cpu-usage [ slave \| slot slot-id ]	V100R006C05 and later versions
View statistics on packets sent to the CPU.	display cpu-defend statistics [ packet-type packet-type ] { all \| slot slot-id \| mcu }	V100R006C05 and later versions
View port attack defense statistics.	display auto-port-defend statistics [ slot slot-id ]	V200R003 and later versions
Configure attack source tracing.	auto-defend enable	V100R006C05 and later versions
View information about attack source tracing.	display auto-defend attack-source detail	V100R006C05 and later versions
View DHCP packet statistics.	display dhcp statistics	V100R006C05 and later versions
View packet statistics on a DHCP relay agent.	display dhcp relay statistics	V100R006C05 and later versions
View statistics on a DHCP server.	display dhcp server statistics	V100R006C05 and later versions
View the rate limit of DHCP packets.	display dhcp packet process statistics	V100R006C05 and later versions

1. Run the display cpu-usage command to view the task running status to find out the task with high CPU occupation. If a switch receives DoS attack packets, the CPU occupation of the bcmRX, FTS, or SOCK task may be high.

<HUAWEI> display cpu-usage
CPU Usage Stat. Cycle: 10 (Second)
CPU Usage         : 68% Max: 99%
CPU Usage Stat. Time : 2016-12-18 15:35:56
CPU utilization for five seconds: 68%: one minute: 60%: five minutes: 55%.

TaskName        CPU Runtime(CPU Tick High/Tick Low) Task Explanation
BOX              0%         0/   11ad0                BOX Output
_TIL              0%         0/       0                Infinite loop event task
_EXC             0%         0/       0                Exception Agent Task
VIDL             60%         0/e7615b10                DOPRA IDLE
TICK             0%         0/   d4afc
bcmRX            20%         0/ 17a14c                bcmRX
FTS               20%         0/   ff707                FTS
SOCK             20%         0/ 26ac89               SOCKPacket schedule and process

2. Run the display cpu-defend statisticscommand to view statistics on the packets received by the CPU. Check whether many DHCP protocol packets are discarded based on CPCAR values of the dhcp-server,dhcp-client, dhcpv6-request, and dhcpv6-reply packet types.

<HUAWEI> display cpu-defend statistics slot 2
Statistics on slot 2:
-----------------------------------------------------------------------------------------------------------
Packet Type          Pass(Packet/Byte)   Drop(Packet/Byte) Last-dropping-time
-----------------------------------------------------------------------------------------------------------
...
dhcp-client                          0                   0 -
                                      0                   0
dhcp-server                         0                   0 -
                                      0                   0
dhcpv6-reply                         0                   0 -
                                      0                   0
dhcpv6-request                       0                   0 -
...
-----------------------------------------------------------------------------------------------------------

3. View packet statistics on port attack defense to check whether DHCP protocol packets are lost. V200R003 and later versions support port attack defense.

[HUAWEI-diagnose] display auto-port-defend statistics
Statistics on MPU:
--------------------------------------------------------------------------------
Protocol     Vlan Queue Cir(Kbps) Pass(Packet/Byte) Drop(Packet/Byte)
--------------------------------------------------------------------------------
arp-request NA   2     256        0                  0
                                   NA                 NA
arp-reply    NA   2     256        0                  0
                                   NA                 NA
dhcp         NA   2     1024       0                  0
                                   NA                 NA
igmp         NA   2     768        0                  0
                                   NA                 NA
--------------------------------------------------------------------------------

Check whether many packets of a protocol are received according to statistics on the tasks and CPU.

Check the networking to determine whether the protocol packets are valid. If not, these packets may be attack packets.

4. The source IP or MAC addresses of many DoS attack sources are fixed. Deploy attack source tracing (enabled by default in V200R009 and later versions) to check whether an attack is initiated.

Apply the attack defense policy policy1. For details, see 3.1 Applying the Attack Defense Policy.

Wait for 1 minute and check whether an attack source is detected.

<HUAWEI> display auto-defend attack-source detail
Attack Source User Table (MPU):
----------------------------------------------------
MAC Address 0000-c123-0102
Interface GigabitEthernet1/0/1
VLAN: Outer/Inner 1000
DHCP: 416
Total 416
----------------------------------------------------

5. Based on the DHCP function enabled on the switch, run the display dhcp packet process statistics command to check whether the number of corresponding packets increases rapidly.

[HUAWEI-diagnose] display dhcp packet process statistics
Packet process rate:
DHCPv4 :80
DHCPv6 :0
ND     :0

Root Cause

A DoS attack of DHCP packets is mainly caused by the following reasons:

1. A user terminal is infected with a virus.

2. A network loop occurs.

Procedure

Method	Advantage	Disadvantage
Configure attack source tracing.	A specific user is punished.	ACL resources are consumed.
Configure software-based rate limiting.	Rate limiting can be configured globally, in a VLAN, or on an interface.	The CPU usage cannot be efficiently reduced.

l Method 1: Configure attack source tracing to punish the attacker.

Apply the attack defense policy policy1. For details, see 3.1 Applying the Attack Defense Policy.

l Method 2: Configure rate limiting for DHCP packets. Configure the function of checking the rate of sending DHCP packets to the processing unit in the system view, VLAN view, or interface view. The following uses the configuration in the VLAN view as an example:

[HUAWEI] vlan 10
[HUAWEI-vlan10] dhcp snooping check dhcp-rate enable
[HUAWEI-vlan10] dhcp snooping check dhcp-rate 80
[HUAWEI-vlan10] quit

1.3.3.3 DHCP Server DoS Attack

Attack Overview

In Figure 1-5, if many attackers request IP addresses on GE1/0/1, IP addresses in the IP address pool of the DHCP server are exhausted, and there are no IP addresses for authorized users.

A DHCP server identifies the MAC addresses of clients based on the client hardware address (CHADDR) field in DHCP Request packets. If an attacker continuously applies for IP addresses by changing the CHADDR field, IP addresses in the address pool on the DHCP server may be exhausted. As a result, authorized users cannot obtain IP addresses.

Figure 1-5 DHCP server DoS attack

Symptom

The IP address pool on the DHCP server is exhausted and users cannot obtain IP addresses.

Troubleshooting Roadmap

Fault Location Method	Command	Models and Versions
Check address pool usage information.	display ip pool	V100R006C05 and later versions
View DHCP snooping binding entries.	display dhcp snooping user-bind all	V100R006C05 and later versions

1. Run the display ip pool command to view address pool usage information on the DHCP server. Check whether MAC addresses in the address pool change gradually. If so, a DHCP server DoS attack may occur because valid users are unlikely to have MAC addresses that change gradually.

<HUAWEI> display ip pool interface vlanif2050 used
Pool-name        : Vlanif2050                          Pool-No          : 1
Lease            : 1 Days 0 Hours 0 Minutes
Domain-name      : -
DNS-server0      : -
NBNS-server0     : -
Netbios-type     : -
Position         : Interface       Status             : Unlocked
Gateway-0        : -
Network          : 25.25.25.0
Mask             : 255.255.255.0
VPN instance     : --
Logging          : Disable
Conflicted address recycle interval: -
Address Statistic: Total       :254       Used        :5
                     Idle        :249       Expired     :0
                     Conflict    :0         Disabled    :0
-------------------------------------------------------------------------------
Network section
         Start           End       Total    Used Idle(Expired) Conflict Disabled
-------------------------------------------------------------------------------
      25.25.25.1    25.25.25.254     254       5        249(0)       0     0
-------------------------------------------------------------------------------
Client-ID format as follows:
   DHCP : mac-address                 PPPoE   : mac-address
   IPSec : user-id/portnumber/vrf      PPP     : interface index
   L2TP : cpu-slot/session-id         SSL-VPN : user-id/session-id
-------------------------------------------------------------------------------
Index              IP             Client-ID    Type       Left   Status
-------------------------------------------------------------------------------
    117    25.25.25.2       0-0-1    DHCP      86397   Used
    118    25.25.25.3       0-0-2    DHCP      86397   Used
    119    25.25.25.4       0-0-3    DHCP      86397   Used
    120    25.25.25.5       0-0-4    DHCP      86397   Used
    121    25.25.25.6       0-0-5    DHCP      86397   Used
-------------------------------------------------------------------------------

2. If DHCP snooping is configured on the access device, check whether there are many users in a VLAN or on an interface and whether these users' MAC addresses change gradually.

<HUAWEI> display dhcp snooping user-bind all
DHCP Dynamic Bind-table:
Flags:O - outer vlan ,I - inner vlan ,P - map vlan
IP Address       MAC Address     VSI/VLAN(O/I/P) Interface      Lease
--------------------------------------------------------------------------------
16.1.28.1      0-0-1 10 /-- /--   Eth0/0/1       2016.10.17-07:31
16.1.28.2      0-0-2 10 /-- /--    Eth0/0/1       2016.10.17-07:31
16.1.28.3      0-0-3 10 /-- /--    Eth0/0/1       2016.10.17-07:31
16.1.28.4      0-0-4 10 /-- /--    Eth0/0/1       2016.10.17-07:31
--------------------------------------------------------------------------------
print count:      1     total count:      1

Root Cause

A user terminal is infected with a virus.

Procedure

To prevent malicious use of IP addresses, limit the number of DHCP snooping binding entries that can be learned by an interface so as to control the number of online users. When the number of online users reaches the specified limit, no user can obtain IP addresses through this interface. To prevent attackers from applying for IP addresses by sending DHCP Request packets with variable CHADDR values, configure the switch to check whether the CHADDR field matches the source MAC address in the header of a DHCP Request packet. If they are the same, the switch forwards the DHCP Request packet. If they are different, the switch discards the DHCP Request packet.

Method	Advantage	Disadvantage
Limit the number of online users.	The limit can be configured globally, in a VLAN, or on an interface.	Packets are sent to the CPU.
Enable packet validity check.	Packet validity check can be configured globally, in a VLAN, or on an interface.	Packets are sent to the CPU. This method depends on correctness of binding entries established for the first time.

l Set the maximum number of DHCP snooping binding entries that can be learned by the DHCP server in the interface, VLAN, or system view.

[HUAWEI] dhcp enable
[HUAWEI] dhcp snooping enable //Enable DHCP snooping globally.
[HUAWEI] interface GigabitEthernet 8/0/1
[HUAWEI-GigabitEthernet8/0/1] dhcp snooping enable
[HUAWEI-GigabitEthernet8/0/1] dhcp snooping max-user-number 10 //Limit the number of DHCP users on the interface.

l Enable the CHADDR field check and alarm functions in the interface, VLAN, or system view.

[HUAWEI] dhcp enable
[HUAWEI] dhcp snooping enable //Enable DHCP snooping globally.
[HUAWEI] interface GigabitEthernet 8/0/1
[HUAWEI-GigabitEthernet8/0/1] dhcp snooping check dhcp-chaddr enable
[HUAWEI-GigabitEthernet8/0/1] dhcp snooping alarm dhcp-chaddr enable
[HUAWEI-GigabitEthernet8/0/1] dhcp snooping check dhcp-request enable
[HUAWEI-GigabitEthernet8/0/1] dhcp snooping alarm dhcp-request enable

1.3.3.4 DHCP Packets Incorrectly Sent to the CPU

Attack Overview

After the DHCP function is enabled, DHCP packets are sent to the CPU by a specified interface or all interfaces. Therefore, some unnecessary DHCP packets are sent to the CPU, resulting in high CPU usage or affecting the DHCP service.

Symptom

When DHCP packets are incorrectly sent to the CPU, the following problems occur:

1. The CPU usage is high.

2. The bandwidth or resources for processing normal DHCP packets are occupied, and users cannot go online or offline properly.

Troubleshooting Roadmap

1. Configure an ACL to match DHCP packets.

[HUAWEI] acl 3000
[HUAWEI-acl-adv-3000] rule permit udp destination-port eq bootpc

2. Run the capture-packet cpu command to capture the packets sent to the CPU. If DHCP packets are captured and the VLAN to which these packets belong does not have the DHCP service enabled, the DHCP packets are incorrectly sent to the CPU.

[HUAWEI] capture-packet cpu acl 3000 destination terminal packet-num 10

Root Cause

DHCP packets are sent to the CPU by a specified interface or all interfaces. Therefore, some unnecessary DHCP packets in certain VLANs are sent to the CPU.

Procedure

Method	Advantage	Disadvantage
Configure intra-VLAN transparent transmission of protocol packets.	Protocol packets that do not need to be sent to the CPU can be transmitted transparently by VLAN.	1. Only HI series fixed and modular switches support this function. 2. The VLANs in which DHCP packets exist must be identified first. 3. If there are many VLANs having DHCP packets, the configuration is complex.
Configure a traffic policy, instead of DHCP snooping.	The CPU usage will be reduced.	The configuration is complex.

Method

Advantage

Disadvantage

Configure intra-VLAN transparent transmission of protocol packets.

Protocol packets that do not need to be sent to the CPU can be transmitted transparently by VLAN.

1. Only HI series fixed and modular switches support this function.

2. The VLANs in which DHCP packets exist must be identified first.

3. If there are many VLANs having DHCP packets, the configuration is complex.

Configure a traffic policy, instead of DHCP snooping.

The CPU usage will be reduced.

The configuration is complex.

l Method 1: Enable transparent transmission of protocol packets in the VLANs that do not process the protocol packets. In this way, protocol packets in these VLANs are transparently forwarded to other devices and will not be sent to the CPU, improving forwarding efficiency. Packets of the following protocols support transparent transmission: CFM, ARP, BFD, DHCPv4, DHCPv6, HTTP, IGMP, MLD, ND, PIM, PIMv6, PPPoE, and TACACS.

[HUAWEI] vlan 10
[HUAWEI-vlan10] protocol-transparent

l Method 2: If DHCP packets are incorrectly sent to the CPU due to the DHCP snooping function, disable DHCP snooping and configure a traffic policy. In this way, DHCP packets will not be incorrectly sent to the CPU and the CPU usage will be reduced. For details about how to configure a traffic policy, see 1.3.3.1 Bogus DHCP Server Attack.

1.3.3.5 DHCP Spoofing

Attack Overview

On a DHCP network, if attackers pretend authorized users to send DHCP Request packets to the DHCP server to renew IP addresses, the IP addresses cannot be reclaimed and other authorized users cannot obtain IP addresses.

Symptom

A user is disconnected unexpectedly.

Troubleshooting Roadmap

If a DHCP spoofing attack occurs, enable the function of checking DHCP packets against the DHCP snooping binding table and the DHCP snooping alarm function.

Root Cause

A user terminal is affected by a virus or attacked.

Procedure

Enable the function of checking DHCP packets against the DHCP snooping binding table and the DHCP snooping alarm function in the system, VLAN, or interface view. The following uses the configuration in the interface view as an example.

[HUAWEI] dhcp enable
[HUAWEI] dhcp snooping enable //Enable DHCP snooping globally.
[HUAWEI] interface GigabitEthernet 8/0/1
[HUAWEI-GigabitEthernet8/0/1] dhcp snooping enable
[HUAWEI-GigabitEthernet8/0/1] dhcp snooping check dhcp-request enable//Check DHCP packets on the interface.
[HUAWEI-GigabitEthernet8/0/1] dhcp snooping alarm dhcp-request enable

1.3.4 ICMP Attack

Attack Overview

Some switches are located at the core layer on the live network and function as gateways. A gateway responds to ICMP packets from authorized users. The processing capability of the CPU is limited, so the CPU can process a limited number of ICMP packets in a specified period. Attackers use software or control hosts to send a large number of ICMP packets to the gateway. If the attack lasts for a long period, the CPU usage of the gateway becomes high and the gateway discards excess ICMP packets. The gateway cannot identify which ICMP packets need to be discarded or processed. In this case, authorized users may fail to communicate with the gateway and get offline.

Symptom

1. When many ping tests are performed using tools for network scanning or other methods, a switch receives a large number of ICMP packets and forwards them to the CPU. As a result, the CPU usage is high and other service functions are affected.

2. A user-side device sends ICMP packets of a specified long length to perform ping tests. The rate of ICMP packets may exceed the CPCAR value set on the switch. As a result, packet loss occurs in the ping tests.

Troubleshooting Roadmap

Fault Location Method	Command	Models and Versions
View statistics on packets sent to the CPU.	display cpu-defend statistics packet-type icmp all	V100R006C05 and later versions
View the rate limit for ICMP packets.	display current-configuration \| include icmp	V100R006C05 and later versions
View ICMP flood attack information.	display anti-attack statistics	V100R006C05 and later versions

1. Run the display cpu-defend statistics packet-type icmp all command to check whether ICMP packets are lost because they exceed the CPCAR and whether the number of lost ICMP packets increases.

<HUAWEI> display cpu-defend statistics packet-type icmp all
Statistics on mainboard:
--------------------------------------------------------------------------------
Packet Type          Pass(Packet/Byte)  Drop(Packet/Byte) Last-dropping-time
--------------------------------------------------------------------------------
icmp                         371078               8620 2017-06-06 06:57
                                 NA                  NA
--------------------------------------------------------------------------------
Statistics on slot 1:
--------------------------------------------------------------------------------
Packet Type          Pass(Packet/Byte)   Drop(Packet/Byte) Last-dropping-time
--------------------------------------------------------------------------------
icmp                        371078               8620 2017-06-06 06:57
                         178623204             4266203

2. Check whether rate limiting is configured for ICMP packets on the switch. If the icmp rate-limit enable configuration exists, ICMP packets may be lost.

<HUAWEI> display current-configuration | include icmp
icmp rate-limit enable

3. Check whether packets are lost due to an ICMP flood packet.

<HUAWEI> display anti-attack statistics
Packets Statistic Information:
-------------------------------------------------------------------------------
AntiAtkType TotalPacketNum       DropPacketNum        PassPacketNum
           (H)        (L)        (H)        (L)        (H)        (L)
-------------------------------------------------------------------------------
URPF          0          0          0          0          0          0
Abnormal      0          0          0          0          0          0
Fragment      0          0          0          0          0          0
Tcp-syn       0          0          0          0          0          0
Udp-flood     0          0          0          0          0          0
Icmp-flood    0       5783          0       1347          0        4436
-------------------------------------------------------------------------------

Root Cause

1. A large number of ICMP packets are sent to the CPU due to an ICMP attack, resulting in high CPU usage.

2. Ping packets are lost due to the ICMP anti-attack or CPCAR configuration.

Procedure

Symptom	Method	Advantage	Disadvantage
The CPU usage of the switch is high.	Configure a blacklist to filter ICMP packets.	Authorized users are not affected.	The attack source needs to be identified first.
Ping packets are lost.	Adjust the CPCAR value for ICMP packets.	Ping tests of more users or with super large packets can be performed.	A large number of packets are sent to the CPU, resulting in high CPU usage.

l When the CPU usage is high, configure a blacklist to filter ICMP packets.

a. Identify the attack source.

In V100R006C05, use the mirroring function to obtain packets and then use a packet parser such as Wireshark to parse the obtained packets. In versions later than V100R006C05, run the capture-packet cpu command to obtain the ping packets sent to the CPU.

For example, when the capture-packet cpu command is used to obtain the ping packets sent to the CPU, the source and destination IP addresses of these packets are 172.22.189.62 and 172.22.189.61, respectively.

In the following command output, ac 16 bd 3e indicates the source IP address, which can be converted into 172.22.189.62 in dotted decimal notation. ac 16 bd 3d indicates the destination IP address, which can be converted into 172.22.189.61 in dotted decimal notation.

[HUAWEI] acl 3333
[HUAWEI-acl-adv-3333] rule 5 permit icmp
[HUAWEI-acl-adv-3333] quit
[HUAWEI] capture-packet cpu acl 3333 destination terminal packet-num 3
Warning: Mirrored packets will be shown on terminal.
[HUAWEI]
Packet: 1
-------------------------------------------------------
00 00 11 00 22 01 00 00 0a 88 1c d0 81 00 cb c7
08 00 45 00 00 54 cc 56 00 00 ff 01 1c a9 ac 16
bd 3e ac 16 bd 3d 08 00 95 13 b0 99 00 01 10 75
85 d6 07 e1 06 16 50 4e 47 01 57 17 a2 16 00 01
-------------------------------------------------------

Packet: 2
-------------------------------------------------------
00 00 11 00 22 01 00 00 0a 88 1c d0 81 00 cb c7
08 00 45 00 00 54 cc 56 00 00 ff 01 1c a9 ac 16
bd 3e ac 16 bd 3d 08 00 95 13 b0 99 00 01 10 75
85 d6 07 e1 06 16 50 4e 47 01 57 17 a2 16 00 01
-------------------------------------------------------

Packet: 3
-------------------------------------------------------
00 00 11 00 22 01 00 00 0a 88 1c d0 81 00 cb c7
08 00 45 00 00 54 cc 56 00 00 ff 01 1c a9 ac 16
bd 3e ac 16 bd 3d 08 00 95 13 b0 99 00 01 10 75
85 d6 07 e1 06 16 50 4e 47 01 57 17 a2 16 00 01
-------------------------------------------------------

-----------------packet getting report-----------------
file: NULL
packets getting: cpu
acl: 3333
vlan: - cvlan: -
car: -- timeout: 60s
packets: 3 (expected) 3 (actual)
length: 64 (expected)
----------------

b. After identifying the attack source, configure a blacklist to filter out excess ICMP packets, preventing high CPU usage and ensuring normal processing of ping packets.

[HUAWEI] acl number 3334
[HUAWEI-acl-basic-3334] rule 5 permit icmp source 172.22.189.62 0 destination 172.22.189.61 0
[HUAWEI-acl-basic-3334] quit
[HUAWEI] cpu-defend policy policy1
[HUAWEI-cpu-defend-policy-policy1] blacklist 1 acl 3334
[HUAWEI-cpu-defend-policy-policy1] quit

Apply the attack defense policy policy1. For details, see 3.1 Applying the Attack Defense Policy.

c. The fast ICMP reply function reduces the CPU usage on the MPU. By default, this function is enabled on fixed switches running V100R006C05 and later versions and modular switches running V200R010 and later versions. If the CPU usage on the MPU is high, enable the fast ICMP reply function.

<HUAWEI> system-view
[HUAWEI] icmp-reply fast

l If the CPU usage is not high but ping packets are lost, adjust the CPCAR value for ICMP packets. Generally, the CPCAR is set to 256. If packet loss still occurs while the CPU usage is not high, set the CPCAR value greater than 256.

[HUAWEI] cpu-defend policy policy1
[HUAWEI-cpu-defend-policy-policy1] car packet-type icmp cir 256
[HUAWEI-cpu-defend-policy-policy1] quit

Apply the attack defense policy policy1. For details, see 3.1 Applying the Attack Defense Policy.

1.3.5 TTL Attack

Attack Overview

The value of the time to live (TTL) field in an IP packet decreases by 1 each time the IP packet is forwarded by a device. When a switch receives a large number of packets with the TTL value less than or equal to 1 within a short period, a network loop may occur. As a result, IP packets cannot be forwarded.

Symptom

Some Layer 3 traffic fails to be forwarded and the CPU usage of the switch is high.

Troubleshooting Roadmap

Fault Location Method	Command	Models and Versions
View statistics on packets sent to the CPU.	display cpu-defend statistics packet-type ttl-expired all	V100R006C05 and later versions

Run the display cpu-defend statistics packet-type ttl-expired all command to check whether TTL-expired packets are lost because they exceed the CPCAR and whether the number of lost TTL-expired packets increases.

<HUAWEI> display cpu-defend statistics packet-type ttl-expired all
Statistics on mainboard:
--------------------------------------------------------------------------------
Packet Type          Pass(Packet/Byte)   Drop(Packet/Byte) Last-dropping-time
--------------------------------------------------------------------------------
ttl-expired                      1159              34050 2017-06-06 06:57
                                   NA                  NA
--------------------------------------------------------------------------------
Statistics on slot 1:
--------------------------------------------------------------------------------
Packet Type          Pass(Packet/Byte)   Drop(Packet/Byte) Last-dropping-time
--------------------------------------------------------------------------------
ttl-expired                        1159               34050 2017-06-06 06:57
                                  139344               4093755
--------------------------------------------------------------------------------
Statistics on slot 2:
--------------------------------------------------------------------------------
Packet Type          Pass(Packet/Byte)   Drop(Packet/Byte) Last-dropping-time
--------------------------------------------------------------------------------
ttl-expired                          0                   0 -
                                     0                   0
--------------------------------------------------------------------------------

Root Cause

If a network loop occurs, a switch receives a large number of TTL-expired packets.

Procedure

l If the CPU usage is high, decrease the CPCAR value for TTL-expired packets to reduce the packets sent to the CPU. If TTL-expired packets cannot be forwarded, the configuration will not affect other services. Generally, the CPCAR of TTL-expired packets sent to the CPU is set to 32 kbit/s. If packet loss still occurs but the CPU usage is not high, set the CPCAR value less than 32.

[HUAWEI] cpu-defend policy policy1
[HUAWEI-cpu-defend-policy-policy1] car packet-type ttl-expired cir 32
[HUAWEI-cpu-defend-policy-policy1] quit

Apply the attack defense policy policy1. For details, see 3.1 Applying the Attack Defense Policy.

l The route is unreachable.

a. Identify the attack source. In V100R006C05, use the mirroring function to obtain packets and then use a packet parser such as Wireshark to parse the obtained packets. In versions later than V100R006C05, run the capture-packet cpu command to obtain the TTL-expired packets sent to the CPU.

For example, when the capture-packet cpu command is used to obtain the TTL-expired packets sent to the CPU, the destination IP address of these packets is 222.228.240.4.

In the following command output, de e4 f0 04 indicates the destination IP address, which can be converted into 222.228.240.4 in dotted decimal notation.

[HUAWEI] acl 3333
[HUAWEI-acl-adv-3333] rule 5 permit ip ttl-expired
[HUAWEI-acl-adv-3333] quit
[HUAWEI] capture-packet cpu acl 3333 destination terminal packet-num 3
Warning: Mirrored packets will be shown on terminal.
[HUAWEI]
Packet: 1
-------------------------------------------------------
a8 ca 71 ff b0 02 84 ad 58 b5 09 02 81 00 0f ff
08 00 45 c0 00 28 ef 9d 00 00 ff 06 2d 99 de e4
f0 0a de e4 f0 04 d5 01 02 86 7d 91 98 04 24 3a
aa f2 50 10 20 00 35 b1 00 00 00 00 00 00 00 00
-------------------------------------------------------

Packet: 2
-------------------------------------------------------
a8 ca 71 ff b0 02 84 ad 58 b5 09 02 81 00 0f ff
08 00 45 c0 00 28 ef 9d 00 00 ff 06 2d 99 de e4
f0 0a de e4 f0 04 d5 01 02 86 7d 91 98 04 24 3a
aa f2 50 10 20 00 35 b1 00 00 00 00 00 00 00 00
-------------------------------------------------------

Packet: 3
-------------------------------------------------------
a8 ca 71 ff b0 02 84 ad 58 b5 09 02 81 00 0f ff
08 00 45 c0 00 28 ef 9d 00 00 ff 06 2d 99 de e4
f0 0a de e4 f0 04 d5 01 02 86 7d 91 98 04 24 3a
aa f2 50 10 20 00 35 b1 00 00 00 00 00 00 00 00
-------------------------------------------------------

-----------------packet getting report-----------------
file: NULL
packets getting: cpu
acl: 3333
vlan: - cvlan: -
car: -- timeout: 60s
packets: 3 (expected) 3 (actual)
length: 64 (expected)
-------------------------------------------------------

b. After identifying the attack source, run the display ip routing-table 222.228.240.4 command to view the routing table. Identify the next hops, determine the device that drops packets based on the traffic statistics or captured packets, and adjust the route.

[HUAWEI] display ip routing-table 222.228.240.4
Route Flags: R - relay, D - download to fib
------------------------------------------------------------------------------
Routing Table : Public
Summary Count : 1
Destination/Mask Proto Pre Cost Flags NextHop Interface

222.228.240.4/32 Direct 0 0 D 127.0.0.1 LoopBack0

1.3.6 TCP Attack

Attack Overview

The TCP SYN attack takes advantage of the vulnerability of three-way handshakes of TCP. During the three-way handshakes of TCP, a receiver sends a SYN+ACK packet to the sender after receiving an initial SYN packet from the sender. When the receiver is waiting for the final ACK packet from the sender, the connection is in half-connected mode. If the receiver fails to receive the ACK packet, it resends a SYN+ACK packet to the sender. If the sender does not return any ACK packet after the receiver retransmits several SYN+ACK packets, the receiver closes the session and refreshes sessions in the memory. The process of transmitting the first SYN+ACK packet to closing the session takes about 30s.

During this period, an attacker may send hundreds of thousands of SYN packets to open interfaces and does not respond to the SYN+ACK packet from the receiver. The memory of the receiver is overloaded so it cannot accept any new connection requests; then, the receiver disconnects all active connections.

To process TCP SYN attacks, TCP SYN flood attack defense must be enabled on the device and a rate limit must be configured for TCP SYN packets, so that resources of the attacked device are not exhausted.

In addition, a hacker may attack the user network with the worm virus through TCP/UDP ports, threatening a large number of users on the user network.

Symptom

1. The resource usage, such as CPU and memory usage of a device is high when the device is attacked by a large number of TCP packets. Besides, FTP, SSH, Telnet, and other services using the TCP connections may be affected. The device may fail to be managed.

2. The device forwards IP packets from any TCP/UDP port by default. If a hacker initiates virus attacks through TCP/UDP ports, data of a large number of users will lose. The following table lists high-risk ports frequently used by some well-known viruses.

Port Number	Function	Virus	Impact
135	DCOM and RPC services	Worm	System restart
137	NetBIOS service	Worm	System restart and remote control
139	NetBIOS session service	Rbot	System permission theft
445	File transfer and remote network management	Blackmail virus	Data damage
4444	Dynamic port	Blaster virus	System restart
5554	Dynamic port	Sasser virus	Virus spreading

Troubleshooting Roadmap

Fault Location Method	Command	Models and Versions
View statistics on packets sent to the CPU.	display cpu-defend statistics packet-type tcp all	V100R006C05 and later versions
View the TCP connection status.	display tcp status	V100R006C05 and later versions
Defend against viruses taking advantage of port vulnerabilities.	Apply traffic policies to filter out packets from high-risk ports.	V100R006C05 and later versions

1. Run the display cpu-defend statistics packet-type tcp all command to check whether TCP packets are lost because they exceed the CPCAR and whether the number of lost TCP packets increases.

<HUAWEI> display cpu-defend statistics packet-type tcp all
Statistics on mainboard:
--------------------------------------------------------------------------------
Packet Type          Pass(Packet/Byte)   Drop(Packet/Byte) Last-dropping-time
--------------------------------------------------------------------------------
tcp                              251484              31436 2017-06-06 06:57
                                    NA                  NA
--------------------------------------------------------------------------------
Statistics on slot 1:
--------------------------------------------------------------------------------
Packet Type         Pass(Packet/Byte)  Drop(Packet/Byte) Last-dropping-time
--------------------------------------------------------------------------------
tcp                             251484              31436 2017-06-06 06:57
                              34785192             2352384
--------------------------------------------------------------------------------

2. Run the display tcp status command to check whether the status of many TCP connections is Syn_Rcvd.

<HUAWEI> display tcp status
TCPCB    Tid/Soid Local Add:port        Foreign Add:port      VPNID State
ae66b700 115/5    0.0.0.0:22            0.0.0.0:0             -1     Listening
b36882d4 115/3    0.0.0.0:23            0.0.0.0:0             -1     Listening
ae66c384 220/3    0.0.0.0:179           222.228.240.55:0      0      Listening
ae66bdf4 220/6    0.0.0.0:179           222.228.240.56:0      0      Listening
ae8ff950 115/27   192.92.42.221:23      192.192.240.128:33970 0      Established
ae66c64c 115/24   192.92.42.221:23      192.192.240.203:59438 0      Established
526d3158 286/1    192.92.42.221:60920   192.192.255.1:21      0      Syn_Rcvd
526d2bc8 223/19   222.228.240.3:646     222.228.240.4:52186   0      Established
526d3b14 223/16   222.228.240.3:646     222.228.240.9:55388   0      Established
ae8ff7ec 223/23   222.228.240.3:646     222.228.240.59:65037 0      Syn_Rcvd
ae66bb2c 220/20   222.228.240.3:53850   222.228.240.56:179    0      Established
ae8ff688 220/28   222.228.240.3:56789   222.228.240.55:179    0      Established

Root Cause

A TCP connection can be established after three-way handshakes. The large number of TCP connections in half-connected mode occupy many system resources, which affect protocols using TCP for connection establishment. Normal running of services is affected.

Procedure

l If the resource usage, such as CPU and memory usage of a device is high, FTP, SSH, Telnet, and other services using the TCP connections may be affected. There is a probability that the device cannot be managed. To solve this problem, perform the following steps:

a. Disable the HTTP service because HTTP connection requests received on the device pose security risks. Note that the web system cannot be used after the HTTP service is disabled.

<HUAWEI> system-view
[HUAWEI] undo http server enable
[HUAWEI] undo http secure-server enable

b. Configure attack detection on TCP SYN flood attacks.

<HUAWEI> system-view
[HUAWEI] anti-attack tcp-syn enable
[HUAWEI] anti-attack tcp-syn car cir 8000

c. If the resource usage is high, reduce the CPCAR for TCP packets. Generally, the CPCAR is set to 256. If packet loss still occurs but the device CPU usage is not high, set the CPCAR value greater than 256.

[HUAWEI] cpu-defend policy policy1
[HUAWEI-cpu-defend-policy-policy1] car packet-type tcp cir 256
[HUAWEI-cpu-defend-policy-policy1] quit

Apply the attack defense policy policy1. For details, see 3.1 Applying the Attack Defense Policy.

d. Identify the attack source. In V100R006C05, use the mirroring function to obtain packets and then use a packet parser such as Wireshark to parse the obtained packets. In versions later than V100R006C05, run the capture-packet cpu command to obtain the TCP packets sent to the CPU.

For example, when the capture-packet cpu command is used to obtain the TCP packets sent to the CPU, the source and destination IP addresses of these packets are 172.22.189.62 and 172.22.189.61, respectively.

[HUAWEI] acl 3333
[HUAWEI-acl-adv-3333] rule 5 permit tcp
[HUAWEI-acl-adv-3333] quit
[HUAWEI] capture-packet cpu acl 3333 destination terminal packet-num 3
Warning: Mirrored packets will be shown on terminal.
[HUAWEI]
Packet: 1
-------------------------------------------------------
00 00 11 00 22 01 00 00 0a 88 1c d0 81 00 cb c7
08 00 45 c0 00 2c d2 05 00 00 ff 06 16 5d ac 16
bd 3e ac 16 bd 3d d3 c7 00 17 83 0c 39 f6 00 00
00 00 60 02 20 00 14 9c 00 00 02 04 05 b4 00 00
-------------------------------------------------------

Packet: 2
-------------------------------------------------------
00 00 11 00 22 01 00 00 0a 88 1c d0 81 00 cb c7
08 00 45 c0 00 2c d2 05 00 00 ff 06 16 5d ac 16
bd 3e ac 16 bd 3d d3 c7 00 17 83 0c 39 f6 00 00
00 00 60 02 20 00 14 9c 00 00 02 04 05 b4 00 00
-------------------------------------------------------

Packet: 3
-------------------------------------------------------
00 00 11 00 22 01 00 00 0a 88 1c d0 81 00 cb c7
08 00 45 c0 00 2c d2 05 00 00 ff 06 16 5d ac 16
bd 3e ac 16 bd 3d d3 c7 00 17 83 0c 39 f6 00 00
00 00 60 02 20 00 14 9c 00 00 02 04 05 b4 00 00
-------------------------------------------------------

-----------------packet getting report-----------------
file: NULL
packets getting: cpu
acl: 3333
vlan: - cvlan: -
car: -- timeout: 60s
packets: 3 (expected) 3 (actual)
length: 64 (expected)
-------------------------------------------------------

e. After identifying the attack source, configure a blacklist to filter out useless TCP packets.

[HUAWEI] acl number 3334
[HUAWEI-acl-adv-3334] rule 5 permit tcp source 172.22.189.62 0
[HUAWEI-acl-adv-3334] quit
[HUAWEI] cpu-defend policy policy1
[HUAWEI-cpu-defend-policy-policy1] blacklist 1 acl 3334
[HUAWEI-cpu-defend-policy-policy1] quit

Apply the attack defense policy policy1. For details, see 3.1 Applying the Attack Defense Policy.

l If hackers take advantage of TCP/UDP port vulnerabilities to initiate virus attacks, data of a large number of users will lose. To solve this problem, perform the following steps:

a. Create ACL rules for high-risk ports.

[HUAWEI] acl number 3000 //The ACL number ranges from 3000 to 4000 and is not used.
[HUAWEI-acl-adv-3000] rule 5 permit tcp destination-port eq 445
[HUAWEI-acl-adv-3000] rule 10 permit tcp destination-port eq 135
[HUAWEI-acl-adv-3000] rule 15 permit tcp destination-port eq 137
[HUAWEI-acl-adv-3000] rule 20 permit tcp destination-port eq 139
[HUAWEI-acl-adv-3000] rule 25 permit udp destination-port eq 445
[HUAWEI-acl-adv-3000] rule 30 permit udp destination-port eq 135
[HUAWEI-acl-adv-3000] rule 35 permit udp destination-port eq 137
[HUAWEI-acl-adv-3000] rule 40 permit udp destination-port eq 139
[HUAWEI-acl-adv-3000] quit

b. Configure a traffic policy.

[HUAWEI] traffic classifier deny-bingdu
[HUAWEI-classifier-deny-bingdu] if-match acl 3000
[HUAWEI-classifier-deny-bingdu] quit
[HUAWEI] traffic behavior deny-bingdu
[HUAWEI-behavior-deny-bingdu] deny
[HUAWEI-behavior-deny-bingdu] quit
[HUAWEI] traffic policy deny-bingdu
[HUAWEI-trafficpolicy-deny-bingdu] classifier deny-bingdu behavior deny-bingdu
[HUAWEI-trafficpolicy-deny-bingdu] quit

c. Apply the traffic policy to an interface, interface group, or in the system view.

n Apply the traffic policy to an interface.

[HUAWEI] interface GigabitEthernet0/0/1
[HUAWEI-GigabitEthernet0/0/1] traffic-policy deny-bingdu inbound
[HUAWEI-GigabitEthernet0/0/1] traffic-policy deny-bingdu outbound

n Apply the traffic policy in the system view.

[HUAWEI] traffic-policy deny-bingdu global inbound
[HUAWEI] traffic-policy deny-bingdu global outbound

n Apply the traffic policy to an interface group. In this way, you do not need to apply the traffic policy to multiple interfaces repeatedly.

[HUAWEI] port-group deny-bingdu
[HUAWEI-port-group-deny-bingdu] group-member GigabitEthernet0/0/1 to GigabitEthernet0/0/10
[HUAWEI-port-group-deny-bingdu] traffic-policy deny-bingdu inbound
[HUAWEI-port-group-deny-bingdu] traffic-policy deny-bingdu outbound

1. Before the configuration, check whether these high-risk ports provide other services normally. Application of the commands may affect normal use of these services.

2. It is recommended that you configure commands in this section on the core and aggregation switches. If any computer on the intranet is infected with viruses, you need to configure these commands on the access switches to which the computers connect.

3. You are advised to apply the traffic policy to all interfaces. Alternatively, apply the traffic policy in the system view or uplink interfaces.

4. The traffic-policy command can be configured in the system view or on an interface only once. If a traffic policy already exists in the system view or on the interface, the configuration fails. You can add the classifier deny-bingdu behavior deny-bingdu command to the traffic policy.

1.3.7 OSPF Attack

Attack Overview

OSPF neighbors periodically send Hello packets to maintain neighbor relationships. The rate at which a device sends OSPF packets to the CPU is limited. If a device receives too many OSPF packets, it cannot normally send OSPF Hello packets to the CPU, causing OSPF neighbor flapping.

Symptom

OSPF routes are unreachable. As a result, Layer 3 service traffic cannot be forwarded.

Troubleshooting Roadmap

Fault Location Method	Command	Models and Versions
Check whether the log contains OSPF neighbor flapping information.	display logbuffer	V100R006C05 and later versions
View statistics on packets sent to the CPU.	display cpu-defend statistics packet-type tcp all	V100R006C05 and later versions

1. Run the display logbuffer command to check whether the log contains OSPF neighbor flapping information.

Feb 15 2017 21:40:20+08:00 HUAWEI %OSPF/3/NBR_CHG_DOWN(l)[131]:Neighbor event:neighbor state changed to Down.
(ProcessId=1, NeighborAddress=10.136.1.25, NeighborEvent=InactivityTimer, NeighborPreviousState=Full, NeighborCurrentState=Down)

Feb 15 2017 21:40:20+08:00 HUAWEI %OSPF/3/NBR_DOWN_REASON(l)[132]:Neighbor state leaves full or changed to Down.
(ProcessId=1, NeighborRouterId=10.136.0.253, NeighborAreaId=0, NeighborInterface=Vlanif903,NeighborDownImmediate reason=Neighbor Down Due to Inactivity, NeighborDownPrimeReason=Hello Not Seen, NeighborChangeTime=2017-06-06 06:57+08:00)

2. Run the display cpu-defend statistics packet-type ospf all command to check whether OSPF packets are lost because they exceed the CPCAR and whether the number of lost OSPF packets increases.

<HUAWEI> display cpu-defend statistics packet-type ospf all
Statistics on mainboard:
--------------------------------------------------------------------------------
Packet Type          Pass(Packet/Byte)   Drop(Packet/Byte) Last-dropping-time
--------------------------------------------------------------------------------
ospf                         36678                  48790 2017-06-06 06:57
                                NA                  NA
--------------------------------------------------------------------------------
Statistics on slot 1:
--------------------------------------------------------------------------------
Packet Type          Pass(Packet/Byte)   Drop(Packet/Byte) Last-dropping-time
--------------------------------------------------------------------------------
ospf                        18265                  24327 2017-06-06 06:57
                          4164330                 5546436
--------------------------------------------------------------------------------
Statistics on slot 2:
--------------------------------------------------------------------------------
Packet Type          Pass(Packet/Byte)   Drop(Packet/Byte) Last-dropping-time
--------------------------------------------------------------------------------
ospf                          18413                  24463 2017-06-06 06:57
                            4119574                  5473151
--------------------------------------------------------------------------------

Root Cause

A loop is detected on the network or there are too many OSPF neighbors, so the device is attacked by a large number of OSPF packets.

Procedure

Step 1 Run the display cpu-defend statistics packet-type ospf all command to check whether OSPF packets are lost because they exceed the CPCAR and whether the number of lost OSPF packets increases. If the device receives a large number of OSPF packets within a short period of time, check for Layer 2 loops.

Step 2 If the default CPCAR does not meet the requirements because there are too many OSPF neighbors, adjust the CPCAR value. Generally, the CPCAR is set to 384. If packet loss still occurs but the device CPU usage is not high, set the CPCAR value greater than 384.

[HUAWEI] cpu-defend policy policy1
[HUAWEI-cpu-defend-policy-policy1] car packet-type ospf cir 384
[HUAWEI-cpu-defend-policy-policy1] quit

Apply the attack defense policy policy1. For details, see 3.1 Applying the Attack Defense Policy.

Step 3 Configure the OSPF sham hello function. This function allows the device to maintain neighbor relationships through not only Hello packets but also all OSPF protocol packets. This prevents OSPF neighbor flapping caused by loss of OSPF Hello packets.

<HUAWEI> system-view
[HUAWEI] ospf 100
[HUAWEI-ospf-100] sham-hello enable

Step 4 Run the silent-interface command to disable an interface from receiving and sending OSPF packets. After the configuration, the interface cannot set up OSPF neighbor relationships, reducing OSPF packet exchanges.

<HUAWEI> system-view
[HUAWEI] ospf 100
[HUAWEI-ospf-100] silent-interface vlanif 200

Step 5 Identify the attack source. In V100R006C05, use the mirroring function to obtain packets and then use a packet parser such as Wireshark to parse the obtained packets. In versions later than V100R006C05, run the capture-packet cpu command to obtain the OSPF packets sent to the CPU.

For example, when the capture-packet cpucommand is used to obtain the OSPF packets sent to the CPU, the source IP address of these packets is 172.22.189.62.

In the following command output, ac 16 bd 3e indicates the source IP address, which can be converted into 172.22.189.62 in dotted decimal notation.

[HUAWEI] acl 3333
[HUAWEI-acl-adv-3333] rule 5 permit ip destination 224.0.0.5 0
[HUAWEI-acl-adv-3333] quit
[HUAWEI] capture-packet cpu acl 3333 destination terminal packet-num 3
Warning: Mirrored packets will be shown on terminal.
[HUAWEI]
Packet: 1
-------------------------------------------------------
01 00 5e 00 00 05 00 00 0a 88 1c d0 81 00 cb c7
08 00 45 c0 00 44 5a 39 00 00 01 59 15 0e ac 16
bd 3e e0 00 00 05 02 01 00 30 ac 11 07 c2 00 00
00 00 95 17 00 00 00 00 00 00 00 00 00 00 ff ff
-------------------------------------------------------

Packet: 2
-------------------------------------------------------
01 00 5e 00 00 05 00 00 0a 88 1c d0 81 00 cb c7
08 00 45 c0 00 44 5a 39 00 00 01 59 15 0e ac 16
bd 3e e0 00 00 05 02 01 00 30 ac 11 07 c2 00 00
00 00 95 17 00 00 00 00 00 00 00 00 00 00 ff ff
-------------------------------------------------------

Packet: 3
-------------------------------------------------------
01 00 5e 00 00 05 00 00 0a 88 1c d0 81 00 cb c7
08 00 45 c0 00 44 5a 39 00 00 01 59 15 0e ac 16
bd 3e e0 00 00 05 02 01 00 30 ac 11 07 c2 00 00
00 00 95 17 00 00 00 00 00 00 00 00 00 00 ff ff
-------------------------------------------------------

-----------------packet getting report-----------------
file: NULL
packets getting: cpu
acl: 3333
vlan: - cvlan: -
car: -- timeout: 60s
packets: 3 (expected) 3 (actual)
length: 64 (expected)
-------------------------------------------------------

Step 6 After identifying the attack source, configure a blacklist to filter out useless OSPF packets.

[HUAWEI] acl number 2001
[HUAWEI-acl-basic-2001] rule 5 permit source 172.22.189.62 0
[HUAWEI-acl-basic-2001] quit
[HUAWEI] cpu-defend policy policy1
[HUAWEI-cpu-defend-policy-policy1] blacklist 1 acl 2001
[HUAWEI-cpu-defend-policy-policy1] quit

Apply the attack defense policy policy1. For details, see 3.1 Applying the Attack Defense Policy.

----End

1.3.8 TC Attack

Attack Overview

After a device receives a TC packet, it instructs the ARP module to age or delete ARP entries. In this case, the device needs to perform ARP learning to obtain the latest ARP entries. However, if the network topology changes frequently or network devices contain many ARP entries, ARP re-learning will lead to excessive ARP packets on the network.

Symptom

Packets are lost, or traffic cannot be forwarded.

Troubleshooting Roadmap

Fault Location Method	Command	Models and Versions
Check whether the device generates a large number of TC packets.	display stp tc-bpdu statistics	V100R006C05 and later versions
Check whether the device has many ARP entries.	display arp	V100R006C05 and later versions
View statistics on packets sent to the CPU.	display cpu-defend statistics slot slot-id	V100R006C05 and later versions

1. Run the display stp tc-bpdu statisticscommand to check the number of sent and received TC packets on interfaces. Run this command multiple times and view the values under TC(Send/Receive)increase.

<HUAWEI> display stp tc-bpdu statistics
-------------------------- STP TC/TCN information --------------------------
MSTID Port                       TC(Send/Receive)      TCN(Send/Receive)
0     GigabitEthernet1/0/9              3/2                  0/0
0     GigabitEthernet1/0/10             1/0                   0/0
1     GigabitEthernet1/0/9              14/9                  -/-
1     GigabitEthernet1/0/10             8/10                  -/-
2     GigabitEthernet1/0/9              3/2                   -/-
2     GigabitEthernet1/0/10             1/0                   -/-

2. Run the display arp command to check whether the device has many (hundreds of) ARP entries. Run the display cpu-defend statistics command to check whether many ARP packets sent to the CPU are lost.

<HUAWEI> display arp
IP ADDRESS      MAC ADDRESS     EXPIRE(M) TYPE        INTERFACE   VPN-INSTANCE
                                          VLAN/CEVLAN
------------------------------------------------------------------------------
157.101.86.2    dcd2-fcf6-e2d1            I -         Vlanif3900
157.101.86.1    643e-8c49-6101 12        D-0         XGE1/0/0
                                          3900/-
...

157.101.86.9    dcd2-fcf6-e2db            I -         Vlanif3940
------------------------------------------------------------------------------
Total:1058         Dynamic:1053       Static:0     Interface:45

<HUAWEI> display cpu-defend statistics slot 1
Statistics on slot 1:
--------------------------------------------------------------------------------
Packet Type Pass(Packet/Byte) Drop(Packet/Byte) Last-droppingtime
--------------------------------------------------------------------------------
arp-miss 0 0-00
arp-reply           13688251                 2 2017-06-06 06:57
                   931881104               136
arp-request        176181433             39657 2017-06-06 06:57
                 11661818724           2580864

Root Cause

TC packet attacks lead to frequent update of ARP entries. As a result, packets are lost, or traffic cannot be forwarded.

Procedure

1. A device deletes MAC address entries and ARP entries after receiving TC packets. Frequent entry deletion may cause high CPU usage. To reduce the CPU usage, increase the interval for processing TC packets. For example, set the interval to 120 seconds.

<HUAWEI> system-view
[HUAWEI] stp tc-protection interval 120

2. Disable the device from responding to TC packets and configure the MAC address triggered ARP entry update function. After that, the device neither ages out nor deletes ARP entries when receiving TC packets.

<HUAWEI> system-view
[HUAWEI] mac-address update arp
[HUAWEI] arp topology-change disable

1.3.9 SSH/Telnet Attack

Attack Overview

The rate at which a device sends SSH/Telnet packets to the CPU is limited. When the device is attacked by unauthorized users or too many users log in to the device simultaneously through SSH/Telnet, the device may fail to be managed. It is recommended that whitelists be used to control the users who can log in to devices, preventing bogus devices and unauthorized access.

Symptom

Users fail to log in to the device.

Troubleshooting Roadmap

Fault Location Method	Command	Models and Versions
View statistics on packets sent to the CPU.	display cpu-defend statistics packet-type ssh all display cpu-defend statistics packet-type telnet all	V100R006C05 and later versions

Fault Location Method

Command

Models and Versions

View statistics on packets sent to the CPU.

display cpu-defend statistics packet-type ssh all

display cpu-defend statistics packet-type telnet all

V100R006C05 and later versions

Run the display cpu-defend statistics packet-type ssh all command to check whether SSH packets are lost because they exceed the CPCAR and whether the number of lost SSH packets increases.

<HUAWEI> display cpu-defend statistics packet-type ssh all
Statistics on mainboard:
--------------------------------------------------------------------------------
Packet Type          Pass(Packet/Byte)   Drop(Packet/Byte) Last-dropping-time
--------------------------------------------------------------------------------
ssh                         159810               2739 2017-06-06 06:57
NA                  NA
--------------------------------------------------------------------------------
Statistics on slot 1:
--------------------------------------------------------------------------------
Packet Type          Pass(Packet/Byte)   Drop(Packet/Byte) Last-dropping-time
--------------------------------------------------------------------------------
ssh                             159810               2739 2017-06-06 06:57
13790778              207864
--------------------------------------------------------------------------------

Run the display cpu-defend statistics packet-type telnet all command to check whether Telnet packets are lost because they exceed the CPCAR and whether the number of lost Telnet packets increases.

<HUAWEI> display cpu-defend statistics packet-type telnet all
Statistics on mainboard:
--------------------------------------------------------------------------------
Packet Type          Pass(Packet/Byte)   Drop(Packet/Byte) Last-dropping-time
--------------------------------------------------------------------------------
telnet                        1577093              13922 2017-06-06 06:57
                                   NA                  NA
--------------------------------------------------------------------------------
Statistics on slot 1:
--------------------------------------------------------------------------------
Packet Type          Pass(Packet/Byte)   Drop(Packet/Byte) Last-dropping-time
--------------------------------------------------------------------------------
telnet                        1577093               13922 2017-06-06 06:57
                            127671081              974564
--------------------------------------------------------------------------------

Root Cause

Attacks from unauthorized users make authorized users fail to log in to the device through SSH/Telnet.

Procedure

1. Identify the attack source.

For example, when the capture-packet cpu command is used to obtain the SSH/Telnet packets sent to the CPU, the source and destination IP addresses of these packets are 172.22.189.62 and 172.22.189.61. Check whether a large number of SSH/Telnet packets are sent to the CPU from the fixed source IP address.

[HUAWEI] acl 3333
[HUAWEI-acl-adv-3333] rule 5 permit tcp destination-port eq 22
[HUAWEI-acl-adv-3333] rule 10 permit tcp destination-port eq telnet
[HUAWEI-acl-adv-3333] quit
[HUAWEI] capture-packet cpu acl 3333 destination terminal packet-num 3
Warning: Mirrored packets will be shown on terminal.
[HUAWEI]
Packet: 1
-------------------------------------------------------
00 00 11 00 22 01 00 00 0a 88 1c d0 81 00 cb c7
08 00 45 c0 00 31 d2 07 00 00 ff 06 16 56 ac 16
bd 3e ac 16 bd 3d d3 c7 00 17 83 0c 39 f7 a6 c1
e0 42 50 18 20 00 8e 36 00 00 ff fd 01 ff fd 03
-------------------------------------------------------

Packet: 2
-------------------------------------------------------
00 00 11 00 22 01 00 00 0a 88 1c d0 81 00 cb c7
08 00 45 c0 00 31 d2 07 00 00 ff 06 16 56 ac 16
bd 3e ac 16 bd 3d d3 c7 00 17 83 0c 39 f7 a6 c1
e0 42 50 18 20 00 8e 36 00 00 ff fd 01 ff fd 03
-------------------------------------------------------

Packet: 3
-------------------------------------------------------
00 00 11 00 22 01 00 00 0a 88 1c d0 81 00 cb c7
08 00 45 c0 00 31 d2 07 00 00 ff 06 16 56 ac 16
bd 3e ac 16 bd 3d d3 c7 00 17 83 0c 39 f7 a6 c1
e0 42 50 18 20 00 8e 36 00 00 ff fd 01 ff fd 03
-------------------------------------------------------

-----------------packet getting report-----------------
file: NULL
packets getting: cpu
acl: 3333
vlan: - cvlan: -
car: -- timeout: 60s
packets: 3 (expected) 3 (actual)
length: 64 (expected)
-------------------------------------------------------

2. After identifying the attack source, configure security policies to control user login. The following is a configuration example:

[HUAWEI] acl number 3334
[HUAWEI-acl-adv-3334] rule 5 permit ip source 172.22.189.62 0
[HUAWEI-acl-adv-3334] quit
[HUAWEI] aaa
[HUAWEI-aaa] local-user admin1234 password irreversible-cipher Helloworld@6789
[HUAWEI-aaa] local-user admin1234 privilege level 3
[HUAWEI-aaa] local-user admin1234 service-type telnet
[HUAWEI-aaa] quit
[HUAWEI] user-interface maximum-vty 15
[HUAWEI] user-interface vty 0 14
[HUAWEI-ui-vty0-14] acl 3334 inbound
[HUAWEI-ui-vty0-14] authentication-mode aaa
[HUAWEI-ui-vty0-14] idle-timeout 20 0
[HUAWEI-ui-vty0-14] screen-length 0
[HUAWEI-ui-vty0-14] protocol inbound telnet

3. Disable the Telnet server function if Telnet login is not required.

<HUAWEI> system-view
[HUAWEI] undo telnet server enable

1.3.10 VRRP Attack

Attack Overview

The master switch in a VRRP group periodically sends VRRP Advertisement packets to other switches to notify them of its normal status. When a backup switch receives too many VRRP protocol packets, the CPU of the backup switch cannot normally process VRRP Advertisement packets. The rate at which a switch sends VRRP protocol packets to the CPU is limited. When the switch receives too many VRRP protocol packets, the VRRP protocol may encounter status flapping.

Symptom

Packet loss occurs during forwarding of Layer 3 service traffic.

Troubleshooting Roadmap

Fault Location Method	Command	Models and Versions
Check whether the VRRP protocol encounters status flapping.	display trapbuffer	V100R006C05 and later versions
View statistics on packets sent to the CPU.	display cpu-defend statistics packet-type vrrp all	V100R006C05 and later versions

1. Run the display trapbuffer command to check whether the log contains VRRP neighbor flapping information.

#Jan 26 2017 22:00:12+09:00 HUAWEI VRRP/2/VRRPCHANGETOMASTER:OID 1.3.6.1.2.1.68.0.1 The status of VRRP changed to master. (VrrpIfIndex=118, VrId=254, IfIndex=118, IPAddress=10.62.3.251, NodeName=ISJPTSIO01HU106, IfName=Vlanif500, ChangeReason=protocol timer expired)
#Jan 26 2017 22:00:12+09:00 HUAWEI VRRP/2/VRRPCHANGETOMASTER:OID 1.3.6.1.2.1.68.0.1 The status of VRRP changed to master. (VrrpIfIndex=124, VrId=254, IfIndex=124, IPAddress=10.173.7.251, NodeName=ISJPTSIO01HU106, IfName=Vlanif3300, ChangeReason=protocol timer expired)

2. Run the display cpu-defend statistics packet-type vrrp all command to check whether VRRP protocol packets are lost because they exceed the CPCAR and whether the number of lost VRRP protocol packets increases.

<HUAWEI> display cpu-defend statistics packet-type vrrp all
Statistics on mainboard:
--------------------------------------------------------------------------------
Packet Type          Pass(Packet/Byte)   Drop(Packet/Byte) Last-dropping-time
--------------------------------------------------------------------------------
vrrp                         8423                   1284 2017-06-06 06:57
                                NA                    NA
--------------------------------------------------------------------------------
Statistics on slot 1:
--------------------------------------------------------------------------------
Packet Type          Pass(Packet/Byte)   Drop(Packet/Byte) Last-dropping-time
--------------------------------------------------------------------------------
vrrp                        0                  0            -
                            0                  0
--------------------------------------------------------------------------------
Statistics on slot 2:
--------------------------------------------------------------------------------
Packet Type          Pass(Packet/Byte)  Drop(Packet/Byte) Last-dropping-time
--------------------------------------------------------------------------------
vrrp                          8413                  1294 2017-06-06 06:57
                           1808574                  277464
------------------------------------

Root Cause

When a loop is detected on a network or the remote device sends VRRP packets at a high frequency, the device is attacked by a large number of VRRP packets.

Procedure

Step 1 Run the display cpu-defend statistics packet-type vrrp all command to check whether VRRP protocol packets are lost because they exceed the CPCAR and whether the number of lost VRRP protocol packets increases. If the device receives a large number of VRRP protocol packets within a short period of time, check for Layer 2 loops.

Step 2 If the default CPCAR does not meet the requirements because of too many VRRP groups, configure an mVRRP group to reduce VRRP packet exchanges.

<HUAWEI> system-view
[HUAWEI] interface vlanif 10
[HUAWEI-Vlanif10] ip address 10.1.1.1 24
[HUAWEI-Vlanif10] vrrp vrid 1 virtual-ip 10.1.1.111
[HUAWEI-Vlanif10] admin-vrrp vrid 1

If the device CPU usage is not high, increase the CPCAR value for VRRP protocol packets.

[HUAWEI] cpu-defend policy policy1
[HUAWEI-cpu-defend-policy-policy1] car packet-type vrrp cir 256
[HUAWEI-cpu-defend-policy-policy1] quit

Apply the attack defense policy policy1. For details, see 3.1 Applying the Attack Defense Policy.

Step 3 Identify the attack source.

For example, when the capture-packet cpucommand is used to obtain the VRRP packets sent to the CPU, the source IP address of these packets is 10.249.63.52.

In the following command output, 0a f9 3f 34 indicates the source IP address, which can be converted into 10.249.63.52 in dotted decimal notation.

[HUAWEI] acl 3333
[HUAWEI-acl-adv-3333] rule 5 permit ip destination 224.0.0.18 0
[HUAWEI-acl-adv-3333] quit
[HUAWEI] capture-packet cpu acl 3333 destination terminal packet-num 3
Warning: Mirrored packets will be shown on terminal.
[HUAWEI]
Packet: 1
-------------------------------------------------------
01 00 5e 00 00 12 00 00 5e 00 01 01 81 00 03 89
08 00 45 c0 00 28 26 10 00 00 ff 70 6a 56 0a f9
3f 34 e0 00 00 12 21 01 78 01 00 01 1c cd 0a f9
3f 36 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-------------------------------------------------------

Packet: 2
-------------------------------------------------------
01 00 5e 00 00 12 00 00 5e 00 01 01 81 00 03 89
08 00 45 c0 00 28 26 10 00 00 ff 70 6a 56 0a f9
3f 34 e0 00 00 12 21 01 78 01 00 01 1c cd 0a f9
3f 36 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-------------------------------------------------------

Packet: 3
-------------------------------------------------------
01 00 5e 00 00 12 00 00 5e 00 01 01 81 00 03 89
08 00 45 c0 00 28 26 10 00 00 ff 70 6a 56 0a f9
3f 34 e0 00 00 12 21 01 78 01 00 01 1c cd 0a f9
3f 36 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-------------------------------------------------------

-----------------packet getting report-----------------
file: NULL
packets getting: cpu
acl: 3333
vlan: - cvlan: -
car: -- timeout: 60s
packets: 3 (expected) 3 (actual)
length: 64 (expected)
-------------------------------------------------------

Step 4 After identifying the attack source, configure a blacklist to filter out useless VRRP packets.

[HUAWEI] acl number 2001
[HUAWEI-acl-basic-2001] rule 5 permit source 10.249.63.52 0
[HUAWEI-acl-basic-2001] quit
[HUAWEI] cpu-defend policy policy1
[HUAWEI-cpu-defend-policy-policy1] blacklist 1 acl 2001
[HUAWEI-cpu-defend-policy-policy1] quit

Apply the attack defense policy policy1. For details, see 3.1 Applying the Attack Defense Policy.

----End

1.3.11 IGMP Attack

Attack Overview

The rate at which a device sends IGMP packets to the CPU is limited. If a device receives too many IGMP packets, it might lead to IGMP multicast protocol flapping. As a result, Layer 2 or Layer 3 multicast service traffic cannot be normally forwarded.

Symptom

After a device is attacked by multicast IGMP packets, the device screen flickers or goes black intermittently when transmitting multicast services. The following symptoms may occur on the device:

1. The CPU defense statistics include the Drop count of IGMP protocol packets.

2. Layer 2 IGMP-Snooping entries or Layer 3 IGMP multicast forwarding entries on the device are Up for a short period of time and are prone to be aged incorrectly.

3. The CPU usage is high, with BCMRX, FTS, SNPG, and MFIB tasks consuming many CPU resources.

Troubleshooting Roadmap

Fault Location Method	Command	Models and Versions
View statistics on packets sent to the CPU.	display cpu-defend statistics packet-type igmp all	V100R006C05 and later versions
View attack source information.	display auto-port-defend attack-source	V200R003 and later versions
Check the Up time of multicast forwarding entries.	display igmp group	V100R006C05 and later versions
Check the Up time of multicast forwarding entries.	display igmp-snooping port-info verbose	V100R006C05 and later versions
Check multicast protocol packet statistics.	display igmp control-message counters	V100R006C05 and later versions
Check multicast protocol packet statistics.	display igmp-snooping statistics vlan	V100R006C05 and later versions

l View statistics on packets sent to the CPU.

Check whether IGMP packets are lost because they exceed the CPCAR and whether the number of lost IGMP packets increases.

<HUAWEI> display cpu-defend statistics packet-type igmp all
Warning: This feature is not supported on slot mainboard.
Statistics on slot 1:
--------------------------------------------------------------------------------
Packet Type          Pass(Packet/Byte)   Drop(Packet/Byte) Last-dropping-time
--------------------------------------------------------------------------------
igmp                               494             297619 2017-06-06 06:57
                                 63232            38095232
--------------------------------------------------------------------------------
Statistics on slot 2:
--------------------------------------------------------------------------------
Packet Type          Pass(Packet/Byte)   Drop(Packet/Byte) Last-dropping-time
--------------------------------------------------------------------------------
igmp                                 0                   0 -
                                     0                   0
--------------------------------------------------------------------------------
Statistics on slot 3:
--------------------------------------------------------------------------------
Packet Type          Pass(Packet/Byte)   Drop(Packet/Byte) Last-dropping-time
--------------------------------------------------------------------------------
igmp                                 0                   0 -
                                     0                   0
--------------------------------------------------------------------------------

l View attack source information.

A switch calculates the rate of protocol packets restricted by port attack defense on a port. If the packet rate exceeds the threshold (60 pps per line card), the switch considers that an attack occurs. Then the switch traces the source and limits the rate of attack packets on the port, and records a log.

Sep 11 2015 15:38:13+01:00 DST Switch %SECE/4/PORT_ATTACK_OCCUR(l)[2]:Auto port-defend started.(SourceAttackInterface=GigabitEthernet1/0/38, AttackProtocol=IGMP)

The device adds the packets within the rate threshold (similar to the CPCAR for protocol packets in attack defense policies) to the low-priority queue, and then sends them to the CPU. The device discards the excess packets.

<HUAWEI> display auto-port-defend attack-source slot 1
Attack source table on slot 1:
Total : 1
--------------------------------------------------------------------------------
Interface Vlan Protocol Expire(s) PacketRate(pps) LastAttackTime
--------------------------------------------------------------------------------
GE1/0/38 NA igmp 299 110 2017-06-06 06:57
--------------------------------------------------------------------------------

l Check the Up time of multicast forwarding entries.

Check the Up time of Layer 2 multicast forwarding entries.

<HUAWEI> display igmp-snooping port-info verbose
The port information of Group 229.0.0.1 on VLAN 3990:
    Time of this group has been up : 00:10:19
The port information of (0.0.0.0, 229.0.0.1):
    Time of this source has been up : 00:10:19
    Port Table on this source(0.0.0.0):
      No.1
        Port name : GE1/0/38
       Time of this port has been up as a host-port : 00:10:19
        Remain time of port expire as dynamic host-port : 00:02:10
        Host-port flags : Dynamic

Check the Up time of Layer 3 multicast forwarding entries.

<HUAWEI> display igmp group
Interface group report information of VPN-Instance: public net
Vlanif3990(19.19.19.199):
Total 1 IGMP Group reported
Group Address Last Reporter Uptime Expires
229.0.0.1 192.85.1.2 00:00:07 00:02:10

l Check multicast protocol packet statistics.

Check the counts of various Layer 2 multicast protocol packets.

<HUAWEI> display igmp-snooping statistics vlan 3990
IGMP Snooping Packets Counter
   Statistics for VLAN 3990
     Recv V1 Report          0
    Recv V2 Report        7245
     Recv V3 Report          0
     Recv V1 Query           0
     Recv V2 Query           0
     Recv V3 Query           0
     Recv Leave              0
     Recv Pim Hello          0
     Send Query(S=0)         0
     Send Query(S!=0)        0
     Suppress Report         0
     Suppress Leave          0
     Proxy Send General Query               0
     Proxy Send Group-Specific Query        0
     Proxy Send Group-Source-Specific Query 0

Check the counts of various Layer 3 multicast protocol packets.

<HUAWEI> display igmp control-message counters
Interface message counter information of VPN-Instance: public net
Vlanif3990(19.19.19.199):
Message Type                Sent        Valid       Invalid     Ignore
------------------------------------------------------------------
General Query               3           0           0           0
Group Query                 0           0           0           0
Source Group Query          0           0           0           0
------------------------------------------------------------------
IGMPV1V2
Report ASM                 0           10612      0           0
Report SSM                  0           0           0           0
------------------------------------------------------------------
LEAVE ASM                   0           0           0           0
LEAVE SSM                   0           0           0           0
------------------------------------------------------------------
IGMPV3
ISIN Report                 0           0           0           0
ISEX Report                 0           0           0           0
TOIN Report                 0           0           0           0
TOEX Report                 0           0           0           0
ALLOW Report                0           0           0           0
BLOCK Report                0           0           0           0
Source Records Total        0           0           0           0
------------------------------------------------------------------
Others                      -           -           0           0
------------------------------------------------------------------

Root Cause

The Layer 2 or Layer 3 multicast function is enabled on a switch on the network. In versions earlier than V200R010, the switch may incorrectly send IGMP protocol packets from all VLANs including those VLANs not running the multicast service.

Additionally, one or multiple ports on the switch may receive a large number of IGMP protocol packets due to factors such as system configuration, network environment, and connected device. These protocol packets are replicated into multiple copies and forwarded by software, which also result in a high CPU usage.

Procedure

Attack Model	Method	Advantage	Disadvantage
A VLAN not running the multicast service has a large number of IGMP packets.	Configure intra-VLAN transparent transmission of protocol packets.	Protocol packets that do not need to be sent to the CPU can be transmitted transparently by VLAN.	1. Only HI series fixed and modular switches support this method 2. The VLANs in which IGMP packets exist must be determined first. 3. If there are many VLANs having IGMP packets, the configuration is complex.
	Drop unnecessary protocol packets by configuring a traffic policy to redirect the packets to a nonexistent VLAN.	All IGMP packets except those from a specified VLAN are discarded on port or globally.	Multiple traffic classifiers and traffic behaviors need to be configured, leading to complex configuration. Only modular switches support this method.
A specific port is attacked by IGMP packets of a specific type.	Configure attack source tracing to drop IGMP attack packets.	Attack source tracing can be applied on the switch or a specified card to identify and drop packets from a specified port and VLAN.	Users need to determine whether packets are attack packets according to the threshold. Packets are not dropped permanently. They are dropped only within the penalty time.
User-side interfaces receive a large number of Leave packets.	Configure a blacklist to drop Leave packets.	The blacklist can be applied on the switch or a specified card to drop attack packets.	The CPU usage is not effectively reduced.

l Configure intra-VLAN transparent transmission of protocol packets.

Application scenario: A large number of IGMP packets from a VLAN not running the multicast service are incorrectly sent to the CPU.

Applicable model: HI series fixed and modular switches

Method:Enable transparent transmission of protocol packets in the VLANs that do not process the protocol packets. In this way, protocol packets in these VLANs are transparently forwarded to other devices and will not be sent to the CPU, improving forwarding efficiency. Packets of the following protocols support transparent transmission: CFM, ARP, BFD, DHCPv4, DHCPv6, HTTP, IGMP, MLD, ND, PIM, PIMv6, PPPoE, and TACACS.

Precautions:

1. Before running the protocol-transparentcommand, ensure that IGMP/MLD Snooping is disabled in the VLAN; otherwise, the configuration fails.

2. After the protocol-transparent command is executed in a VLAN, the switch does not participate in protocol calculation in this VLAN.

Commands:

[HUAWE] vlan 3999
[HUAWEI-vlan3999] protocol-transparent

l Drop unnecessary protocol packets by configuring a traffic policy to redirect the packets to a nonexistent VLAN.

Applicable scenario: Multicast protocol packets of only one VLAN need to be sent to the CPU, and multicast protocol packets in other VLANs are all unnecessary.

Applicable model: modular switches

Method: Drop IGMP protocol packets from all VLANs except a specified VLAN.

Precautions:Multiple traffic classifiers and traffic behaviors need to be configured, leading to complex configuration. Only modular switches support this method.

Commands:

The following example commands enable the switch to drop IGMP packets from all VLANs except VLAN 3990.

[HUAWEI] acl number 3100 //This ACL number cannot conflict with the existing ACL numbers on the switch.
[HUAWEI-acl-adv-3100] rule 5 permit igmp // Match IGMP protocol packets.
[HUAWEI-acl-adv-3100] quit
[HUAWEI] traffic classifier igmp-permit-cvlan
[HUAWEI-classifier-igmp-permit-cvlan] if-match acl 3100
[HUAWEI-classifier-igmp-permit-cvlan] if-match cvlan-id 3990 //Allow IGMP packets with inner VLAN ID 3990 to pass.
[HUAWEI-classifier-igmp-permit-cvlan] quit
[HUAWEI] traffic classifier igmp-permit-vlan
[HUAWEI-classifier-igmp-permit-vlan] if-match acl 3100
[HUAWEI-classifier-igmp-permit-cvlan] if-match cvlan-id 3990 //Allow IGMP packets from VLAN 3990 to pass.
[HUAWEI-classifier-igmp-permit-vlan] quit
[HUAWEI] traffic classifier igmp-deny
[HUAWEI-classifier-igmp-deny] if-match acl 3100 //Redirect all the other IGMP packets to a nonexistent VLAN.
[HUAWEI-classifier-igmp-deny] quit
[HUAWEI] traffic behavior igmp-deny
[HUAWEI-behavior-igmp-deny] permit
[HUAWEI-behavior-igmp-deny] remark vlan-id 4090 // Create a VLAN not in use according to the actual situation.
[HUAWEI-behavior-igmp-deny] quit
[HUAWEI] traffic behavior igmp-permit
[HUAWEI-behavior-igmp-permit] permit
[HUAWEI-behavior-igmp-permit] remark vlan-id 3990
[HUAWEI-behavior-igmp-permit] quit
[HUAWEI] traffic policy igmp
[HUAWEI-trafficpolicy-igmp] classifier igmp-permit-cvlan behavior igmp-permit
[HUAWEI-trafficpolicy-igmp] classifier igmp-permit-vlan behavior igmp-permit
[HUAWEI-trafficpolicy-igmp] classifier igmp-deny behavior igmp-deny
[HUAWEI-trafficpolicy-igmp] quit
[HUAWEI] traffic-policy igmp global inbound //Apply the traffic policy globally.

l Configure attack source tracing to drop IGMP attack packets.

Applicable scenario: A port receives a large number of IGMP attack packets.

Applicable model: all

Method:Enable a switch to trace the source of a specified type of packets sent to the CPU.

Precautions:If you do not want IGMP packets from certain VLANs to be dropped, configure a whitelist to exclude them from attack source tracing.

Commands:

[HUAWEI] cpu-defend policy test
[HUAWEI-cpu-defend-policy-test] auto-port-defend enable //Enable attack source tracing.
[HUAWEI-cpu-defend-policy-test] undo auto-defend protocol arp dhcp icmp tcp telnet ttl-expired //Match IGMP packets.
[HUAWEI-cpu-defend-policy-test] auto-defend threshold 70 //Determine packets whose rate exceeds 70 pps as attack packets.
[HUAWEI-cpu-defend-policy-test] auto-defend action deny timer 3600 //Drop packets within the penalty time, which is 1 hour. (The default value is 300s.)
[HUAWEI-cpu-defend-policy-test] auto-defend trace-type source-portvlan

Apply the attack defense policy. For details, see 3.1 Applying the Attack Defense Policy.

l Configure a blacklist to drop Leave packets.

Applicable scenario: A port sends a large number of IGMP Leave packets to the CPU.

Applicable model: modular switches, S5720HI fixed switches, EI and HI series fixed switches running V200R008 and later versions

Method:Configure a blacklist to drop a specified type of Leave packets sent to the CPU.

Precautions:It is recommended that you configure a blacklist only for IGMPv2 Leave packets.

Commands:

[HUAWEI] acl number 3000
[HUAWEI-acl-adv-3000] rule 5 permit igmp destination 224.0.0.2 0 //Match IGMP Leave packets.
[HUAWEI-acl-adv-3000] quit
[HUAWEI] cpu-defend policy test
[HUAWEI-cpu-defend-policy-test] blacklist 1 acl 3000 //Set a blacklist.
[HUAWEI-cpu-defend-policy-test] quit

Apply the attack defense policy. For details, see 3.1 Applying the Attack Defense Policy.

1.3.12 PIM Attack

Attack Overview

The rate at which a device sends PIM packets to the CPU is limited. If a device receives too many PIM packets, it might lead to PIM route flapping or PIM neighbor flapping. As a result, Layer 3 multicast service traffic cannot be normally forwarded.

Symptom

After a device is attacked by multicast PIM packets, the device screen flickers or goes black intermittently when transmitting multicast services. The following symptoms may occur on the device:

1. The CPU defense statistics include the Drop count of PIM protocol packets.

2. Layer 3 multicast forwarding entries on the device are Up for a short period of time and are prone to be aged incorrectly, leading to forwarding exceptions of Layer 3 multicast traffic.

3. The CPU usage is high, with BCMRX, FTS, MFIB, and MCSW tasks consuming many CPU resources.

Troubleshooting Roadmap

Fault Location Method	Command	Models and Versions
View statistics on packets sent to the CPU.	display cpu-defend statistics packet-type pim all	V100R006C05 and later versions, which support Layer 3 multicast features
Check the Up time of multicast forwarding entries.	display pim routing-table fsm	V100R006C05 and later versions, which support Layer 3 multicast features
Check PIM protocol packet statistics.	display pim control-message counters	V100R006C05 and later versions, which support Layer 3 multicast features

l View statistics on packets sent to the CPU.

Run the display cpu-defend statistics packet-type pim all command to check whether PIM packets are lost because they exceed the CPCAR and whether the number of lost PIM packets increases.

<HUAWEI> display cpu-defend statistics packet-type pim all
Warning: This feature is not supported on slot mainboard.
Statistics on slot 1:
--------------------------------------------------------------------------------
Packet Type          Pass(Packet/Byte)   Drop(Packet/Byte) Last-dropping-time
--------------------------------------------------------------------------------
pim                               2132              3748 2017-06-06 06:57
                                272896              479744
--------------------------------------------------------------------------------
Statistics on slot 2:
--------------------------------------------------------------------------------
Packet Type          Pass(Packet/Byte)   Drop(Packet/Byte) Last-dropping-time
--------------------------------------------------------------------------------
pim                                  0                   0 -
                                     0                   0
--------------------------------------------------------------------------------
Statistics on slot 3:
--------------------------------------------------------------------------------
Packet Type          Pass(Packet/Byte)   Drop(Packet/Byte) Last-dropping-time
--------------------------------------------------------------------------------
pim                                  0                   0 -
                                     0                   0
--------------------------------------------------------------------------------

l Check the Up time of multicast forwarding entries.

Run the display pim routing-table fsmcommand to check the Up time of multicast forwarding entries on each outbound interface.

<HUAWEI> display pim routing-table 239.253.92.83 fsm
VPN-Instance: public net
Total 420 (*, G) entries; 343 (S, G) entries

Total matched 1 (*, G) entry; 1 (S, G) entry

Abbreviations for FSM states and Timers:
     NI - no info, J - joined, NJ - not joined, P - pruned,
     NP - not pruned, PP - prune pending, W - winner, L - loser,
     F - forwarding, AP - ack pending, DR - designated router,
     NDR - non-designated router, RCVR - downstream receivers,
     PPT - prunepending timer, GRT - graft retry timer,
     OT - override timer, PLT - prune limit timer,
     ET - join expiry timer, JT - join timer,
     AT - assert timer, PT - prune timer

(*, 239.253.92.83)
     RP: 61.55.156.51
     Protocol: pim-sm, Flag: WC
     UpTime: 32w:4d
     Upstream interface: Vlanif323
         Upstream neighbor: 10.0.4.98
         RPF prime neighbor: 10.0.4.98
         Join/Prune FSM: [J, JT Expires: 00:00:08]
     Downstream interface(s) information:
     Total number of downstreams: 12
         1: Vlanif441
             Protocol: pim-sm, UpTime: 6w:6d, Expires: 00:03:29
             DR state: [NDR]
             Join/Prune FSM: [J]
             Assert FSM: [NI]
         2: Vlanif506
             Protocol: pim-sm, UpTime: 08:37:57, Expires: 00:03:21
             DR state: [NDR]
             Join/Prune FSM: [J]
             Assert FSM: [NI]
         3: Vlanif330
             Protocol: pim-sm, UpTime: 08:37:58, Expires: 00:03:26
             DR state: [DR]
             Join/Prune FSM: [J]
             Assert FSM: [NI]
         4: Vlanif313
             Protocol: pim-sm, UpTime: 14w:1d, Expires: 00:03:27
             DR state: [NDR]
             Join/Prune FSM: [J]
             Assert FSM: [NI]

l Check PIM protocol packet statistics.

Run the display pim control-message counters command to check the PIM protocol packet statistics.

<HUAWEI> display pim control-message counters
VPN-Instance: public net
PIM global control-message counters:
Message Type     Received         Sent             Invalid          Filtered
Register         51               0                0                0
Register-Stop    0                48               0                0
Probe            44               0                0                0
C-RP            0                0                0                0

PIM control-message counters for interface: Vlanif10
Message Type     Received         Sent             Invalid          Filtered
Assert           0                6                0                0
Graft            0                0                0                0
Graft-Ack        0                0                0                0
Hello            34496           34495            0                0
Join-prune       26171            90               0                0
State-Refresh    0                0                0                0
BSR              0                0                0                0

PIM control-message counters for interface: Vlanif20
Message Type     Received         Sent             Invalid          Filtered
Assert           0                0                0                0
Graft            0                0                0                0
Graft-Ack        0                0                0                0
Hello            34491            34495            0                0
Join-prune       0                41               0                0
State-Refresh    0                0                0                0
BSR              0                0                0                0

Root Cause

The Layer 3 multicast function is enabled on a switch on the network, and the switch is interconnected to many Layer 3 PIM neighbors. When there are a large number of multicast group entries on the network, or the network is attacked by a large number of PIM protocol packets:

1. If the PIM-SM protocol is configured, the switch will receive a large number of PIM Join packets from multiple interfaces simultaneously. The rate exceeds the default CPCAR value for PIM protocol packets.

2. If the PIM-DM protocol is configured, the switch will receive a large number of PIM State-Refresh packets from multiple interfaces simultaneously. The rate exceeds the default CPCAR value for PIM protocol packets.

3. If the PIM-SM/DM protocol is configured, the switch will receive a large number of PIM attack packets from a specified interface or multiple interfaces. The rate exceeds the default CPCAR value for PIM protocol packets.

Procedure

Step 1 Set the CPCAR value for PIM protocol packets to a larger value to improve the PIM packet processing capability of the switch. It is recommended that the CIR do not exceed 512 kbit/s.

Modify the CPCAR value as follows:

1. Run the cpu-defend policy and then carpacket-type pim cir cir-value commands to set a new CIR.

<HUAWEI> system-view
[HUAWEI] cpu-defend policy pim
[HUAWEI-cpu-defend-policy-pim] car packet-type pim cir 512
[HUAWEI-cpu-defend-policy-pim] quit

Apply the attack defense policy. For details, see 3.1 Applying the Attack Defense Policy.

Step 2 If the PIM-DM protocol is configured and a large number of PIM State-Refresh packets are transmitted on the network, modify the interval at which the switch sends PIM State-Refresh packets or change the PIM-DM protocol to PIM-SM.

The operations are as follows:

1. Modify the interval at which the switch sends PIM State-Refresh packets.

Set the interval for sending State-Refresh packets on the device directly connected to a multicast source.

[HUAWEI] pim
[HUAWEI-pim] state-refresh-interval interval

Set the minimum duration before new PIM State-Refresh packets are received on all devices.

[HUAWEI] pim
[HUAWEI-pim] state-refresh-rate-limit interval

2. Change the PIM-DM protocol to PIM-SM. Pay attention to the following points:

− PIM-DM and PIM-SM cannot be configured simultaneously in a VPN instance or the public network instance.

− It is recommended that you enable PIM-SM on all interfaces in a PIM-SM domain to ensure that the interfaces can establish neighbor relationships with all connected PIM devices.

− If PIM-SM and IGMP need to be enabled on the same interface, enable PIM-SM, and then enable IGMP.

----End

2 Recommended Local Attack Defense Configuration

2.1 Modular Switches

Scenario Overview

On a live network, there are various types of attacks and the attack type is constantly changing. Therefore, a fixed protection method is unable to defend against all attacks. Instead, protection methods should be adjusted based on the actual scenario. The following provides a widely used attack defense script and attack detection mode to defend against TTL, TCP, ARP, DHCP, and IGMP attacks. After the attack type is determined, the attack defense configuration can be modified according to section 1.3 Defense Measures for Different Types of Attacks.

Script Deployment

# If VLAN 1 is not used on the live network, but interfaces on the access devices and gateways are still in VLAN 1, attacks or storms may occur. Remove interfaces from VLAN 1.

l The interface type is hybrid.

interface GigabitEthernet x/x/x
undo port hybrid vlan 1

l The interface type is trunk.

interface GigabitEthernet x/x/x
port link-type trunk
undo port trunk allow-pass vlan 1

l The interface type is access.

interface GigabitEthernet x/x/x
port link-type access
undo port default vlan 1

# Deploy the attack defense script on the MPU.

cpu-defend policy main-board        # Create the attack defense policy main-board.
car packet-type ttl-expired cir 16 # Set the CIR value to for TTL-expired packets 16 kbit/s.
car packet-type tcp cir 32          # Set the CIR value to for TCP packets 32 kbit/s.
auto-defend enable                  # Enable attack source tracing.
auto-defend attack-packet sample 5 # Set the packet sampling ratio for attack source tracing to 5.
auto-defend threshold 30            # Set the checking threshold for attack source tracing to 30 pps.
undo auto-defend trace-type source-portvlan   # Configure attack source tracing based on the source MAC address and source IP address.
undo auto-defend protocol tcp telnet ttl-expired # Delete TCP, Telnet, and TTL-expired packets from the list of traced packets in attack source tracing.
auto-defend whitelist 1 interface GigabitEthernet x/x/x # Add the interconnection interface and upstream interface to the whitelist for attack source tracing.
auto-defend whitelist 2 interface GigabitEthernet x/x/x # Add the interconnection interface and upstream interface to the whitelist for attack source tracing.
auto-port-defend whitelist 1 interface GigabitEthernet x/x/x # Add the interconnection interface and upstream interface to the whitelist for port attack defense. By default, port attack defense is enabled in V200R003 and later versions.
auto-port-defend whitelist 2 interface GigabitEthernet x/x/x # Add the interconnection interface and upstream interface to the whitelist for port attack defense. By default, port attack defense is enabled in V200R003 and later versions.
cpu-defend-policy main-board       # Apply the attack defense policy.

# Deploy the attack defense script on the LPU.

cpu-defend policy io-board          # Create the attack defense policy io-board.
car packet-type ttl-expired cir 8   # Set the CIR value to for TTL-expired packets 8 kbit/s.
car packet-type tcp cir 16          # Set the CIR value to for TCP packets 16 kbit/s.
auto-defend enable                  # Enable attack source tracing.
auto-defend attack-packet sample 5 # Set the packet sampling ratio for attack source tracing to 5.
auto-defend threshold 30            # Set the checking threshold for attack source tracing to 30 pps.
undo auto-defend trace-type source-portvlan   # Configure attack source tracing based on the source MAC address and source IP address.
undo auto-defend protocol tcp telnet ttl-expired # Delete TCP, Telnet, and TTL-expired packets from the list of traced packets in attack source tracing.
auto-defend whitelist 1 interface GigabitEthernet x/x/x    # Add the interconnection interface and upstream interface to the whitelist for attack source tracing.
auto-defend whitelist 2 interface GigabitEthernet x/x/x    # Add the interconnection interface and upstream interface to the whitelist for attack source tracing.
auto-port-defend whitelist 1 interface GigabitEthernet x/x/x # Add the interconnection interface and upstream interface to the whitelist for port attack defense. By default, port attack defense is enabled in V200R003 and later versions.
auto-port-defend whitelist 2 interface GigabitEthernet x/x/x # Add the interconnection interface and upstream interface to the whitelist for port attack defense. By default, port attack defense is enabled in V200R003 and later versions.
cpu-defend-policy io-board global # Apply the attack defense policy.

Precaution

1. This script applies to V200R008 and earlier versions. In V200R009 and later versions, attack source tracing is enabled by default, and there is no need to deploy this script separately.

2. The TCP CPCAR limits the rate at which local VLANIF or loopback interfaces send packets to the CPU. The rate for other routing protocol packets, such as BGP is not affected by the TCP CPCAR.

3. The ttl-expired parameter is valid for the tracert function only. The rate limit for routing protocol packets containing the TTL field is determined by the CPCAR for each type of routing protocols, but not affected by the ttl-expired parameter.

4. If the customer has modified the cpu-defend policy command, configuration in this script should not conflict with the customer configuration.

2.2 Fixed Switches

Scenario Overview

On a live network, there are various types of attacks and the attack type is constantly changing. Therefore, a fixed protection method is unable to defend against all attacks. Instead, protection methods should be adjusted based on the actual scenario. The following provides a widely used attack defense script and attack detection mode to defend against TTL, TCP, ARP, and DHCP attacks. After the attack type is determined, the attack defense configuration can be modified according to section 1.3 Defense Measures for Different Types of Attacks.

Script Deployment

# If VLAN 1 is not used on the live network, but interfaces on the access devices and gateways are still in VLAN 1, attacks or storms may occur. Remove interfaces from VLAN 1.

l The interface type is hybrid.

interface GigabitEthernet x/x/x
undo port hybrid vlan 1

l The interface type is trunk.

interface GigabitEthernet x/x/x
port link-type trunk
undo port trunk allow-pass vlan 1

l The interface type is access.

interface GigabitEthernet x/x/x
port link-type access
undo port default vlan 1

# Deploy the attack defense script on a switch.

cpu-defend policy io-board           # Create the attack defense policy io-board.
car packet-type ttl-expired cir 8    # Set the CIR value to for TTL-expired packets 8 kbit/s.
car packet-type tcp cir 16           # Set the CIR value to for TCP packets 16 kbit/s.
auto-defend enable                   # Enable attack source tracing.
auto-defend attack-packet sample 5   # Set the packet sampling ratio for attack source tracing to 5.
auto-defend threshold 30             # Set the checking threshold for attack source tracing to 30 pps.
undo auto-defend trace-type source-portvlan   # Configure attack source tracing based on the source MAC address and source IP address.
undo auto-defend protocol tcp igmp telnet ttl-expired   # Delete TCP, IGMP, Telnet, and TTL-expired packets from the list of traced packets in attack source tracing.
auto-defend whitelist 1 interface GigabitEthernet x/x/x # Add the interconnection interface and upstream interface to the whitelist for attack source tracing.
auto-defend whitelist 2 interface GigabitEthernet x/x/x # Add the interconnection interface and upstream interface to the whitelist for attack source tracing.
auto-port-defend whitelist 1 interface GigabitEthernet x/x/x # Add the interconnection interface and upstream interface to the whitelist for port attack defense. By default, port attack defense is enabled in V200R003 and later versions.
auto-port-defend whitelist 2 interface GigabitEthernet x/x/x # Add the interconnection interface and upstream interface to the whitelist for port attack defense. By default, port attack defense is enabled in V200R003 and later versions.
cpu-defend-policy io-board global   # Apply the attack defense policy.

Precaution

1. This script applies to V200R008 and earlier versions. In V200R009 and later versions, attack source tracing is enabled by default, and there is no need to deploy this script separately.

2. The TCP CPCAR limits the rate at which local VLANIF or loopback interfaces send packets to the CPU. The rate for other routing protocol packets, such as BGP is not affected by the TCP CPCAR.

4. If the customer has modified the cpu-defend policy command, configuration in this script should not conflict with the customer configuration.

3 A Appendix

3.1 Applying the Attack Defense Policy

l Modular switches

Both MPUs and LPUs have their own CPUs. Local attack defense policies are configured differentially for MPUs and LPUs.

Before creating and applying attack defense policies, check attack information on the MPUs and LPUs. If the attack information on the MPUs and LPUs is consistent, apply the same attack defense policy to the MPUs and LPUs; otherwise, apply different policies to them.

a. Apply an attack defense policy to an MPU.

<HUAWEI> system-view
[HUAWEI] cpu-defend-policy policy1
[HUAWEI] quit

b. Apply an attack defense policy to an LPU.

If an attack defense policy has been applied to all LPUs, it cannot be applied to the specified LPU. In a similar manner, if an attack defense policy has been applied to a specified LPU, it cannot be applied to all LPUs.

n If all LPUs process similar services, apply an attack defense policy to all LPUs.

<HUAWEI> system-view
[HUAWEI] cpu-defend-policy policy2 global

n If LPUs process different services, apply an attack defense policy to the specified LPU.

<HUAWEI> system-view
[HUAWEI] slot 1
[HUAWEI-slot-1] cpu-defend-policy policy2

l Fixed switches

− Apply an attack defense policy to a stand-alone switch.

<HUAWEI> system-view
[HUAWEI] cpu-defend-policy policy1 global

− In a stack:

n Apply an attack defense policy to the master switch.

<HUAWEI> system-view
[HUAWEI] cpu-defend-policy policy1

n Apply an attack defense policy to all stacked switches.

<HUAWEI> system-view
[HUAWEI] cpu-defend-policy policy1 global

This article contains more resources

You need to log in to download or view. No account? Register

Attack Defense for S series switches [All About Switches]

1 Attack Processing for S Series Switches

1.1 Attack Defense Overview

1.2 Determining the Attack Type

1.3 Defense Measures for Different Types of Attacks

1.3.1 ARP Attack

1.3.1.1 ARP Flood

1.3.1.2 ARP Spoofing

1.3.2 ARP Miss Attack

1.3.2.1 Network Scanning Attack

1.3.3 DHCP Attack

1.3.3.1 Bogus DHCP Server Attack

1.3.3.2 DHCP Flooding Attack

1.3.3.3 DHCP Server DoS Attack

1.3.3.4 DHCP Packets Incorrectly Sent to the CPU

1.3.3.5 DHCP Spoofing

1.3.4 ICMP Attack

1.3.5 TTL Attack

1.3.6 TCP Attack

1.3.7 OSPF Attack

1.3.8 TC Attack

1.3.9 SSH/Telnet Attack

1.3.10 VRRP Attack

1.3.11 IGMP Attack

1.3.12 PIM Attack

2 Recommended Local Attack Defense Configuration

2.1 Modular Switches

2.2 Fixed Switches

3 A Appendix

3.1 Applying the Attack Defense Policy

This article contains more resources

Third Party’s Trade Secret

`@trans`drinking_poetry`~trans`

`@trans`universal_genius`~trans`

`@trans`full_of_learning`~trans`

My Followers

Enterprise

Consumer

Corporate

Carriers

Attack Defense for S series switches [All About Switches]

1 Attack Processing for S Series Switches

1.1 Attack Defense Overview

1.2 Determining the Attack Type

1.3 Defense Measures for Different Types of Attacks

1.3.1 ARP Attack

1.3.1.1 ARP Flood

1.3.1.2 ARP Spoofing

1.3.2 ARP Miss Attack

1.3.2.1 Network Scanning Attack

1.3.3 DHCP Attack

1.3.3.1 Bogus DHCP Server Attack

1.3.3.2 DHCP Flooding Attack

1.3.3.3 DHCP Server DoS Attack

1.3.3.4 DHCP Packets Incorrectly Sent to the CPU

1.3.3.5 DHCP Spoofing

1.3.4 ICMP Attack

1.3.5 TTL Attack

1.3.6 TCP Attack

1.3.7 OSPF Attack

1.3.8 TC Attack

1.3.9 SSH/Telnet Attack

1.3.10 VRRP Attack

1.3.11 IGMP Attack

1.3.12 PIM Attack

2 Recommended Local Attack Defense Configuration

2.1 Modular Switches

2.2 Fixed Switches

3 A Appendix

3.1 Applying the Attack Defense Policy

This article contains more resources

Third Party’s Trade Secret

`@trans`drinking_poetry`~trans`

`@trans`universal_genius`~trans`

`@trans`full_of_learning`~trans`

My Followers