Acabamos de receber nossa primeira inundação multicast IPv6 na rede hoje de manhã. Conseguimos parar o computador infrator bloqueando o endereço mac com:
mac-address-table static x.x.x vlan x drop
Antes de bloquearmos o endereço mac, iniciamos uma captura do Wireshark para podermos analisar os pacotes posteriormente.
Após examinar os pacotes, parece que os pacotes que estão inundando a rede estavam corrompidos. Solicitações de IPv6 DHCP entrando em contato com o endereço multicast IPv6 33: 33: 00: 01: 00: 02.
O impacto da inundação foi meio estranho, a única coisa que parecia afetada foram as solicitações normais de IPv4 DHCP, os clientes regulares não conseguiram obter um endereço IP, mas aqueles que já tinham um antes da inundação começaram a ter problemas ... nos switches também alcançou 95-100%, mas não pareceu afetar as operações normais de comutação / roteamento de tráfego.
O que precisamos de ajuda para determinar é como apenas 30 Mbps de tráfego multicast IPv6 podem aumentar a CPU em um 6509 SUP720 para 100% e fazer com que o DHCP IPv4 normal pare de funcionar e como nos proteger contra isso, caso aconteça novamente.
Cada porta de acesso / cliente tem a seguinte configuração:
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
O multicast de controle de tempestade não é aplicado ao multicast IPv6?
Aqui está um extrato da captura do Wireshark com os pacotes "maus" no Dropbox .
E uma pequena coleção de gráficos para ilustrar o impacto:
Também investigamos o computador infrator e não conseguimos encontrar o motivo ou a capacidade de reproduzir o problema ...