ExOS rate-limit flood- broadcast Flood Rate Exceeded

  • 18 February 2017
  • 7 replies

Hi everyone.

I have some problem with control broadcast in my network.
If i set broadcast flood rate in something like 30000, i saw that Flood Rate Exceeded counter increases, but in Rx Pkt Bcast i saw maximum 50-100 packets per second.
MCast & UnkCast rate set to no-limit
sc1 # show ports 7 rate-limit flood port-number
Port Rate-Limit Discard Monitor Sat Feb 18 15:21:43 201777
Port Link Rx Pkt Rx Byte Rx Pkt Rx Pkt Flood Rate
State Count Count Bcast Mcast Exceeded
7 A 10532496 1630959311 10531169 1406 10531364 [/code]
Can you tel me what packet drop switch?

Also i fond this page https://extremeportal.force.com/ExtrArticleDetail?an=000083176, but i can't understand what it is the magic number: 15.625

TU for your answer? sory for my englishh=)

7 replies

Userlevel 4
To be simple, if you set rate-limit value of 64,000 it is given 64,000 tokens to a switch in every 15.625 microsecond. And since 64,000 tokens are good for 1 packet, the other packets will be dropped if those are coming into the switch within 15.625 microsecond.
So even if you see there's only 50 to 100 packets in average, there's still a possibility the switch drops packets when an interval time between two packets is very short.

TY for your answer, but i can't understand what exactly I set with command:
configure ports 14 rate-limit flood broadcast 60[/code]This means that first 60 packets go on and 61 packet will be dropped. Or using this command i set tokens count that generated switch, when it forvarding 1 packet?
Userlevel 4
Let's divide time frames in every 15.625 microsecond.
( t0, t1 = t0+15.625, t2 = t1 + 15.625 ... tx+1 = tx + 15.625 )
If you set the limit to 64 pps(to be simple), 64 tokens will be given to the switch on every time frame.
As the article says, the switch needs 64,000 tokens to forward 1 packet.
How many cycle the switch need to have 64,000 tokens? 64,000/64 = 1,000

Let's say the switch does not have any token from beginning and when can it forward a packet?
t0 => 0 token, insufficient token, packet dropped
t1 => 64 tokens, insufficient tokens, packet dropped
t1000 => 64,000 tokens, use all of those to forward 1 packet
t1001 = > 64 tokens, insufficient tokens, packet dropped

So any packets that come to the switch from t0 to t999 will be dropped.

In ideal situation when the broadcast packets are coming in every 1,000th time frame, 64 packets will be forwarded in 1 second since 64,000 * 15,625 microsecond is approximately 1 second.
Userlevel 7

this behavior is supposed to be fixed with 21.1 and above. If you cannot upgrade to 21.1+, it would be better to use meters instead of the cli rate-limit flood command.
So if I correctly understand - drop of this packet its no so bad? I don't think so. Set rate-limit for 60000 broadcast its bad idea to, so how i can calculate rate limit for 200 broadcast pps without Flood Rate increment

-cannot upgrade to 21.1+ -- our vendor give us this this firmavare:
* sc1 # show switch
System Type: X670V-48x
Primary ver: patch1-9[/code]
Userlevel 7

Indeed, a x670V is on the 16.x train release, no way to upgrade to 21/22.x.

Drop of packet is certainly bad in that case. The rate-limit command does that (explicitly drop), but the issue here is that it doesn't happen precisely when expected. I understand the need to rate-limit such traffic above a given threshold, as this is certainly a loop going on, or an attack. Considering the behavior of this command, which is not anymore really per second, I'd encourage you to create meters. They would do the job as expected.
Userlevel 6
Let me see if I can ease the minds about how and when we use port/hardware based broadcast flood protection. Our use is edge customer facing interfaces... We set it to 200 pps on all of these. Do we get a few hits and alarms about this... Yep and we have trained our NOC on how to look at the stats on that port to determine if the customer has a loop or something going on inside their LAN or network. this does not affect their ability to use the network or services. This does not disable their port but sure the heck will slow down a local broadcast storm from coming back into our one gig switches and saturating a one gig uplink port. It generates a nice snmp trap for the NOC to respond to. The first time you let one of your edge customers know they have a small or big loop going on in their LAN you will be a hero to them... Just remember this is a broadcast packets being sent to every port in the same broadcast domain. If you drop a few packets because of this configuration as a rule it does not effect the services. If you have a loop going on in an adjacent network that is being sent to you because you are part of their layer 2 broadcast domain believe me they will want you to let them know so it can be dealt with and shut down. We have thousands of interfaces with broadcast packets being limited for years and have yet to have any issues with our services and clients.