2524 switch CPU 91% after receiving invalid multicast from cisco

[Igoris_1]

It seems 2524 switch get's crazy- CPU utilization from 21% goes to 91%, event log does not show any problem, packet monitoring shows some invalid multicast packets, coming from cisco device, which is on a clients side, see attached screenshot. Switch has latest firmware F.05.55 and is configured with 13 VLANs. On the same VLAN, where multicasts are coming I see big increase in traffic, but strange thing is that it seems traffic is generated by switch itself. When I reboot switch, CPU utilization is 21% and everything looks fine, but the next day problem comes back. Any ideas?

[Matt Hobbs]

Have you tried enabling IGMP on that VLAN?

[Richard Brodie_1]

From the sample, you have a high (apparently) bogus multicast rate sent from a Cisco source address to a Cisco multicast address.

How does that much up with the Procurve being the source of the traffic? From the information you've posted it just looks like the Cisco has gone loco and is crapflooding your LAN. If that was just a brief event, how do the traffic patterns alter after?

If rebooting the Procurve fixes it, maybe just pulling the link down briefly would too.

[Igoris_1]

disable source port does not help.
Now what I found after deeper investigation: there are three 2524 switches connected into chain and STP is running. In spite of gigabit port 25 (connected to another 2524) is blocked by STP on one of the switches I see traffic still passing that port from other switch, SNMP monitoring shows that, looks like multicast packets get into the loop and flood all three switches. All 3 CPUs utilization is almost the same- 91%.
Now question: is that right that STP blocked port is still forwarding some non standard multicast packets?

[Igoris_1]

regarding IGMP VLAN has no IP address, and according to documentation Reserved Addresses are Excluded from IP Multicast (IGMP) Filtering. Is it worth to enable IGMP in this case?

[Richard Brodie_1]

The multicast address is used Cisco CDP/VTP not an IP one at all. I doubt IGMP will affect it.

[Igoris_1]

there is a fix in release F.05.55 RSTP (PR_99049) â Switch does not detect and block network topology loops on a single
port.
It seems it is not fixed properly, some type of packets are still passing blocked port. Any comments? I will submit software case tomorrow.

[Matt Hobbs]

By the sounds of it, it is blocking those packets but they are still hitting the CPU. Certain packets need to be sent to the CPU to see if they need further processing, e.g. BPDU's, Broadcast traffic... I would say this is expected behaviour. You should track down exactly what is sending out that traffic in the first place.

[Igoris_1]

while CPU is 91% every port in affected VLAN is sending out 1,5 Mbps, I could not find such traffic coming into the switches, it was definitely the loop generated traffic. When I disabled switch1 port going to switch2, which was blocked by STP on that switch2, then CPU utilization dropped to 20% on all three switches and traffic 1,5 Mbps disappeared. That proves it was a loop initiated by specific multicast packets.