Cisco Bug: CSCvt94725 - Strom-control multicast silently drops multicast traffic without reaching the threshold
Jul 20, 2020
- Cisco Catalyst 9500 Series Switches
Known Affected Releases
16.12.2 16.12.3 17.1.1 17.2.1
Symptom: - RTP packets loss on multicast receivers. - Quality degradation. Conditions: storm-control configured under the interface for multicast traffic. In addition to the Traffic storm control feature, Cat9500H and Cat9600 switches also supports storm control policer at hardware level. The main idea of this policer is to prevent the system from any traffic exceeding the set threshold level. There are four policers for each physical network port(unicast, unknown unicast, multicast and broadcast). The Storm Control policers are implemented as simple token bucket policers in which credits are deducted for incoming frames/bytes. When credit runs out, hardware drops the packets for that physical port/traffic type pair. Credits will be restored every 1 msec. The whole idea of storm control policer is to protect from any traffic coming at rate higher than the set threshold(spikes, which are higher than the threshold) at hardware level even before the software can take action. example: Say interface speed is 100Mbps. The storm control level set is 90%, which is 90% of 100Mbps i.e, 90Mbps allowed Since at hardware we policer at every 1 msec, the rate allowed will be 90kb/msec. if there are any spikes reaching > 90kb/msec , rest of the traffic will be dropped in that msec since at hardware level, storm control policer credits would have been run out and will be restored in the next milli sec. in this case overall traffic rate may not be > 90Mbps hence software storm-control would not be detected.
Bug details contain sensitive information and therefore require a Cisco.com account to be viewed.
Bug Details Include
- Full Description (including symptoms, conditions and workarounds)
- Known Fixed Releases
- Related Community Discussions
- Number of Related Support Cases