Mitigar una inundación de multidifusión de paquetes con formato incorrecto de IPv6

Así que esta mañana tuvimos nuestra primera inundación de multidifusión IPv6 en la red. Logramos detener la computadora infractora al bloquear la dirección mac con: mac-address-table static x.x.x vlan x drop

Antes de bloquear la dirección mac, comenzamos una captura de Wireshark para poder analizar los paquetes más adelante.

Después de mirar los paquetes, parece que los paquetes que inundaban la red estaban dañados. IPv6 DHCP solicita contactar con la dirección de multidifusión IPv6 33: 33: 00: 01: 00: 02.

El impacto de la inundación fue un poco extraño, lo único que parece afectado fueron las solicitudes normales de IPv4 DHCP, los clientes habituales no podían obtener una dirección IP, pero aquellos que ya tenían una antes de que comenzara la inundación no experimentaron problemas ... La CPU en los conmutadores también alcanzó su punto máximo al 95-100%, pero no pareció afectar las operaciones normales de conmutación / enrutamiento del tráfico.

Lo que necesitamos ayuda para determinar es cómo solo 30 mbps de tráfico de multidifusión IPv6 pueden llevar la CPU en un 6509 SUP720 al 100% y hacer que el DHCP IPv4 normal deje de funcionar y cómo protegernos contra esto si vuelve a suceder.

Cada puerto de acceso / cliente tiene la siguiente configuración:

 switchport access vlan x
 switchport mode access
 switchport nonegotiate
 switchport block multicast
 switchport block unicast
 switchport port-security maximum 2
 switchport port-security
 switchport port-security aging time 2
 switchport port-security violation restrict
 switchport port-security aging type inactivity
 storm-control broadcast level 5.00 4.00
 storm-control multicast level 5.00 4.00
 spanning-tree portfast
 spanning-tree bpduguard enable

¿No se aplica la multidifusión de control de tormentas a la multidifusión IPv6?

Aquí hay un extracto de la captura de Wireshark con los paquetes "malvados" en Dropbox .

Y una pequeña colección de gráficos para ilustrar el impacto:

También investigamos la computadora infractora y no pudimos encontrar la razón o no poder reproducir el problema ...

Antecedentes

Estoy en algún lugar que bloquea las descargas de Dropbox, por lo que no puedo ver el tráfico capturado, pero supongo que se trata de multidifusiones de Ethernet de 64 bytes.

Hagamos algunos cálculos para ver cuánto tráfico está permitiendo ...

Una trama de 64 bytes tiene 672 bits (incluidos 8 bytes para Preámbulo / SFD y 12 bytes para IFG) ...

8 * (8 + 12 + 64) = 672 bits

Eso significa que los cuadros de 64 bytes Gigabit Ethernet de velocidad de línea son de aproximadamente 1.488Mpps ...

(1000000000 / 672.0) = 1488095.24 pps

¿Qué significa esto para usted? Bueno, su configuración actual de control de tormentas acelera el tráfico al 5% de la velocidad de línea, por lo que está permitiendo que 74.4kpps de tráfico llegue a su interruptor antes de que el control de tormenta entre en funcionamiento. 74.4kpps * Los marcos de 64 bytes son 38Mbps, lo cual es correcto en lo que muestran sus gráficos:

Responder

Entonces, la conclusión es que está permitiendo que demasiado tráfico golpee la CPU del interruptor, por lo que la utilización de la CPU fue alta. 74.4kpps es realmente demasiado para permitir que cualquier interruptor de CPU procese.

Asumiendo que estas estaciones no deberían enviar una gran cantidad de multidifusión o transmisión, la respuesta simple es limitar su tráfico de esta manera ...

   ! Note that broadcast traffic has the ethernet I/G bit set
   ! which means it is also classified technically as a multicast
   ! for storm-control purposes.  Therefore set your broadcast limit
   ! a little lower than your multicast limit
   storm-control broadcast level 0.4 0.3
   storm-control multicast level 0.5 0.3

Ahora se activa el control de tormentas cuando un puerto envía 6kpps de transmisión (0.4% de velocidad de línea 1GE) o 7.5kpps de multidifusión / transmisión combinadas (0.5% de velocidad de línea 1GE).

Para su información, probablemente valga la pena analizar el Control Plane Policing , que protege la CPU del switch contra varios puertos que se agrupan en él. Tenga en cuenta que el CPP puede ser complicado de hacer bien, por lo que es una buena idea probarlo bien antes de implementarlo en su entorno.