Kassinipedia

Snooping & DAI - Troubleshooting

Se lee en 3 min

Protección de capa 2 - Troubleshooting

Método general (de lo mínimo a lo complejo)

  1. ¿Los clientes obtienen IP? Si no, revisa DHCP Snooping (puerto del servidor debe ser trusted).
  2. ¿Hay hosts sin conectividad tras activar DAI? revisa la binding table y los puertos trusted.
  3. ¿El puerto del servidor/uplink está marcado trusted en snooping y en DAI?
  4. ¿La VLAN nativa está bien (no la 1, coincide en ambos extremos)?

Comando base:

Switch# show ip dhcp snooping binding
Switch# show ip arp inspection interfaces

Caso 1 — Los clientes no obtienen IP tras activar DHCP Snooping

Síntoma: al activar DHCP Snooping, los usuarios dejan de recibir dirección.

Causa: el puerto hacia el servidor DHCP legítimo quedó como untrusted, así que el switch descarta sus Offer/Ack.

Diagnóstico:

Switch# show ip dhcp snooping           ! ¿qué interfaces son trusted?

Solución: marcar el uplink hacia el servidor como trusted.

Switch(config)# interface gigabitEthernet 0/1
Switch(config-if)# ip dhcp snooping trust

Caso 2 — Hosts sin conectividad tras activar DAI

Síntoma: después de habilitar DAI, algunos equipos pierden comunicación (su ARP se descarta).

Causa: DAI valida el ARP contra la binding table de DHCP Snooping. Si el host tiene IP estática (no pasó por DHCP) o la binding table está vacía, su ARP se descarta.

Diagnóstico:

Switch# show ip dhcp snooping binding    ! ¿está el host en la tabla?
Switch# show ip arp inspection           ! ¿cuántos drops?

Solución:

  • Asegurar que DHCP Snooping esté activo y aprendiendo (el puerto del servidor trusted).
  • Para hosts con IP estática legítima, usar una ARP ACL que los permita (o marcarlos según el diseño).
  • Marcar como trusted los uplinks hacia dispositivos intermedios/servidores.
Switch(config)# interface gigabitEthernet 0/1
Switch(config-if)# ip arp inspection trust

Caso 3 — El puerto se satura de mensajes DHCP/ARP (rate-limit)

Síntoma: un puerto cae o descarta por exceder el límite de tasa.

Causa: un ataque de starvation, o un límite demasiado bajo para el tráfico legítimo.

Diagnóstico:

Switch# show ip dhcp snooping            ! rate-limit de DHCP
Switch# show ip arp inspection interfaces ! rate (pps) de ARP

Solución: ajustar el límite (o investigar el ataque).

Switch(config)# interface fastEthernet 0/1
Switch(config-if)# ip dhcp snooping limit rate 100
Switch(config-if)# ip arp inspection limit 15

Nota: DAI trae por defecto un límite de 15 pps; si un puerto legítimo lo supera, súbelo o usa ip arp inspection limit none con criterio.

Caso 4 — VLAN nativa como vector de ataque (Double Tagging)

Síntoma: preocupación de seguridad por VLAN hopping.

Causa: se está usando la VLAN 1 como nativa en los troncales.

Diagnóstico:

Switch# show interfaces trunk            ! columna Native vlan

Solución: usar una VLAN nativa dedicada (no la 1), igual en ambos extremos.

Switch(config)# interface gigabitEthernet 0/1
Switch(config-if)# switchport trunk native vlan 99

Caso 5 — Aparece un servidor DHCP pirata (spoofing)

Síntoma: algunos clientes reciben gateway/DNS incorrectos.

Causa: un servidor DHCP no autorizado (pirata) está respondiendo desde un puerto untrusted.

Diagnóstico:

Switch# show ip dhcp snooping            ! ¿el puerto del pirata es untrusted?
Switch# show ip dhcp snooping binding

Solución: con DHCP Snooping activo y solo el puerto del servidor legítimo como trusted, los Offer/Ack del pirata se descartan automáticamente. Verifica que ningún puerto de usuario esté marcado trusted por error.

Recuerda el orden: puerto del servidor trusted (snooping), binding table poblada (base de DAI), uplinks trusted en DAI, límites de tasa razonables, y VLAN nativa dedicada.

Vista Gráfica

Retroenlaces