A host that can't reach its gateway looks the same whether someone is attacking your LAN or nobody is. This is how to tell a forged or flooded ARP attack apart from a plain learning failure fast, the display commands that settle it, and the anti-spoofing configuration that closes the gap for good.
By the AtlasCommTech engineering team — 13 years of carrier & enterprise network deployments · Updated July 2026
A host that can't ping its gateway looks identical whether someone is attacking your LAN or nobody is at all.
On Huawei AR routers, ARP problems all reach the same starting point: a display arp table that doesn't look right — an Incomplete entry, a host that suddenly drops off the network, a gateway that seems to have moved. The instinct is to assume an attack. Just as often it's a rate limit configured too aggressively, an ARP fast-reply setting on the wrong device, or a Spanning Tree topology that hasn't converged yet — and treating a plain misconfiguration as an intrusion wastes time chasing an attacker who was never there.
What follows is the split this note is built on — forged or flooded ARP traffic versus a genuine learning failure — the checks for each with the exact commands, the anti-spoofing configuration that closes the attack side outright, and field-case FAQ answers.
ARP faults land in exactly two families: something is actively forging or flooding ARP traffic, or ARP simply never gets learned.
Sorting the symptom into one of these two families first tells you which half of this note actually applies — and stops you from configuring anti-spoofing defenses against a problem that was never an attack.
Diagram labels are kept in English for engineering clarity.
Every branch on the attack side has the same fix pattern: identify the forged source, then close it with an anti-attack switch. Every branch on the learning-failure side is a plain configuration or link problem that has nothing to do with an intruder — enabling anti-spoofing features doesn't do anything for it.
The same first command, display arp, sends you down one of these two branches — everything after it depends on which family you're actually in.
An Incomplete entry isn't proof of an attack by itself — the CPU-defend drop counter is what actually tells you.
<HUAWEI> display arp
IP ADDRESS MAC ADDRESS EXP(M) TYPE/VLAN INTERFACE
10.1.2.1 Incomplete 0 D 10GE0/0/1
// Incomplete = ARP request sent, no reply ever came back
<HUAWEI> display cpu-defend statistics packet-type arp-request all
PacketType Total Passed Total Dropped Last Dropping Time
arp-request 226099 895000132 2022-05-20 11:29:22
// Dropped climbing fast across repeated samples -> attack signature
[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> display auto-defend attack-source slot 0
MacAddress InterfaceName Vlan:Outer/Inner TOTAL
0000-0000-0001 10ge 0/0/1 193 416
// the flagged MAC can include your own gateway or an uplink device -- verify before blacklistingNo attacker anywhere — just a rate limit, a silent peer, or a topology that hasn't finished converging.
<HUAWEI> display cpu-defend statistics all
PacketType Total Passed Total Dropped Last Dropping Time
arp-miss 135576021 1601690 2022-03-31 13:17:49
arp-request 39556247 2009617 2022-03-31 13:17:49
[HUAWEI] display this include-default | include arp miss anti-attack
arp miss anti-attack rate-limit maximum 16384
// ~0.1 Miss messages/sec allowed -- too low once real user count grows
[HUAWEI] undo arp miss anti-attack rate-limit
<HUAWEI> system-view
[HUAWEI] diagnose
[HUAWEI-diagnose] display arp fast-reply statistics
Slot Received request Sent reply
2 0 0
// Received request stuck at 0 -> request never arrived, not an ARP fault
<HUAWEI> display stp
Protocol Status :enabled
// STP not yet converged can look exactly like a learning failure
[HUAWEI] stp disableOnce the two branches above have told you which family you're in, these six account for most of what's actually wrong.
SYMPTOMAn entire segment loses internet access at once, and the MAC address associated with the gateway's IP suddenly looks unfamiliar.
CAUSEAn attacker on the same broadcast domain sends a gratuitous ARP claiming the gateway's own IP address. Hosts that accept it overwrite their real gateway MAC with the attacker's, and every packet meant for the gateway goes to the attacker instead.
FIXConfirm the gateway genuinely lives on this device with display arp / display ip routing-table for the gateway IP, then enable arp anti-attack gateway-duplicate enable and arp gratuitous-arp send enable so the device keeps refreshing the correct entry on its own schedule.
[Router] interface Vlanif10
[Router-Vlanif10] arp anti-attack gateway-duplicate enable
[Router-Vlanif10] arp gratuitous-arp send enable
<Router> display arp anti-attack gateway-duplicate itemSYMPTOMOne specific user's network drops with no link or routing problem, while everything else on the same segment stays fine.
CAUSEAn attacker forges ARP packets that appear to come from another legitimate host, overwriting that host's real entry on the gateway with the attacker's MAC address.
FIXEnable arp anti-attack entry-check on the access interface — send-ack revalidates with an actual ARP exchange before accepting a change, fixed-mac locks the MAC once learned. Clear the poisoned entry first with reset arp interface before turning the feature on.
<Router> display current-configuration | include arp anti-attack entry-check
<Router> reset arp interface GigabitEthernet0/0/1
[Router-GigabitEthernet0/0/1] arp anti-attack entry-check send-ack enableSYMPTOMDevice CPU usage spikes, normal users can't learn ARP or reach the internet, and even managing the box itself becomes slow or drops.
CAUSEA flood of ARP or unreachable-destination packets triggers ARP Miss and ARP-Request generation at a scale the CPCAR limiter wasn't sized for, so legitimate ARP traffic gets discarded in the same bucket as the attack traffic.
FIXConfirm with display cpu-defend statistics packet-type arp-request all that Dropped is climbing fast, then trace the source with an auto-defend attack-source policy before blacklisting anything — never before identifying it, since the gateway's own MAC can turn up in the same attack-source table.
<HUAWEI> display arp
10.1.1.2 Incomplete 0 D Vlanif20
// Incomplete entries under heavy CPU load -> check the drop counter next
[HUAWEI] cpu-defend policy policy1
[HUAWEI-cpu-defend-policy-policy1] auto-defend enable
[HUAWEI-cpu-defend-policy-policy1] undo auto-defend protocol dhcp dhcpv6 dns icmp icmpv6 nd igmp mld tcp tcpv6 telnet
// keep only ARP under attack-source tracing for this caseSYMPTOMA Layer-2 device sits between the terminals and the gateway, and hosts behind it can't reach the gateway even though nothing on the wire looks wrong.
CAUSEarp miss anti-attack rate-limit was set to a value that made sense on a smaller network but throttles legitimate Miss messages once the user count grows — the field-case example, maximum 16384, worked out to roughly one Miss message every ten seconds.
FIXCompare display cpu-defend statistics all's Dropped counters for arp-miss and arp-request against the real user count, and either raise the limit or remove it if it was never sized against actual traffic.
<HUAWEI> display cpu-defend statistics all
arp-miss 135576021 1601690 2022-03-31 13:17:49
[HUAWEI] display this | include arp miss anti-attack rate-limit
arp miss anti-attack rate-limit maximum 16384
[HUAWEI] undo arp miss anti-attack rate-limitSYMPTOMOne device shows a correct entry for its neighbor, but the neighbor never learns the reverse entry — traffic works in one direction and not the other.
CAUSEARP fast-reply is enabled by default, but if the peer never receives the request, or receives it and simply doesn't answer, the reverse entry is never generated.
FIXOn the peer, watch display arp fast-reply statistics from the diagnose view across several samples — Received request stuck at zero means the request never arrived; Received request moving but Sent reply not moving means the peer itself isn't answering and needs deeper investigation.
<HUAWEI> system-view
[HUAWEI] diagnose
[HUAWEI-diagnose] display arp fast-reply statistics
Status: Enable
Slot Received request Sent reply
2 0 0SYMPTOMPing between two devices fails at first and then starts working a short while later, with no configuration change in between.
CAUSESpanning Tree hasn't finished converging on this segment yet; ARP requests sent while a port is still in a blocking or listening state don't get through until the topology settles.
FIXCheck display stp for Protocol Status: enabled, and if STP isn't actually needed on this segment, disable it with stp disable rather than troubleshoot it as an ARP fault.
<HUAWEI> display stp
Protocol Status :enabled
[HUAWEI] stp disablePulled straight from the field — the ones worth having an answer ready for.
Not meaningfully at normal traffic volumes — entry-check and gateway-duplicate detection just add a comparison against existing state on packets that already have to be processed. The choice that actually matters is the mode: fixed-all locks every field, so relocating a host to a different port or VLAN afterward requires clearing the entry manually, where send-ack mode revalidates automatically.
No. Incomplete just means the ARP request was sent and no reply ever came back. That happens under a real attack, but it happens just as often from a genuinely unreachable host, a rate limiter dropping the reply, or a link problem — check cpu-defend statistics and the actual link status before assuming an attacker.
Check what that MAC belongs to first. The recorded attack-source table can include the gateway's own MAC or an interconnecting network device's MAC picked up as noisy legitimate traffic; blacklisting those takes down real business instead of stopping an attacker.
No, and this is exactly the split this note is about. Nothing was forging ARP traffic; the topology simply hadn't finished converging before the host tried to resolve its gateway. Disabling STP where it isn't needed is a link-layer fix, not an anti-spoofing one, and it would never have shown up in any of the attack-side counters.
They protect different targets. gateway-duplicate specifically protects the gateway's own address against a forged claim; entry-check protects other legitimate hosts' entries from being overwritten by an unrelated attacker. Enabling one doesn't cover the other.
Yes, and they solve different problems — 802.1X controls who's allowed onto the segment at all, while ARP anti-spoofing controls what an already-admitted device is allowed to claim about its own or another host's address once it's on the wire. Running both is the normal design, not a redundant one, and it's exactly what a zero-trust access model layers together.
This note is built around Huawei AR-series routers' ARP fault-classification model and anti-attack feature set — gateway-duplicate, entry-check, ARP Miss rate-limiting, attack-source tracing — plus the field cases behind them. Other vendors implement equivalent protections under different names and different default states, so always check what's already enabled before assuming a feature "should" already be catching this. It doesn't cover switch-side Dynamic ARP Inspection-style deployments in depth, or wireless-specific ARP proxy behavior on APs/ACs.
Send us the display arp / display cpu-defend statistics output and which branch you're stuck on, and we'll help you read it.