Rate-limit

[eyeV]

Hi everybody.
I have two Summit x670 (15.4.1.3) switches and I'd like to limit inbound broadcast, multicast and unknown unicast packets on specific ports. So, I've configured rate-limit to 500pps.

config port 3 rate-limit flood broadcast 500
config port 3 rate-limit flood multicast 500
config port 3 rate-limit flood unknown-destmac 500Then I see the output of "show ports 3 stat" command. I see only 10-20 pps, but Flood Rate Exceeded counter is increasing and I have log messages like
Flood Rate Limiting activated on Port 3

[Erik_Auerswald]

I have just tested broadcast rate-limits on an X620-16t switch using EXOS 21.1.1.4-patch1-2, they work fine. So there is a 10G switch, using a newer SoC, with working broadcast limiters. 

[Stephane_Grosj1]

Ok, so the fix in 21.1 I was referring above is working. Good to hear. It should work as well on any other switches running 21.1 and above.

[FredrikB]

This is an old thread, but as new releases and hardware have seen the light of day, I think it's appropriate to add some info here.

From tests in the real world and dialogue with the TAC, there seems to be on specific platform that behaves differently and which may never have a decent rate limiting implementation, being the X430/X440 (non G2).

Referring to this article (seems revised and in the current version almost possible to understand):
https://gtacknowledge.extremenetworks.com/articles/How_To/How-to-rate-limit-implement-on-EXOS-platfo...

- Measurements are per time slice, and this hardware has a time slice that is 15.625 microseconds long.
- Setting a rate of 64000 allows one packet per time slice (15.625 microseconds)
- Setting a rate of 2 * 64000 = 128000 allows two packets per time slice (15.625 microseconds)
- Setting a rate of n * 64000 allows "n" packets per time slice (15.625 microseconds)
- For each second, one extra packet is allowed due to how buffers are handled (or is this per 15.625 us time slice?)

All this is based on the fact that one packet "costs" 64000 tokens in order to to be processed and the rate limit is in reality the number of tokens that are added to the bucket every time slice. If you add 64000 tokens to the bucket every time slice, you can afford to buy one packet per interval (time slice). I assume the bucket is "emptied" at the end of every time slice and new tokens are added, and the number of tokens being the rate limit you defined.

Scenario 1:

Rate limit set to 64000.
Packets are coming in at a pace of two packets every 15.625 microseconds (not realistic, but for the sake of discussion).
Result:
One packet per 15.625 microsecond interval will be accepted and the second packet will be discarded, resulting in 64001 packets coming through (counting the one in the buffer) each second.
In this unrealistic scenario, we get the requested amount of packets per second (plus one for free  ).

Scenario 2:

Rate limit set to 128000.
Small 64 byte packets come in as a bust of 10 packets, with no gap in between them, taking 6.72 microseconds in total to transmit (1 Gbps line rate).
All packets happen to arrive in the same time slice (the same 15.625 us interval).
As the limit of 128000 allows two packets per time slice and all packets arriving in the same time slice, only two packets are allowed (plus one in the buffer making it three packets).


In addition, all G2 hardware (including X620, X690 and X870) do count the packets during a whole second as expected, but only if the EXOS release is 21.2 or higher. I see this expected behavior in X450e as well, but apparently in EXOS 15.3.5.2 patch1-17.

I hope to get some confirmation or further explanation to this from the TAC.

/Fredrik

[Erik_Auerswald]

Just to document this, I have encountered the issue with basically unusable broadcast limiters on X670 switches with different EXOS versions (15.2, 15.3, 15.6). 