Cómo Configurar Dynamic ARP Inspection en Cisco Catalyst

Dynamic ARP Inspection (DAI) es la característica de seguridad L2 que valida cada paquete ARP contra una base de datos confiable y descarta los que tienen bindings IP–MAC inválidos. Es la defensa estándar de Cisco contra ataques de ARP spoofing dentro del dominio de broadcast, y forma parte del objetivo 5.7 del examen CCNA 200-301 v1.1 — Configure Layer 2 security features: DHCP snooping, dynamic ARP inspection, port security.

En este artículo explico cómo configurar DAI paso a paso en un switch Cisco Catalyst 9300 con IOS-XE 17.x, incluyendo DHCP snooping como prerrequisito, las validaciones opcionales, el rate limiting, los comandos de verificación y los problemas comunes que vas a encontrar al implementarlo en una red real. El recorrido sigue el flujo lógico que necesitas dominar para el examen y para entornos de producción.

Topología del laboratorio

Todos los ejemplos de configuración, capturas y logs de este artículo se basan en la siguiente topología sobre Cisco IOS-XE 17.x según la guía oficial Cisco para Catalyst 9300, alineada con las plataformas de referencia del examen CCNA 200-301 v1.1.

Las direcciones MAC se muestran en notación Cisco IOS (xxxx.xxxx.xxxx), que es la que aparece en los outputs reales de los comandos show del switch.

Topología:

• Todos los dispositivos pertenecen a la VLAN 1 y a la red 192.168.1.0/24.
• GATEWAY actúa como servidor DHCP autorizado.
• H1 y ATTACKER reciben su IP por DHCP desde GATEWAY.
• En SW (Catalyst 9300), el puerto Gi1/0/47 (uplink al GATEWAY) es el único trusted tanto en DHCP snooping como en DAI. Los puertos Gi1/0/1 y Gi1/0/13 permanecen untrusted por defecto.

Nota: en redes reales se evita usar VLAN 1 por seguridad y se segmentan los hosts en VLANs dedicadas. Esta simplificación se mantiene aquí únicamente para el laboratorio.

Qué es Dynamic ARP Inspection

Dynamic ARP Inspection (DAI) es una función de seguridad de inspección en ingreso (ingress) que valida paquetes ARP comparando bindings IP–MAC contra una base de datos confiable (binding table de DHCP snooping, ARP ACLs o bindings estáticos) antes de permitir su reenvío.

DAI mitiga ataques de ARP spoofing dentro de un dominio de broadcast L2, pero no los elimina por completo, ya que solo inspecciona tráfico en puertos untrusted y VLANs donde está habilitado, y no aplica verificación en puertos marcados como trusted ni en tráfico de salida (egress).

DAI está diseñado para regular las solicitudes ARP, es decir, decide cuáles dejar pasar y cuáles descartar. Su funcionamiento se basa en:

• Comprobar si la “IP / MAC de origen” del paquete ARP recibido es correcta.
• Determinar la validez consultando la binding table de DHCP snooping (o, alternativamente, una ARP ACL o bindings estáticos).
• Descartar los paquetes ARP no autorizados.

El problema: cómo funciona un ataque ARP spoofing

El protocolo ARP definido en el RFC 826 no incluye autenticación: no hay verificación de la autenticidad de las solicitudes y, además, es posible el envío de respuestas ARP sin solicitudes ARP previas — esto es el llamado gratuitous-ARP. Cuando un atacante ejecuta un ataque ARP spoofing y falsifica un ARP Reply enviando “el gateway es mi dirección MAC”:

• La comunicación del terminal se dirige al atacante (ataque MITM — Man In The Middle).
• Es posible la interceptación, alteración y secuestro de sesiones.
• Se convierte en una causa de retraso en la red e interrupción de la comunicación.

Demostración práctica del ataque

En el laboratorio descrito arriba, el ATTACKER (Gi1/0/1, 192.168.1.10) ejecuta Cain & Abel para envenenar la tabla ARP del host H1 (Gi1/0/13, 192.168.1.50), suplantando al GATEWAY (192.168.1.1).

Antes del ataque, reviso las tablas ARP en el host H1 y en el ATTACKER. Luego inicio Cain & Abel, activo el sniffer y añado todos los hosts del dominio de difusión. Después paso a la pestaña ARP, presiono + y selecciono la dirección del gateway y el host desde el cual interceptaré el tráfico. Presiono el botón ARP-poisoning y el proceso de modificación de la tabla ARP en el host H1 se ha iniciado.

Al revisar de nuevo la tabla ARP en H1, observo la suplantación de la dirección MAC para la IP 192.168.1.1.

Ahora en el host H1 inicio putty e intento entrar al GATEWAY a través del protocolo inseguro telnet. Debido a que el protocolo telnet transmite los datos en plain text, en el sniffer del atacante se verá toda la información necesaria, es decir, el login y la contraseña.

Tras ingresar el login/password y la contraseña enable, en el ATTACKER abro el sniffer en la pestaña Passwords. Se ve que se capturó la información:

============================================
=== Cain's Telnet sniffer generated file ===
============================================
User Access Verification
Username: admin
Password: cisco
Router>enable
Password: Cisco

Listo. La contraseña de telnet ha sido interceptada.

DHCP snooping: prerrequisito de Dynamic ARP Inspection

Por qué es necesario DHCP snooping

DHCP snooping es una función de seguridad que evita la distribución de direcciones IP desde servidores DHCP no autorizados dentro de la red.

Si existe un servidor DHCP no autorizado en la red, a los terminales se les asignará un Default Gateway o DNS incorrecto, lo que causará problemas como los siguientes:

• No se puede conectar a la red.
• Las comunicaciones se interceptan a través de un gateway especificado por el atacante (ataque MITM).
• No se puede acceder a los sistemas internos.

En la topología del lab, el GATEWAY (Cisco ISR 4321) es el servidor DHCP autorizado. Si el ATTACKER decidiera levantar en su computadora un servidor DHCP y repartir direcciones falsas, DHCP snooping descartará las respuestas DHCP provenientes de su puerto (Gi1/0/1, untrusted).

Funcionamiento de DHCP snooping

Todo es muy sencillo. Existen puertos Untrusted y Trusted:

• Como puerto confiable se asigna el puerto que conduce al servidor DHCP autorizado (en el lab, Gi1/0/47 hacia el GATEWAY).
• Todos los demás puertos serán no confiables y las respuestas DHCP provenientes de ellos serán descartadas.

Funcionamiento detallado:

• Monitorea los mensajes DHCP y distingue entre puertos confiables (trusted) y puertos no autorizados (untrusted).
• Registra la información de IP / MAC / VLAN / puerto distribuida a los terminales como una binding table.
• Descarta los DHCP Offer / ACK no autorizados para prevenir ataques.

La binding table desempeña un papel importante en el Dynamic ARP Inspection. Hay que tener cuidado con esta dependencia: por defecto DAI utiliza la binding table de DHCP snooping para validar los bindings IP–MAC, pero también puede operar sin DHCP snooping mediante ARP ACLs o bindings estáticos, lo cual es relevante en entornos con direccionamiento IP estático. No entender estas alternativas puede causar problemas durante la implementación.

Configuración de DHCP snooping en el lab

Activo en el switch SW (Catalyst 9300) la función DHCP snooping para la VLAN 1:

SW(config)# ip dhcp snooping
SW(config)# ip dhcp snooping vlan 1
SW(config)# ip dhcp snooping database flash:/dhcp-snoop.db

Sintaxis genérica: para activar DHCP snooping en múltiples VLANs (por ejemplo 10 y 20), se usaría ip dhcp snooping vlan 10,20.

En el puerto que mira hacia el GATEWAY (servidor DHCP autorizado):

SW(config)# interface GigabitEthernet1/0/47
SW(config-if)# ip dhcp snooping trust

Los puertos Gi1/0/1 (ATTACKER) y Gi1/0/13 (H1) son “untrusted” por defecto, por lo que no se requiere configuración adicional en ellos.

Verificación del estado:

SW# show ip dhcp snooping
Switch DHCP snooping is enabled
DHCP snooping is configured on following VLANs:
1
DHCP snooping is configured on the following Interfaces:
Insertion of option 82 is enabled
circuit-id format: vlan-mod-port
remote-id format: MAC
Option 82 on untrusted port is not allowed
Verification of hwaddr field is enabled
Interface                Trusted    Rate limit (pps)
-----------------------  --------   ----------------
GigabitEthernet1/0/47    yes        unlimited

Verificación de la binding table:

SW# show ip dhcp snooping binding
MacAddress          IpAddress       Lease(sec)  Type            VLAN  Interface
------------------  --------------  ----------  --------------  ----  -----------------------
50b7.c378.b41a      192.168.1.10    69421       dhcp-snooping   1     GigabitEthernet1/0/1
e803.9abe.0cd8      192.168.1.50    26268       dhcp-snooping   1     GigabitEthernet1/0/13
Total number of bindings: 2

Como se ve, las MAC 50b7.c378.b41a y e803.9abe.0cd8 corresponden a ATTACKER y H1 respectivamente, según la topología del laboratorio. Sobre la base de esta binding table funcionará el mecanismo Dynamic ARP Inspection.

Configurar Dynamic ARP Inspection paso a paso

Activar DAI por VLAN

En el switch Cisco, esta herramienta se activa para cada VLAN por separado. En el lab, todos los hosts están en la VLAN 1:

SW(config)# ip arp inspection vlan 1

Sintaxis genérica: para activar DAI en múltiples VLANs simultáneamente, ip arp inspection vlan 10,20.

Definir puertos trusted y untrusted

En DAI para los puertos del switch existen dos configuraciones: Trusted y Untrusted. Por defecto, todos los puertos del switch son Untrusted, es decir, no confiables.

El puerto que va al gateway o el puerto en el que está conectado por trunk otro switch se puede hacer Trusted; entonces las solicitudes ARP que lleguen a través de él se considerarán confiables. En el lab, marco como trusted el uplink al GATEWAY:

SW(config)# interface GigabitEthernet1/0/47
SW(config-if)# ip arp inspection trust

Los puertos de los hosts (Gi1/0/1 y Gi1/0/13) permanecen untrusted, que es lo deseado.

Validaciones opcionales (src-mac, dst-mac, ip)

Por defecto, DAI valida los paquetes ARP únicamente contra la binding table de DHCP snooping (correspondencia IP ↔ MAC ↔ VLAN ↔ puerto). Sin embargo, esta validación básica no inspecciona el contenido del frame Ethernet ni del payload ARP en profundidad. Estas validaciones adicionales están deshabilitadas por defecto y deben configurarse explícitamente.

Sintaxis del comando (notación de la guía oficial Cisco IOS-XE 17.x para Catalyst 9000):

SW(config)# ip arp inspection validate {[src-mac] [dst-mac] [ip]}

Comando ejecutable en el CLI (lo que se teclea realmente — sin las llaves, que son notación de manual):

SW(config)# ip arp inspection validate src-mac dst-mac ip

Las tres opciones de validación son:

• src-mac → compara la dirección MAC de origen del encabezado Ethernet contra la dirección MAC del emisor (sender) dentro del payload ARP. Si no coinciden, el paquete se descarta. Detecta paquetes ARP en los que el atacante manipula el sender MAC del payload pero deja la MAC real en el frame Ethernet (o viceversa). Aplica tanto a ARP requests como a ARP replies.
• dst-mac → compara la dirección MAC de destino del encabezado Ethernet contra la dirección MAC del destinatario (target) dentro del payload ARP. Aplica únicamente a ARP replies.
• ip → verifica que las direcciones IP dentro del payload ARP no sean inválidas o inesperadas. Descarta paquetes con 0.0.0.0, 255.255.255.255 o direcciones IP multicast en los campos sender/target. Aplica a requests (sender IP) y replies (sender y target IP).

Las opciones se pueden combinar en un único comando. Por defecto no se realiza ninguna validación adicional, y si se configura el comando ip arp inspection validate, se debe especificar al menos una opción. Cada ejecución del comando reemplaza la configuración previa (no es acumulativo).

Verificación del estado:

SW# show ip arp inspection

En el output, las líneas Source Mac Validation, Destination Mac Validation y IP Address Validation indicarán Enabled o Disabled según corresponda.

Rate limiting de ARP en puertos untrusted

Aunque DAI descarta los paquetes ARP no autorizados, un atacante puede inundar el switch con ARPs falsificados para saturar la CPU (el procesamiento de DAI ocurre en software). Para proteger la CPU del switch frente a ataques de inundación ARP, DAI incorpora un mecanismo de rate limiting que limita la tasa de paquetes ARP por segundo (pps) en cada puerto.

Comportamiento por defecto:

• Puertos untrusted → límite por defecto de 15 pps.
• Puertos trusted → sin límite (unlimited).
• Cuando un puerto excede el rate limit configurado, el switch coloca la interfaz en estado err-disabled, bloqueando el tráfico hasta intervención manual o recuperación automática configurada.

Configuración del límite por puerto (en el lab, podríamos endurecer el límite del puerto del ATTACKER):

SW(config)# interface GigabitEthernet1/0/1
SW(config-if)# ip arp inspection limit rate <pps> [burst interval <segundos>]

• rate <pps> → paquetes ARP por segundo permitidos (rango 0–2048).
• burst interval → ventana en segundos sobre la cual se mide el rate (1–15 segundos, por defecto 1).

Ejemplo: permitir hasta 100 ARPs por segundo medidos sobre una ventana de 2 segundos:

SW(config-if)# ip arp inspection limit rate 100 burst interval 2

Para deshabilitar el límite en un puerto específico (por ejemplo, un uplink confiable):

SW(config-if)# ip arp inspection limit none

Auto-recuperación con errdisable recovery

Activo además una verificación adicional de DAI:

SW(config)# errdisable recovery cause arp-inspection

Esta opción permite recuperar el puerto del estado errdisabled después de 300 segundos. Si la discrepancia MAC-IP continúa en este puerto, entonces el puerto no será recuperado.

Para ajustar el intervalo de recuperación:

SW(config)# errdisable recovery interval 300

Si la condición que provocó el err-disable persiste (rate excedido o ARPs inválidos continuos), el puerto volverá a caer.

Verificación de DAI y DHCP snooping

show ip arp inspection interfaces

Muestra los puertos trusted/untrusted y las estadísticas de rate limit. Aplicado al lab:

SW# show ip arp inspection interfaces

Output esperado en Catalyst 9300 con IOS-XE 17.x:

Interface                Trust State     Rate (pps)    Burst Interval
-----------------------  -----------     ----------    --------------
GigabitEthernet1/0/1     Untrusted       15            1
GigabitEthernet1/0/13    Untrusted       15            1
GigabitEthernet1/0/47    Trusted         unlimited     1

show ip arp inspection statistics

Muestra el contador de paquetes ARP procesados, reenviados y descartados por VLAN, desglosado según el motivo del descarte.

SW# show ip arp inspection statistics

Output (en el lab solo está activa la VLAN 1):

Vlan      Forwarded        Dropped     DHCP Drops    ACL Drops
----      ---------        -------     ----------    ---------
   1           1284             47             47            0

Vlan      DHCP Permits  ACL Permits  Probe Permits   Source MAC Failures   Dest MAC Failures   IP Validation Failures
----      ------------  -----------  -------------   -------------------   -----------------   ----------------------
   1              1284            0              0                     0                   0                        0

Columnas clave:

• Forwarded → paquetes ARP válidos que pasaron la inspección.
• Dropped → total de descartados.
• DHCP Drops → descartados por no coincidir con la binding table de DHCP snooping (el caso típico de ARP spoofing).
• ACL Drops → descartados por una ARP ACL configurada manualmente.
• Source MAC Failures → descartados por la validación src-mac (discrepancia entre la MAC origen del frame Ethernet y la MAC del sender en el payload ARP).
• Dest MAC Failures → descartados por la validación dst-mac (discrepancia entre la MAC destino del frame Ethernet y la MAC del target en el payload ARP).
• IP Validation Failures → descartados por la validación ip (direcciones IP inválidas en el payload ARP).

Para limpiar los contadores:

SW# clear ip arp inspection statistics [vlan <id>]

show ip arp inspection vlan <id>

Muestra el estado de DAI para una VLAN específica, incluyendo si está activo, las validaciones habilitadas y la configuración de logging.

SW# show ip arp inspection vlan 1

Output:

Source Mac Validation     : Enabled
Destination Mac Validation: Enabled
IP Address Validation     : Enabled

 Vlan     Configuration    Operation   ACL Match          Static ACL
 ----     -------------    ---------   ---------          ----------
    1     Enabled          Active      -                  No

 Vlan     ACL Logging      DHCP Logging       Probe Logging
 ----     -----------      ------------       -------------
    1     Deny             Deny               Off

Útil para confirmar de un vistazo qué validaciones están activas y si DAI está realmente operativo (Active) en la VLAN.

show ip dhcp snooping statistics

Muestra estadísticas del procesamiento de DHCP snooping: paquetes recibidos, reenviados y descartados.

SW# show ip dhcp snooping statistics

Output resumido:

Total Packets Processed                               = 5421
Packets Forwarded                                     = 5421
Packets Dropped                                       =   47
Packets Dropped From untrusted ports                  =   47

Para una vista detallada por causa:

SW# show ip dhcp snooping statistics detail

Esto muestra contadores adicionales: paquetes con MAC inválida, opción 82 inválida, server messages en puertos untrusted, etc. Es la herramienta clave para detectar si un atacante intentó levantar un servidor DHCP no autorizado.

Flujo recomendado de verificación en troubleshooting

1. show ip dhcp snooping → confirmar que snooping está activo en las VLANs correctas.
2. show ip dhcp snooping binding → confirmar que los hosts esperados están en la tabla.
3. show ip arp inspection vlan <id> → confirmar que DAI está Active en la VLAN.
4. show ip arp inspection interfaces → revisar trust state y rate limits.
5. show ip arp inspection statistics → identificar si hay drops y por qué motivo.
6. show ip dhcp snooping statistics detail → confirmar que no hay rogue DHCP server activo.
7. Logs %SW_DAI-4-DHCP_SNOOPING_DENY → trazar el host atacante por MAC/IP/puerto.

Demostración: el ataque bloqueado por DAI

Repito el ataque desde el ATTACKER (Gi1/0/1) intentando hacer ARP-poisoning a través de Cain & Abel. El ataque no tiene éxito y en los logs del switch SW aparecen registros como los siguientes:

18:11:19: %SW_DAI-4-DHCP_SNOOPING_DENY: 1 Invalid ARPs (Req) on Gi1/0/1, vlan 1.([50b7.c378.b41a/192.168.1.10/0000.0000.0000/192.168.1.1/18:11:19 UTC Mon Mar 1 1993])
18:11:19: %SW_DAI-4-DHCP_SNOOPING_DENY: 1 Invalid ARPs (Res) on Gi1/0/1, vlan 1.([50b7.c378.b41a/192.168.1.10/001d.4641.02b4/192.168.1.1/18:11:19 UTC Mon Mar 1 1993])
18:11:19: %SW_DAI-4-DHCP_SNOOPING_DENY: 1 Invalid ARPs (Res) on Gi1/0/13, vlan 1.([e803.9abe.0cd8/192.168.1.1/50b7.c378.b41a/192.168.1.10/18:11:19 UTC Mon Mar 1 1993])

Los logs muestran ARPs inválidos provenientes de Gi1/0/1 (ATTACKER, MAC 50b7.c378.b41a) intentando suplantar la identidad del GATEWAY (192.168.1.1, MAC real 001d.4641.02b4). El switch los descarta correctamente y el atacante ya no puede interceptar nada. DAI es la pieza más efectiva de la estrategia de mitigación de ataques ARP en el switch de acceso.

Problemas comunes durante la implementación y soluciones

Los terminales con configuración de IP estática no pueden comunicarse

DHCP snooping solo registra en la binding table la información asignada por DHCP.

→ Los terminales con IP estática pueden ser detectados por la verificación de DAI y sus paquetes ARP pueden ser descartados.

Solución: registrar manualmente un static binding. Por ejemplo, si en el lab quisiéramos dar IP estática a H1 (192.168.1.50, MAC e803.9abe.0cd8, conectado a Gi1/0/13), añadiríamos:

SW(config)# ip source binding e803.9abe.0cd8 vlan 1 192.168.1.50 interface Gi1/0/13

La alternativa de poner el puerto en trust no se recomienda, porque desactiva por completo la inspección DAI en ese puerto.

Error de diseño en VLAN intermedias (entornos con DHCP Relay)

En configuraciones que usan DHCP Relay, el servidor DHCP está fuera del segmento L2, por lo que si te equivocas en la ubicación del puerto trust, el DHCP no pasará.

→ Configura la interfaz de uplink del DHCP Relay como trust.

La binding table desaparece al reiniciar el switch

Por defecto, la información de binding de DHCP snooping se pierde al reiniciar el switch.

Medida (ya incluida en la configuración del lab en §3.3):

SW(config)# ip dhcp snooping database flash:/dhcp-snoop.db

Con esto, DAI y snooping funcionarán normalmente incluso después de un reinicio.

Conclusión

DAI puede operar sobre la binding table de DHCP snooping (modo recomendado y más común), o alternativamente sobre ARP ACLs o bindings estáticos en entornos con direccionamiento IP fijo. El orden de configuración habitual es DHCP Snooping → DAI → validaciones opcionales → rate limiting.

DHCP snooping previene servidores DHCP no autorizados; DAI mitiga el ARP spoofing apoyándose en la binding table que aquel construye.

Junto con port security, DAI y DHCP snooping completan el trío de features de seguridad L2 que exige el objetivo 5.7 del examen CCNA 200-301 v1.1, y dominar esta secuencia es requisito directo para aprobarlo.