In large campus networks with SMLT topologies where multicast routing protocols (such as PIM) have been provisioned and scaled to large amounts of multicast senders and receivers, it has been observed that high CPU utilization
(sometimes combined with high CPU buffer utilization) leading to IST instability may occur during re-convergence of the multicast routing protocols after failures.

Additional information;

Release 5.1.3.0 has been modified with changes that were originally introduced in release 7.0.0.0. These changes allow IST protocol messages to be processed even under high CPU utilization. This is achieved by checking to see if IST control messages are queued up (but not yet processed) before deciding that the IST session has timed out and needs to be brought down. Each line card recognizes and counts IST control messages when they arrive and before they are sent to the CP, and the IST message processing logic on the CP will check for outstanding IST control messages before deciding the IST needs to be brought down due to inactivity.

Cheers!

Apparently the auto-save feature may be exhausting the number of writes that the physical flash memory is capable of. If the switch is configured with MAC address security, a feature that could possibility be causing the auto-save feature to write the configuration hundreds if not thousands of times, the flash memory may surfer from extreme “memory wear” and cease functioning properly.

Thankfully there is a “second” NVRAM flash block available.

I would highly suggest that everyone review the bulletin for themselves.

It might be wise to disable the auto-save feature and have the technicians/engineers manually save any configuration changes when necessary (similar to how Cisco switches/routers work).

Cheers!