Abnormal high CPU utilization on stack

[Ilya_Semenov]

Hello, everybody!

I have a stack of 2x460 and 6x440 1st generation summits (8 switches total). The problem is every morning at exactly same time I get the message from snmp (please, see the attached file).

I've noticed also, that there is constantly high CPU utilization from 20 to approximately 50% regardless of the day time. The EXOS version is 15.7.4.2.

Please, share your ideas about reasons why it happening.

Many thanks in advance,

Ilya

[Marco_Lorenz]

No. No NLB. In my case it is a machinecntroller from Siemens (S7), which is sending a lot of multicasts and brings CPU to 85% in average.

[Marco_Lorenz]

If possible you can disable all edgeports and enable them one after the other and look which port is responsible for the high cpu load.

[Gilson_Fraboni]

you have configuring Windows NLB on the stack?

[Erik_Auerswald]

Lots of multicast traffic can be generated by many end systems sending some multicast, e.g. Bonjour, MDNS, LLMNR, SSDP/UPnP. These packets are sent to the switch CPU, but the switch does not use the information.

Taking a packet capture should give you information about the amount of this kind of multicast traffic in your network.

You can stop those packets from affecting the switch CPU by using an ACL. You can use the following as an example to start from:
entry deny_MDNS { if match all { destination-address 224.0.0.251/32; } then { deny-cpu; count MDNS-deny; } } entry deny_LLMNR { if match all { destination-address 224.0.0.252/32; } then { deny-cpu; count LLMNR-deny; } }The counters give you a way to see if there were packets affected by the ACL.

You might want to take a look at the GTAC Knowledge article How can I block mDNS with an ACL using MAC addresses as well.

[Marco_Lorenz]

The reason for high cpu can be a device sending a lot of multicasts. Because multicasts are pricessed in the main cpu the load will inctease with the amount of multicasts being send to the device. You can figure it out by inspecting a tracefile. I have a similar issue and the only way to decrease cpu load was an accesslist which blocks multicasttraffic on the port where the sending device is attached.