Accueil / Notes techniques / Usurpation ARP et échecs d'apprentissage

Usurpation ARP, imitation de passerelle et échecs d'apprentissage

Un hôte incapable d'atteindre sa passerelle se présente de la même façon, qu'il y ait ou non une attaque sur le LAN. Voici comment distinguer rapidement une attaque ARP forgée ou en inondation d'un simple échec d'apprentissage, les commandes display qui tranchent, et la configuration anti-usurpation qui referme durablement la faille.

Par Yuwen Zhang (Atlas), fondateur d'AtlasCommTech — 13 ans de déploiements de réseaux opérateurs et d'entreprise · Mis à jour en juillet 2026

Pourquoi le même symptôme a deux causes très différentes

Un hôte qui ne peut pas faire de Ping vers sa passerelle a l'air identique, qu'il y ait une attaque sur le LAN ou pas du tout.

Sur les routeurs Huawei AR, les problèmes ARP aboutissent tous au même point de départ : une table display arp qui n'a pas l'air normale — une entrée Incomplete, un hôte qui disparaît soudainement du réseau, une passerelle qui semble avoir changé. Le réflexe est de présumer une attaque. Tout aussi souvent, il s'agit d'une limite de débit trop stricte, d'un réglage ARP fast-reply sur le mauvais appareil, ou d'une topologie Spanning Tree qui n'a pas encore convergé — et traiter une simple erreur de configuration comme une intrusion fait perdre du temps à traquer un attaquant qui n'a jamais existé.

Voici la distinction sur laquelle repose cette note — trafic ARP forgé ou en inondation par opposition à un véritable échec d'apprentissage — les vérifications pour chacun avec les commandes exactes, la configuration anti-usurpation qui referme durablement le côté attaque, et des réponses de FAQ tirées de cas de terrain.

Comprenez la distinction avant de toucher à la configuration

Les pannes ARP se répartissent en exactement deux familles : quelque chose forge ou inonde activement du trafic ARP, ou l'ARP n'est tout simplement jamais appris.

Classer d'abord le symptôme dans l'une de ces deux familles indique quelle moitié de cette note s'applique réellement — et vous évite de configurer des défenses anti-usurpation contre un problème qui n'a jamais été une attaque.

Les légendes du schéma restent en anglais pour la clarté technique.

Chaque branche du côté attaque suit le même schéma de correction : identifier la source forgée, puis la fermer avec un commutateur anti-attaque. Chaque branche du côté échec d'apprentissage est un simple problème de configuration ou de liaison qui n'a rien à voir avec un intrus — activer des fonctions anti-usurpation n'y change rien.

Parcourir chaque branche

La même première commande, display arp, vous oriente vers l'une de ces deux branches — tout ce qui suit dépend de la famille dans laquelle vous êtes réellement.

Branche A — Confirmer si une attaque a réellement lieu

Une entrée Incomplete ne prouve pas à elle seule une attaque — c'est le compteur de rejet CPU-defend qui vous renseigne réellement.

Exécutez display arp et repérez les entrées où MAC ADDRESS affiche Incomplete — cela confirme un échec d'apprentissage ARP, mais c'est le point de départ commun aux deux branches, pas la preuve d'une attaque en soi.
Exécutez display cpu-defend statistics packet-type arp-request all (ou arp-reply) et observez le compteur Dropped sur quelques secondes. S'il augmente de dizaines ou plus par seconde, le limiteur de débit CPCAR rejette des paquets ARP plus vite qu'un trafic normal n'en générerait jamais — c'est une signature d'attaque, pas un problème de capacité.
Configurez le traçage de la source d'attaque pour identifier qui l'envoie réellement : une politique cpu-defend avec auto-defend enable, puis display auto-defend attack-source pour relire directement le MAC et l'IP source fautifs.
Si l'adresse de la passerelle elle-même semble incorrecte, vérifiez display arp pour l'IP de la passerelle — TYPE devrait afficher I- (propriété de l'interface) — puis confirmez que arp anti-attack gateway-duplicate enable est configuré. Si la fonction a déjà signalé un fautif, display arp anti-attack gateway-duplicate item affiche directement l'IP, le MAC et l'interface source de l'attaquant enregistré.

<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 blacklisting

Branche B — Confirmer si l'apprentissage avait une chance de réussir

Aucun attaquant nulle part — juste une limite de débit, un pair silencieux, ou une topologie qui n'a pas fini de converger.

Exécutez display arp miss anti-attack rate-limit pour voir le taux de suppression Miss configuré. Un taux trop bas — l'exemple de terrain est arp miss anti-attack rate-limit maximum 16384, qui revient à peine à 0,1 message Miss par seconde en moyenne — limite le trafic ARP Miss légitime dans le même seau de rejet qu'une attaque, et lui ressemble en tout point jusqu'à ce que vous lisiez cette valeur.
Sur l'appareil pair, exécutez display arp fast-reply statistics depuis la vue diagnose plusieurs fois de suite et observez si Received request et Sent reply évoluent réellement. Si Received request n'augmente jamais, la requête elle-même n'est jamais arrivée — un problème de liaison, de VLAN ou de transfert en amont, pas du tout un problème ARP. Si elle augmente mais que Sent reply non, le pair ne répond pas.
Exécutez display arp statistics et comparez le nombre d'entrées au nombre réel d'utilisateurs connectés. Un nombre totalement disproportionné par rapport à la base d'utilisateurs indique une agitation déclenchée par Miss plutôt qu'un échec d'apprentissage — vérifiez si une seule adresse IP source déclenche l'ARP Miss de façon répétée.
Si le Ping ne réussit qu'après un délai, vérifiez si STP est encore activé avec display stp — une topologie qui n'a pas fini de converger bloque l'échange ARP avec tout le reste, et désactiver STP là où il n'est pas nécessaire (stp disable) est une solution complètement différente de tout ce qui est spécifique à l'ARP.

<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 disable

6 causes racines qui reviennent sans cesse

Une fois que les deux branches ci-dessus vous ont indiqué votre famille, ces six causes couvrent l'essentiel du problème réel.

1. Adresse de passerelle usurpée via un ARP gratuit

SYMPTÔMETout un segment perd l'accès à internet d'un coup, et l'adresse MAC associée à l'IP de la passerelle semble soudain inconnue.

CAUSEUn attaquant sur le même domaine de diffusion envoie un ARP gratuit revendiquant l'IP même de la passerelle. Les hôtes qui l'acceptent écrasent leur véritable MAC de passerelle par celui de l'attaquant, et chaque paquet destiné à la passerelle va à l'attaquant à la place.

SOLUTIONConfirmez que la passerelle réside bien sur cet appareil avec display arp / display ip routing-table pour l'IP de la passerelle, puis activez arp anti-attack gateway-duplicate enable et arp gratuitous-arp send enable pour que l'appareil continue de rafraîchir la bonne entrée selon son propre calendrier.

[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 item

2. L'entrée ARP d'un utilisateur légitime est réécrite en silence

SYMPTÔMELe réseau d'un utilisateur spécifique tombe en panne sans aucun problème de liaison ou de routage, tandis que tout le reste sur le même segment reste normal.

CAUSEUn attaquant forge des paquets ARP qui semblent provenir d'un autre hôte légitime, écrasant la véritable entrée de cet hôte sur la passerelle par l'adresse MAC de l'attaquant.

SOLUTIONActivez arp anti-attack entry-check sur l'interface d'accès — send-ack revalide par un véritable échange ARP avant d'accepter un changement, fixed-mac verrouille le MAC une fois appris. Effacez d'abord l'entrée empoisonnée avec reset arp interface avant d'activer la fonction.

<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 enable

3. L'inondation ARP / scan IP pousse la charge CPU au-delà du limiteur de débit

SYMPTÔMEL'utilisation du CPU de l'appareil s'envole, les utilisateurs normaux ne peuvent plus apprendre l'ARP ni accéder à internet, et même la gestion de l'appareil devient lente ou se coupe.

CAUSEUne inondation de paquets ARP ou de destination inaccessible déclenche une génération d'ARP Miss et d'ARP-Request à une échelle pour laquelle le limiteur CPCAR n'était pas dimensionné, si bien que le trafic ARP légitime est rejeté dans le même seau que le trafic d'attaque.

SOLUTIONConfirmez avec display cpu-defend statistics packet-type arp-request all que Dropped augmente rapidement, puis retracez la source avec une politique auto-defend attack-source avant de mettre quoi que ce soit en liste noire — jamais avant identification, car le MAC de la passerelle elle-même peut apparaître dans la même table de sources d'attaque.

<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 case

4. Limite de débit ARP Miss configurée trop agressivement

SYMPTÔMEUn appareil de couche 2 se trouve entre les terminaux et la passerelle, et les hôtes derrière lui ne peuvent pas atteindre la passerelle bien que rien sur le câble ne semble anormal.

CAUSEarp miss anti-attack rate-limit a été réglé sur une valeur logique pour un petit réseau, mais elle limite les messages Miss légitimes une fois que le nombre d'utilisateurs augmente — l'exemple de terrain, maximum 16384, équivalait à environ un message Miss toutes les dix secondes.

SOLUTIONComparez les compteurs Dropped d'arp-miss et arp-request de display cpu-defend statistics all au nombre réel d'utilisateurs, et augmentez la limite ou supprimez-la si elle n'a jamais été dimensionnée en fonction du trafic réel.

<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-limit

5. Le pair n'envoie jamais la réponse rapide

SYMPTÔMEUn appareil affiche une entrée correcte pour son voisin, mais le voisin n'apprend jamais l'entrée inverse — le trafic fonctionne dans un sens et pas dans l'autre.

CAUSEL'ARP fast-reply est activé par défaut, mais si le pair ne reçoit jamais la requête, ou la reçoit sans y répondre, l'entrée inverse n'est jamais générée.

SOLUTIONSur le pair, observez display arp fast-reply statistics depuis la vue diagnose sur plusieurs échantillons — Received request bloqué à zéro signifie que la requête n'est jamais arrivée ; Received request qui bouge mais Sent reply qui ne bouge pas signifie que le pair lui-même ne répond pas et nécessite une investigation plus poussée.

<HUAWEI> system-view
[HUAWEI] diagnose
[HUAWEI-diagnose] display arp fast-reply statistics
Status: Enable
Slot   Received request   Sent reply
2      0                  0

6. La convergence STP retarde l'ARP — ce n'est pas du tout une panne ARP

SYMPTÔMELe Ping entre deux appareils échoue d'abord puis commence à fonctionner peu après, sans aucun changement de configuration entre-temps.

CAUSELe Spanning Tree n'a pas encore fini de converger sur ce segment ; les requêtes ARP envoyées alors qu'un port est encore en état blocking ou listening ne passent pas tant que la topologie ne s'est pas stabilisée.

SOLUTIONVérifiez display stp pour Protocol Status: enabled, et si STP n'est pas réellement nécessaire sur ce segment, désactivez-le avec stp disable plutôt que de le dépanner comme une panne ARP.

<HUAWEI> display stp
Protocol Status        :enabled
[HUAWEI] stp disable

Six questions qui reviennent sans cesse

Tirées directement du terrain — celles pour lesquelles il vaut la peine d'avoir une réponse prête.

Activer l'anti-usurpation ARP sur chaque interface ralentit-il quoi que ce soit ?

Pas de manière significative aux volumes de trafic normaux — la détection entry-check et gateway-duplicate ajoute simplement une comparaison avec l'état existant sur des paquets qui doivent déjà être traités. Le choix qui compte vraiment est le mode : fixed-all verrouille chaque champ, donc déplacer un hôte vers un autre port ou VLAN par la suite exige d'effacer l'entrée manuellement, alors que le mode send-ack revalide automatiquement.

display arp affiche des entrées Incomplete — est-ce toujours une attaque ?

Non. Incomplete signifie simplement que la requête ARP a été envoyée et qu'aucune réponse n'est jamais revenue. Cela arrive lors d'une véritable attaque, mais tout aussi souvent à cause d'un hôte réellement inaccessible, d'une réponse rejetée par un limiteur de débit, ou d'un problème de liaison — vérifiez cpu-defend statistics et l'état réel de la liaison avant de présumer un attaquant.

Le traçage de source d'attaque a signalé une adresse MAC — est-il sûr de la mettre immédiatement en liste noire ?

Vérifiez d'abord à quoi appartient ce MAC. La table de sources d'attaque enregistrée peut inclure le MAC de la passerelle elle-même ou celui d'un appareil réseau d'interconnexion capté comme trafic légitime bruyant ; les mettre en liste noire coupe des activités réelles au lieu d'arrêter un attaquant.

Nous avons désactivé STP et le problème de Ping intermittent a disparu — STP était-il en fait l'« attaquant » ?

Non, et c'est exactement la distinction dont traite cette note. Rien ne forgeait du trafic ARP ; la topologie n'avait simplement pas fini de converger avant que l'hôte n'essaie de résoudre sa passerelle. Désactiver STP là où il n'est pas nécessaire est une correction de couche liaison, pas une correction anti-usurpation, et cela ne serait jamais apparu dans aucun des compteurs côté attaque.

gateway-duplicate et entry-check semblent faire quelque chose de similaire — avons-nous besoin des deux ?

Elles protègent des cibles différentes. gateway-duplicate protège spécifiquement l'adresse de la passerelle elle-même contre une revendication forgée ; entry-check protège les entrées des autres hôtes légitimes d'être écrasées par un attaquant sans rapport. Activer l'une ne couvre pas l'autre.

Ces fonctions anti-attaque ARP peuvent-elles fonctionner avec le contrôle d'admission 802.1X/NAC ?

Oui, et elles résolvent des problèmes différents — 802.1X contrôle qui est autorisé à accéder au segment du tout, tandis que l'anti-usurpation ARP contrôle ce qu'un appareil déjà admis est autorisé à revendiquer sur sa propre adresse ou celle d'un autre hôte une fois sur le câble. Faire fonctionner les deux est la conception normale, pas redondante, et c'est exactement ce qu'un modèle d'accès Zero Trust superpose ensemble.

Limites honnêtes de cette note

Limites honnêtes de cette note

Cette note s'appuie sur le modèle de classification des pannes ARP des routeurs Huawei série AR et son ensemble de fonctions anti-attaque — gateway-duplicate, entry-check, limitation de débit ARP Miss, traçage de source d'attaque — ainsi que sur les cas de terrain qui les sous-tendent. D'autres fournisseurs mettent en œuvre des protections équivalentes sous des noms différents et avec des états par défaut différents, donc vérifiez toujours ce qui est déjà activé avant de présumer qu'une fonction « devrait » déjà intercepter ceci. Elle ne couvre pas en profondeur les déploiements de type Dynamic ARP Inspection côté commutateur, ni le comportement de proxy ARP spécifique au sans-fil sur les AP/AC.

Vous ne savez pas si c'est un attaquant ou une configuration ?

Envoyez-nous la sortie de display arp / display cpu-defend statistics et la branche sur laquelle vous êtes bloqué, et nous vous aiderons à l'interpréter.

WhatsApp avec un ingénieur →