Atenuando uma inundação multicast de pacotes mal formada IPv6

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 ...

fundo

Estou em algum lugar que bloqueia os downloads do Dropbox, então não consigo ver o tráfego capturado, mas suponho que sejam multicasts Ethernet de 64 bytes.

Vamos fazer algumas contas para ver quanto tráfego você está permitindo ...

Um quadro de 64 bytes possui 672 bits (incluindo 8 bytes para Preâmbulo / SFD e 12 bytes para IFG) ...

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

Isso significa que os quadros Gigabit Ethernet de 64 bytes de taxa de linha são de aproximadamente 1.488Mpps ...

(1000000000 / 672,0) = 1488095,24 pps

O que isso significa para você? Bem, sua configuração atual de controle de tempestade reduz o tráfego em 5% da taxa de linha, permitindo que 74,4kpps de tráfego atinjam seu switch antes que o controle de tempestade entre em ação. 74,4kpps * quadros de 64 bytes são 38Mbps, o que é correto no que seus gráficos mostram:

Responda

Portanto, a conclusão é que você está permitindo que muito tráfego atinja a CPU do switch, e é por isso que a utilização da CPU foi alta. 74.4kpps é realmente demais para permitir o processamento de qualquer CPU de switch.

Supondo que essas estações não devam enviar muito multicast ou broadast, a resposta simples é reduzir o tráfego dessa maneira ...

   ! 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

Agora, o controle de tempestade entra em ação quando uma porta envia 6kpps de broadcast (taxa de linha 1GE de 0,4%) ou 7,5kpps de multicast / broadcast combinado (taxa de linha 1GE de 0,5%).

Para sua informação, provavelmente vale a pena examinar o Policiamento de Plano de Controle , que protege a CPU do switch contra várias portas que se agrupam nele. Lembre-se de que o CPP pode ser complicado para acertar, por isso é uma boa ideia testar bem antes de implementá-lo em seu ambiente.