So we just had our first IPv6 multicast flood in the network this morning.
We managed to stop the offending computer by blocking the mac address with:
mac-address-table static x.x.x vlan x drop
Before we blocked the mac address we started a Wireshark capture so we could analyze the packets later on.
After looking at the packets it seems the packets flooding the network was corrupt IPv6 DHCP requests contacting the IPv6 multicast address 33:33:00:01:00:02.
The impact of the flood was kind of weird, the only thing that seem affected was normal IPv4 DHCP requests, regular clients couldn't get a IP address, but those who already had one before the flooding started experienced no problems... The CPU's on the switches also peaked to 95-100%, but did not seem to impact normal traffic switching/routing operations.
What we need help to determine is how only 30mbps of IPv6 multicast traffic can push the CPU on a 6509 SUP720 to 100% and make normal IPv4 DHCP to stop working and how to protect ourselves against this should it happen again.
Each access/client port has the following configuration:
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
Isn't storm-control multicast applied to IPv6 multicast?
Here is a extract from the Wireshark capture with the "evil" packets on Dropbox.
And a little collection of graphs to illustrate the impact:
We also investigated the offending computer and could not find the reason or being able to reproduce the issue...