Determining the correct level for Broadcast Rate limiting.
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Get Direct Link
- Report Inappropriate Content
‎04-24-2017 05:18 AM
I’m considering enabling broadcast, multicast and unknown unicast rate limiting on a customer’s network ( core EAPs ring links ), this customer recently had a EAPs ring loop as the result of a card malfunction, this was devastating to the customer network.
Ultimately I would like to determine if this were to occur again, how can I mitigate against this enough to be able to manage the devices.
OSPF adjacencies are also formed across the EAPS rings, the implication here being the if the rate limits are set to low this will bring down the adjacencys.
So I have a number thoughts I would interested if this community would comment on
Ultimately I would like to determine if this were to occur again, how can I mitigate against this enough to be able to manage the devices.
OSPF adjacencies are also formed across the EAPS rings, the implication here being the if the rate limits are set to low this will bring down the adjacencys.
So I have a number thoughts I would interested if this community would comment on
- In a loop situation OSPF control traffic will also be looped and rate limited, so does rate limiting provide any advantage at all ?
How can I determine the correct level to set the limits ? I cannot afford a trial and error approach. The command "show port utilisation" only shows peak. Functionality would be improved here if I could see peak Muticast, and Peak Broadcast & peak unknown.
Using SNMP, SNMP is able to report on multicast and broadcast. Now there are a number of values that can be read via SNMP, are these suitable to determine the values used by the rate limiters.
4 REPLIES 4
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Get Direct Link
- Report Inappropriate Content
‎04-24-2017 10:47 AM
I would recommend upgrading to 16.1 so you can use the log action to find a good number. If you can't upgrade then you should be able to use the "show port statistics" command to at least look at the multicast and Broadcast.
Hope this helps
Hope this helps
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Get Direct Link
- Report Inappropriate Content
‎04-24-2017 07:19 AM
Hi Thank you for this, I have read the article
previously, but my switches do seem to lack the "out actions " options, the code is 15.3.4.6
* LAB-XXX-CORE-BD8810.1 # configure ports 1 rate-limit flood broadcast 100000 ?
Execute the command
* LAB-XXX--CORE-BD8810.1 # configure ports 1 rate-limit flood broadcast 100000 * LAB-XXX-CORE-BD8810.4 # configure port 1 rate-limit flood broadcast 1000 out-actions log
^
%% Invalid input detected at '^' marker. I can only assume this option was added in a later code release.
Regards
Simon
previously, but my switches do seem to lack the "out actions " options, the code is 15.3.4.6
* LAB-XXX-CORE-BD8810.1 # configure ports 1 rate-limit flood broadcast 100000 ?
* LAB-XXX--CORE-BD8810.1 # configure ports 1 rate-limit flood broadcast 100000 * LAB-XXX-CORE-BD8810.4 # configure port 1 rate-limit flood broadcast 1000 out-actions log
^
%% Invalid input detected at '^' marker. I can only assume this option was added in a later code release.
Regards
Simon
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Get Direct Link
- Report Inappropriate Content
‎04-24-2017 07:19 AM
Yes, it was added in EXOS 16.1.
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Get Direct Link
- Report Inappropriate Content
‎04-24-2017 07:04 AM
Hi Simon,
you can use
show ports <PORTLIST> rate-limit flood no-refreshto check how much flooded data is seen on the ports, and if the flood rate is exceeded.
In general, you should be able to use a limit sufficiently high to not disrupt normal usage, but that still allows spare CPU on the switches and spare bandwidth on the links to manage the switches during a broadcast storm. You should use data from your reporting tools to determine the broadcast and multicast traffic levels seen in your network.
You might want to take a look at the GTAC Knowledge article What Are the Recommended Broadcast, Multicast, and Unknown Unicast Rate-Limit Thresholds for EXOS?.
Since EXOS 16.1, you can just log violation of rate-limit flood:
Thanks,
Erik
you can use
show ports <PORTLIST> rate-limit flood no-refreshto check how much flooded data is seen on the ports, and if the flood rate is exceeded.
In general, you should be able to use a limit sufficiently high to not disrupt normal usage, but that still allows spare CPU on the switches and spare bandwidth on the links to manage the switches during a broadcast storm. You should use data from your reporting tools to determine the broadcast and multicast traffic levels seen in your network.
You might want to take a look at the GTAC Knowledge article What Are the Recommended Broadcast, Multicast, and Unknown Unicast Rate-Limit Thresholds for EXOS?.
Since EXOS 16.1, you can just log violation of rate-limit flood:
The out-actions, log, trap, disable-port, and port_group options were added inExtremeXOS 16.1.For more information on how flood rate-limiting is implemented you can look at the GTAC Knowledge article How is rate-limit implemented on EXOS?.
Thanks,
Erik
