08-23-2023 04:28 AM
Hi,
I'm setting up my first storm control because I suspect a broadcast issue on a specific interface :
SW#sh int g1/0/6
...
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 2000 bits/sec, 2 packets/sec
76810 packets input, 8400106 bytes, 0 no buffer
Received 68976 broadcasts (0 multicasts)
0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
0 watchdog, 0 multicast, 0 pause input
0 input packets with dribble condition detected
273780 packets output, 34699514 bytes, 0 underruns
0 output errors, 0 collisions, 0 interface resets
0 unknown protocol drops
0 babbles, 0 late collision, 0 deferred
0 lost carrier, 0 no carrier, 0 pause output
0 output buffer failures, 0 output buffers swapped out
So I applied a storm-control to the interface :
interface GigabitEthernet1/0/6
description BROADCAST GIRL
switchport access vlan 19
switchport mode access
ip device tracking maximum 10
storm-control broadcast level 10.00
storm-control multicast level 10.00
spanning-tree portfast edge
But nothing show up :
Interface Filter State Upper Lower Current Action Type
--------- ------------- ----------- ----------- ---------- --------- ----
Gi1/0/6 Forwarding 10.00% 10.00% 0.00% None B
Gi1/0/6 Forwarding 10.00% 10.00% 0.00% None M
I tried to look for the best practise but I could'nt find what I've done wrong.
Do you have a clue please ?
Many thanks
Solved! Go to Solution.
08-25-2023 08:17 AM - edited 08-25-2023 09:10 AM
I understand.
Unfortunately, storm control is the proverbially double edged sword; it cuts both ways. I.e. if limiting broadcast to a very low level "cures" this one host's issue, do other hosts now have issues? Just something to watch for.
BTW, I recall (?) the broadcast % is not based on non-broadcast to broadcast packets ratio, but to the percentage of interface bandwidth. If that's correct, 1% on a gig interface would allow up to 10 Mbps of the bandwidth to be broadcast.
08-23-2023 04:48 AM
Hi @Thibault_1
I dont see anything wrong. What is happening is that the interface is not receiving too much broadcast traffic. Instead of 10 use a lower value like 1 or 2 and test again.
08-23-2023 05:08 AM
Hello @Thibault_1,
Storm control will take action when the broadcast or multicast traffic rate exceeds the specified threshold (10% in your case). If the current traffic rate is below this threshold, storm control won't take any action, and you won't see any entries in the "Interface Filter State" output. Then follow @Flavio Miranda and apply a lower value, 1 or 2.
08-23-2023 08:38 AM
In addition to what others posted do you know the time frame of those broadcast. Did you clear the counters on that interface and monitor to see how quickly it goes up.
Received 68976 broadcasts (0 multicasts)
Is a lot of broadcasts but if the counters have never been cleared and assessed and the switch has been up for 6 years 4 months 21 days 3 hours 5 minutes and 16 seconds then its probably not a big deal.
Secondly your counters say 0 multicasts so your multicast likely wont catch anything anyway.
-David
08-24-2023 03:42 AM
Hi everyone,
Thank you for your helpful feedbacks ! Here are some responses :
@Flavio Miranda the strange part for me is that the sh storm-controll output doesn't count the broadcast as the "current" collumn displays 0.
M02@rt37 given the numbers, it is exceeding the thresold : it is now a 88.6% with the fresh values
163481 (packets input, 17908420 bytes, 0 no buffer Received 144882 broadcasts (0 multicasts)
@David Ruess I've cleared the counters 24H before posting the first message. I have no comparison yet to tell if the number is a lot or not, but it looks annormal that 88% of the traffic is broadcast.
I agree with the multicast parameter, that is useless in that case.
I down the thresold to 1 and see what happens.
Many thanks!
08-24-2023 03:56 AM
You're welcome @Thibault_1
Thanks for your feedback.
08-25-2023 04:32 AM
"I down the thresold to 1 and see what happens."
Hopefully, my prior reply made clear using storm control like features is "bad" for "good" traffic, so when it triggers you're "breaking" your network including when it's not (yet) in danger of collapse.
So, when you choose a value for it to engage, you don't want to set too low. I.e. using the minimum value makes it more likely you'll trigger storm control when it shouldn't be triggered.
Conversely, even a value as low as 1% might be ideal for YOUR network.
Just understand using storm control is like using fire, both very useful and very dangerous.
08-24-2023 12:00 PM
"I'm setting up my first storm control because I suspect a broadcast issue on a specific interface :"
Well, if indeed 90% of your packets are broadcast, I can see why you believe you might think you have a broadcast issue, but those same stats show a zero ingress rate.
What you also want to know, is what's the percentage of bandwidth being used by these broadcasts.
What you're trying to ascertain, is your broadcast rate abnormally high? Is it beyond what one would expect for the number of hosts and the network applications using it.
The major problem with "storm controls", it's like being in a sinking lifeboat because it has too many passengers. So, to keep the lifeboat from sinking, you start to randomly throw some passengers out of the boat. I.e. your choice is everyone drowns or some drown! (Some choice - not too bad, if you're not heaved out of the lifeboat, though.)
If you have too many broadcasts, first you need to determine if they are valid. If not, find the cause of the invalid broadcasts, and fix that. If valid, mitigate, which might include configuration changes on hosts and/or further segmentation of your network (broadcasts are why we don't all run our LAN network as one big /16).
"I tried to look for the best practise"
Best practice:
Set values well above whatever you believe is the expected normal level of broadcasts, but ideally low enough, your network doesn't sink.
Monitor storm-control getting triggered.
If triggered, resolve cause and/or mitigate to acceptable levels.
08-25-2023 07:51 AM
Hi,
Thank you for your feedback @Joseph W. Doherty
I understand your words, but here is the problem I try to solve : a device on the subnet doesn't react properly. I wonder if it's not because he revieces to much broadcast and cannot follow. It is not easy to change the subnet because everything is already configured on site.
I would like to make sure the broadcasting device does not disturb my other device, so I've blocked the broadcast by setting the level to 0. I was able to see the storm control triggered as the "current" value does not change.
08-25-2023 08:17 AM - edited 08-25-2023 09:10 AM
I understand.
Unfortunately, storm control is the proverbially double edged sword; it cuts both ways. I.e. if limiting broadcast to a very low level "cures" this one host's issue, do other hosts now have issues? Just something to watch for.
BTW, I recall (?) the broadcast % is not based on non-broadcast to broadcast packets ratio, but to the percentage of interface bandwidth. If that's correct, 1% on a gig interface would allow up to 10 Mbps of the bandwidth to be broadcast.
08-25-2023 08:50 AM
**bleep** ! Although I've read the cisco note I must have missed that ! It explains everything !
I'll wait monday to have the results of the tests.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide