No relevant resource is found in the selected language.

This site uses cookies. By continuing to browse the site you are agreeing to our use of cookies. Read our privacy policy>Search


To have a better experience, please upgrade your IE browser.


FAQ---When ARP MISS is abnormal

Publication Date:  2019-07-09 Views:  5443 Downloads:  0

Issue Description

Maybe every one of you saw at least one time these DEFD/4/CPCAR_DROP_MPU alerts in his logs, shouting at you that ARP MISS messages exceeded the CPCAR limit on the CPU.

DEFD/4/CPCAR_DROP_MPU(l)[0]:Rate of packets to cpu exceeded the CPCAR limit on the MPU. (Protocol=arp-miss, ExceededPacketCount=682)

What are these ARP MISS messages and should they scare us?
ARP MISS messages are messages that are sent to the master control board for processing when the device has a route to a destination but doesn’t have an ARP entry for the next hop of the route.  So, if  a host sends a large number of IP packets with unsolvable destination IP addresses,  the device triggers a large number of ARP Miss messages .  When IP packets trigger ARP Miss messages, the device generates temporary ARP entries and sends ARP Request packets to the destination network.

To be clear, these ARP MISS messages are normal in a lot of situations. When someone from outside our network is trying to reach an inside host and the device doesn’t have an ARP entry for the next hop, an ARP miss message will be generated.

Of course they could be the result of an attack as well because not everyone wants our best in this world.
Some attackers could scan hosts on the local network segment or other network segments and send many IP packets with unresolvable destination IP addresses in this way, harming the device. As a result, the device triggers many ARP Miss messages, generates a large number of fake ARP entries, and broadcasts ARP Request packets to resolve the destination IP addresses, leading to Central Processing Unit (CPU) overload


How to see if you have these ARP fake entries?
You can check the arp incomplete records with the display arp all command . If the MAC ADDRESS field is incomplete for some ip addresses, it means a fake ARP entry was created for it.

Example :
<HUAWEI> display arp all
                                          VLAN     Incomplete      0         D-0         GE0/0/10
                                           200/-   Incomplete      1         D-0         GE0/0/10

How to distinguish good from evil?
There are not a lot of ways to know which is what but is nice to know that there are some ways to fight against these ARP MISS messages when they forget their places.

One of them and maybe the first one you could try in this case is to set the aging time of temporary ARP  entries.

As I said,  when IP packet trigger ARP  Miss messages, the device generates temporary  ARP entries and sends ARP requests to the destination network. When temporary ARP entries age out, the device clears them. If no ARP entry matches the IP packets forwarded by the device, ARP Miss messages are triggered again and temporary ARP entries are regenerated. This process continues.

By default, the aging time of temporary ARP entries is  1 second and might be too small .  You can extend the aging time of temporary ARP entries and reduce the frequency of triggering ARP Miss messages to minimize the impact on the device with this arp-fake expire-time command.

Some other ways may require to limiting the rate of ARP Miss messages based on the source IP address (arp-miss speed-limit source-ip command) or to limit the rate globally/vlan/interface (arp-miss anti-attack rate-limit command).

How to check the source of the attack ?
A way to check the source of ARP MISS messages is to set the maximum number of ARP Miss messages that can be processed in a second to a lower value with the arp-miss speed-limit source-ip maximum command (the default is 500, for example you can configure it to 30) and then check if it was an ARP MISS  attack with the display arp anti-attack arpmiss-record-info command
However this is a little risky because a small value may cause discarding of valid packets. If the threshold is exceeded, the device will discard all ARP Miss packets from  the source IP address for 5 seconds by default.

Another way could be to analyze packets for all the packets that are going to the destinations that creates the fake ARP entries and  you already know how to do that:)

I hope this article will come in handy if you encounter this kind of issue. Thanks!