Understanding storm-control unicast and performance issues it can cause

[matthew.drew]

Recently my environment has had layer 2 performance problems from what we thought was either a broadcast or unicast storm. Since then I've really tried to harden the switching environment. Part of that was implementing storm-control across all our access layer trunks and user ports. I have a security camera connected to a switchport running storm-control unicast level 5.00. I noticed the frame rates skipping so I decided to check the interface and logs.

I see about 4 Mbps of traffic ingress

5 minute input rate 4035000 bits/sec, 361 packets/sec
5 minute output rate 191000 bits/sec, 354 packets/sec

and this message in the log...

%STORM_CONTROL-3-FILTERED: A Unicast storm detected on Fa0/4. A packet filter action has been applied on the interface.

From my understanding of this line of config, the switch will only drop unknown unicast frames when they reach 5% of 100 Mbps, so 5 Mbps. The frames from this HD security cam should be known unicast, right? And known unicast should not be affected by storm-control.

Sure enough though, when I delete that command and remove storm-control the camera stop skipping and works perfectly.

Why would a security camera be bombarding a port with unknown unicast? These cameras seem to work fine otherwise...

[Feds]

Hi Matthew,

I know this thread is quite old, but I see nobody replied. I've had a similar issue of "unicast storm" on a trunk to an ESXi host, when one of the VMs was simply being backed up. Switch is a 3650 running IOS-XE 17.3.4.

SC unicast is set to 75% (upper) and 60% (lower) on a 1Gbps port.

I googled a bit but couldn't find anything too informative whether SC unicast should be enabled as best practice on access ports, or instead if unknown-unicast should be enabled only. I can't think of a valid reason to have "good" known unicast blocked for an access port when you can trust the attached device/user. Perhaps only if you want to implement shaping without a shaping policy. Blocking unknown unicast is a different story especially if device/user is untrusted.

What I have found though is Cisco stating that "actual enforced threshold might differ from the configured level by several percentage points", and in another page that "several" being quantified at 5%. This may explain your problem for SC being applied to unicast reaching 4% and not 5% as per configured threshold.

It's also not very clear the way Cisco doco describe difference between SC unicast and unknown-unicast and what happens exactly when you have one or the other configured (not both): does "SC for unicast is a combination of known and unknown unicast" apply to the "storm-control unicast ..." command? So why is there a specific one for unknown-unicast?

Storm control for unicast is a combination of known unicast and unknown unicast traffic. When storm control for unicast is configured, and it exceeds the configured value, the storm will hit each type of traffic through the hardware policer. The following example describes how the unicast traffic is filtered, when the configured storm is 10%:

• Incoming traffic is unknown unicast 8% + known unicast 7%. Total of 15% storm is not filtered in hardware by the hardware policer.

• Incoming traffic is unknown unicast 11% + known unicast 7%. Total of 18% storm will hit unknown unicast traffic type, and the hardware policer will filter unknown traffic that exceeds 11%.

• Incoming traffic is unknown unicast 11% + known unicast 11%. Total of 22% storm will hit unknown unicast traffic and known unicast traffic, and the hardware policer will filter both unknown and unknown unicast traffic.

If anyone can explain this a little bit better, I'd appreciate it.

Thanks
Fed

[paul driver]

Hello

---

@matthew.drew wrote:

Why would a security camera be bombarding a port with unknown unicast?

---

If a switchport isn't aware of the destination address it will indeed flood the switch which what seems to be occurring and so your SC unicat percentage is being reached and is causing your camera to jitter.

So you need to find out the cause of the unicast flood.

STP changes, non viable mac/arp ageing, asymmetric routing etc...