What Do I Do If the Device Receives a Large Number of ARP Request or Reply Packets?
Network access speed is slow, users are disconnected, network access is frequently interrupted, users cannot access the network, or services are interrupted.
The device has a high CPU usage or is disconnected from the NMS, or the attached devices are disconnected from the network.
Ping responses are delayed, packets are lost, or the ping operation fails.
To resolve the problem, perform the following steps. Saving the results of each troubleshooting step is recommended. If your troubleshooting fails to correct the fault, record your actions and provide the record to technical support personnel.
Run the display cpu-defend statistics packet-type { arp-request | arp-request-uc | arp-reply } all command in the user view to check whether the Drop value of ARP Request or Reply packets increases.
- If the count of dropped packets is 0, go to step 6.
- If the count of dropped packets is not 0, the rate of ARP Request or Reply packets has exceeded the CPCAR rate limit and excess packets have been discarded. Go to step 2.
Run the display cpu-usage command in the user view to check the CPU usage of the device.
- If CPU usage is in the normal range, Go to step 3.
- If CPU usage exceeds 70%, Go to step 5.
Run the car command in the attack defense policy view to increase the CPCAR values for ARP Request or Reply packets.
Improper CPCAR settings will affect services on your network. If you need to adjust CPCAR settings, you are advised to contact technical support personnel for help.
Apply the attack defense policy after running the car command. The attack defense policy can take effect only after it is applied.
After the preceding steps, if the fault persists or the fault is rectified but CPU usage is high, go to step 4.
Obtain packet headers on user-side interfaces of the device, and find the attacker based on the source addresses of the ARP Request or Reply requests received on these interfaces.
If many ARP Request or Reply packets have the same source MAC or IP address, the device considers that the host with this source MAC or IP address is the attack source.
Based on the actual network environment, run the arp speed-limit source-ip [ ip-address ] maximum maximum command in the system view to decrease the rate limit of ARP packets based on the source IP address, or run the arp speed-limit source-mac [ mac-address ] maximum maximum command to limit the rate of ARP packets based on the source MAC address.
When ARP packet rate limit based on the source IP or MAC address has been set to a small value (for example, 5 bit/s), determine whether the fault has been rectified:- If the fault persists, go to step 5.
- If the fault is rectified but CPU usage is high, configure the blacklist or a blackhole MAC address entry so that packets from the attack source will be discarded. After the configuration, if CPU usage is still high, go to step 6.
Obtain packet headers on user-side interfaces of the device, and find the attacker based on the source addresses of ARP Request or Reply packets received on these interfaces.
If a lot of ARP Request or Reply packets are sent from a source address, the device considers the source address as an attack source. Add the source address to the blacklist or configure a blackhole MAC address entry to discard ARP packets sent by the attacker.
If the fault persists, go to step 6.
Collect the following information and contact technical support personnel:
- Result of the preceding procedure
- Configuration file, logs, and alarms of the device