Inicio / Notas técnicas / Suplantación ARP y fallos de aprendizaje

Suplantación ARP, imitación de gateway y fallos de aprendizaje

Un host que no puede llegar a su gateway se ve igual tanto si alguien está atacando la LAN como si no. Esto es cómo distinguir rápidamente un ataque ARP falsificado o de inundación de un simple fallo de aprendizaje, los comandos display que lo confirman, y la configuración antisuplantación que cierra la brecha definitivamente.

Por Yuwen Zhang (Atlas), fundador de AtlasCommTech — 13 años de despliegues de redes de operadores y empresariales · Actualizado en julio de 2026

Por qué el mismo síntoma tiene dos causas muy distintas

Un host que no puede hacer Ping a su gateway se ve idéntico, tanto si alguien está atacando la LAN como si no hay nadie.

En los routers Huawei AR, los problemas de ARP siempre llegan al mismo punto de partida: una tabla display arp que no se ve bien — una entrada Incomplete, un host que de repente se desconecta, un gateway que parece haberse movido. El instinto es asumir un ataque. Con la misma frecuencia se trata de un límite de tasa configurado demasiado estricto, un ajuste de ARP fast-reply en el dispositivo equivocado, o una topología de Spanning Tree que aún no ha convergido — y tratar un simple error de configuración como una intrusión desperdicia tiempo persiguiendo a un atacante que nunca existió.

A continuación, la división en la que se basa esta nota — tráfico ARP falsificado o de inundación frente a un fallo de aprendizaje genuino — las comprobaciones para cada uno con los comandos exactos, la configuración antisuplantación que cierra el lado del ataque de forma definitiva, y respuestas de preguntas frecuentes de casos de campo reales.

Comprenda la división antes de tocar cualquier configuración

Las fallas de ARP se dividen en exactamente dos familias: algo está falsificando o inundando activamente tráfico ARP, o el ARP simplemente nunca se aprende.

Clasificar primero el síntoma en una de estas dos familias indica qué mitad de esta nota aplica realmente — y evita que configure defensas antisuplantación contra un problema que nunca fue un ataque.

Las etiquetas del diagrama se mantienen en inglés por claridad técnica.

Cada rama del lado del ataque sigue el mismo patrón de solución: identificar la fuente falsificada y luego cerrarla con un interruptor antiataque. Cada rama del lado del fallo de aprendizaje es un simple problema de configuración o de enlace que no tiene nada que ver con un intruso — activar funciones antisuplantación no hace nada al respecto.

Recorriendo cada rama

El mismo primer comando, display arp, lo dirige hacia una de estas dos ramas — todo lo que sigue depende de en qué familia esté realmente.

Rama A — Confirmar si realmente hay un ataque

Una entrada Incomplete no prueba por sí sola un ataque — lo que realmente lo indica es el contador de descarte de CPU-defend.

Ejecute display arp y busque entradas donde MAC ADDRESS muestre Incomplete — eso confirma un fallo de aprendizaje ARP, pero es el punto de partida compartido por ambas ramas, no una prueba de ataque por sí sola.
Ejecute display cpu-defend statistics packet-type arp-request all (o arp-reply) y observe el contador Dropped durante unos segundos. Si sube decenas o más por segundo, el limitador de tasa CPCAR está descartando paquetes ARP más rápido de lo que el tráfico normal generaría — eso es una firma de ataque, no un problema de capacidad.
Configure el rastreo de la fuente de ataque para identificar quién lo envía realmente: una política cpu-defend con auto-defend enable, luego display auto-defend attack-source para leer directamente el MAC y la IP de origen infractores.
Si la propia dirección del gateway se ve mal, revise display arp para la IP del gateway — TYPE debería mostrar I- (propiedad de la interfaz) — luego confirme que arp anti-attack gateway-duplicate enable esté configurado. Si la función ya marcó a un infractor, display arp anti-attack gateway-duplicate item muestra directamente la IP, el MAC y la interfaz de origen del atacante registrado.

<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

Rama B — Confirmar si el aprendizaje realmente tuvo alguna oportunidad

Ningún atacante en ninguna parte — solo un límite de tasa, un peer silencioso, o una topología que aún no ha terminado de converger.

Ejecute display arp miss anti-attack rate-limit para ver la tasa de supresión de Miss configurada. Una tasa configurada demasiado baja — el ejemplo de campo es arp miss anti-attack rate-limit maximum 16384, que en promedio apenas permite 0.1 mensajes Miss por segundo — limita el tráfico ARP Miss legítimo en el mismo cubo de descarte que un ataque, y se ve idéntico a uno hasta que lea este valor.
En el dispositivo peer, ejecute display arp fast-reply statistics desde la vista diagnose varias veces seguidas y observe si Received request y Sent reply realmente se mueven. Si Received request nunca aumenta, la solicitud misma nunca llegó — un problema de enlace, VLAN o reenvío aguas arriba, no un problema de ARP en absoluto. Si aumenta pero Sent reply no, el peer no está respondiendo.
Ejecute display arp statistics y compare el número de entradas con la cantidad real de usuarios conectados. Un número muy desproporcionado respecto a la base de usuarios apunta a una agitación provocada por Miss en lugar de un fallo de aprendizaje — verifique si una sola IP de origen está desencadenando ARP Miss repetidamente.
Si el Ping solo tiene éxito después de un retraso, verifique si STP sigue habilitado con display stp — una topología que no ha terminado de converger bloquea el intercambio ARP junto con todo lo demás, y deshabilitar STP donde no se necesita (stp disable) es una solución completamente distinta de cualquier cosa específica de 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 causas raíz que aparecen una y otra vez

Una vez que las dos ramas anteriores le indican en qué familia está, estas seis explican la mayor parte de lo que realmente falla.

1. Dirección del gateway suplantada mediante ARP gratuito

SÍNTOMATodo un segmento pierde acceso a internet a la vez, y la dirección MAC asociada a la IP del gateway de repente parece desconocida.

CAUSAUn atacante en el mismo dominio de difusión envía un ARP gratuito reclamando la propia IP del gateway. Los hosts que lo aceptan sobrescriben su MAC real del gateway con la del atacante, y cada paquete destinado al gateway va al atacante en su lugar.

SOLUCIÓNConfirme que el gateway realmente reside en este dispositivo con display arp / display ip routing-table para la IP del gateway, luego habilite arp anti-attack gateway-duplicate enable y arp gratuitous-arp send enable para que el dispositivo siga refrescando la entrada correcta según su propio calendario.

[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. La entrada ARP de un usuario legítimo se reescribe silenciosamente

SÍNTOMALa red de un usuario específico se cae sin ningún problema de enlace o enrutamiento, mientras que todo lo demás en el mismo segmento sigue bien.

CAUSAUn atacante falsifica paquetes ARP que parecen provenir de otro host legítimo, sobrescribiendo la entrada real de ese host en el gateway con la dirección MAC del atacante.

SOLUCIÓNHabilite arp anti-attack entry-check en la interfaz de acceso — send-ack revalida con un intercambio ARP real antes de aceptar un cambio, fixed-mac bloquea el MAC una vez aprendido. Limpie primero la entrada envenenada con reset arp interface antes de activar la función.

<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. La inundación de ARP / escaneo IP empuja la carga de CPU más allá del limitador de tasa

SÍNTOMAEl uso de la CPU del dispositivo se dispara, los usuarios normales no pueden aprender ARP ni acceder a internet, e incluso gestionar el propio equipo se vuelve lento o se cae.

CAUSAUna inundación de paquetes ARP o de destino inalcanzable desencadena la generación de ARP Miss y ARP-Request a una escala para la que el limitador CPCAR no estaba dimensionado, por lo que el tráfico ARP legítimo se descarta en el mismo cubo que el tráfico de ataque.

SOLUCIÓNConfirme con display cpu-defend statistics packet-type arp-request all que Dropped está subiendo rápido, luego rastree la fuente con una política auto-defend attack-source antes de poner algo en la lista negra — nunca antes de identificarlo, ya que el MAC del propio gateway puede aparecer en la misma tabla de fuentes de ataque.

<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. Límite de tasa de ARP Miss configurado de forma demasiado agresiva

SÍNTOMAUn dispositivo de capa 2 se encuentra entre los terminales y el gateway, y los hosts detrás de él no pueden alcanzar el gateway aunque nada en el cableado parezca estar mal.

CAUSAarp miss anti-attack rate-limit se configuró en un valor razonable para una red más pequeña, pero limita los mensajes Miss legítimos una vez que crece el número de usuarios — el ejemplo de campo, maximum 16384, equivalía a aproximadamente un mensaje Miss cada diez segundos.

SOLUCIÓNCompare los contadores Dropped de arp-miss y arp-request de display cpu-defend statistics all con el número real de usuarios, y aumente el límite o elimínelo si nunca se dimensionó en función del tráfico real.

<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. El peer nunca envía la respuesta rápida

SÍNTOMAUn dispositivo muestra una entrada correcta para su vecino, pero el vecino nunca aprende la entrada inversa — el tráfico funciona en una dirección y no en la otra.

CAUSAEl ARP fast-reply está habilitado por defecto, pero si el peer nunca recibe la solicitud, o la recibe y simplemente no responde, la entrada inversa nunca se genera.

SOLUCIÓNEn el peer, observe display arp fast-reply statistics desde la vista diagnose en varias muestras — Received request estancado en cero significa que la solicitud nunca llegó; Received request moviéndose pero Sent reply sin moverse significa que el propio peer no está respondiendo y necesita una investigación más profunda.

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

6. La convergencia de STP retrasa el ARP — no es una falla de ARP en absoluto

SÍNTOMAEl Ping entre dos dispositivos falla al principio y luego empieza a funcionar poco después, sin ningún cambio de configuración de por medio.

CAUSAEl Spanning Tree aún no ha terminado de converger en este segmento; las solicitudes ARP enviadas mientras un puerto sigue en estado blocking o listening no pasan hasta que la topología se estabiliza.

SOLUCIÓNVerifique display stp para Protocol Status: enabled, y si STP no es realmente necesario en este segmento, desactívelo con stp disable en lugar de solucionarlo como una falla de ARP.

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

Seis preguntas que surgen constantemente

Sacadas directamente del campo — las que merece la pena tener una respuesta lista.

¿Habilitar la antisuplantación ARP en cada interfaz ralentiza algo?

No de forma significativa con volúmenes de tráfico normales — la detección de entry-check y gateway-duplicate solo añade una comparación con el estado existente en paquetes que ya deben procesarse. La elección que realmente importa es el modo: fixed-all bloquea cada campo, por lo que reubicar un host a otro puerto o VLAN después requiere borrar la entrada manualmente, mientras que el modo send-ack revalida automáticamente.

display arp muestra entradas Incomplete — ¿siempre es un ataque?

No. Incomplete solo significa que la solicitud ARP se envió y nunca llegó respuesta. Eso ocurre en un ataque real, pero ocurre igual de a menudo por un host genuinamente inalcanzable, una respuesta descartada por un limitador de tasa, o un problema de enlace — verifique cpu-defend statistics y el estado real del enlace antes de asumir un atacante.

El rastreo de fuente de ataque marcó una dirección MAC — ¿es seguro ponerla en la lista negra de inmediato?

Primero verifique a qué pertenece ese MAC. La tabla de fuentes de ataque registrada puede incluir el propio MAC del gateway o el de un dispositivo de red de interconexión captado como tráfico legítimo ruidoso; ponerlos en la lista negra derriba negocio real en lugar de detener a un atacante.

Deshabilitamos STP y el problema intermitente de Ping desapareció — ¿STP era en realidad el "atacante"?

No, y esto es exactamente la división de la que trata esta nota. Nada estaba falsificando tráfico ARP; la topología simplemente no había terminado de converger antes de que el host intentara resolver su gateway. Deshabilitar STP donde no se necesita es una solución de capa de enlace, no antisuplantación, y nunca habría aparecido en ninguno de los contadores del lado del ataque.

gateway-duplicate y entry-check parecen hacer algo similar — ¿necesitamos ambos?

Protegen objetivos diferentes. gateway-duplicate protege específicamente la propia dirección del gateway contra una reclamación falsificada; entry-check protege las entradas de otros hosts legítimos de ser sobrescritas por un atacante no relacionado. Habilitar una no cubre a la otra.

¿Estas funciones antiataque de ARP pueden funcionar junto con el control de admisión 802.1X/NAC?

Sí, y resuelven problemas diferentes — 802.1X controla quién puede acceder al segmento en absoluto, mientras que la antisuplantación ARP controla lo que un dispositivo ya admitido puede reclamar sobre su propia dirección o la de otro host una vez en el cable. Ejecutar ambos es el diseño normal, no redundante, y es exactamente lo que un modelo de acceso de confianza cero superpone en conjunto.

Límites honestos de esta nota

Límites honestos de esta nota

Esta nota se basa en el modelo de clasificación de fallas de ARP de los routers Huawei serie AR y su conjunto de funciones antiataque — gateway-duplicate, entry-check, limitación de tasa de ARP Miss, rastreo de fuente de ataque — además de los casos de campo que los respaldan. Otros fabricantes implementan protecciones equivalentes bajo nombres diferentes y con estados predeterminados distintos, así que siempre verifique qué está ya habilitado antes de asumir que una función "debería" ya estar capturando esto. No cubre en profundidad despliegues estilo Dynamic ARP Inspection del lado del switch, ni el comportamiento de proxy ARP específico inalámbrico en APs/ACs.

¿No está seguro si es un atacante o una configuración?

Envíenos la salida de display arp / display cpu-defend statistics y en qué rama está atascado, y le ayudamos a interpretarla.

WhatsApp con un ingeniero →