Storm control enables the device to monitor traffic levels and to drop broadcast, multicast, and unknown unicast packets when a specified traffic level—called the storm control level or storm control bandwidth—is exceeded, thus preventing packets from proliferating and degrading the LAN. Storm control is enabled by default on ELS platforms and disabled by default on non-ELS platforms.
In case every traffic that gets dropped at a port is assumed to be happening because of storm control enabled without considering the bandwidth as its base criterion, the control plane will be flooded with notifications of the same which is not an ideal situation. This document explains briefly the importance of storm control and how to prevent erroneous storm-control logs.
The log messages below may be visible on ports that have storm control enabled:
l2ald[1903]: %DAEMON-1-L2ALD_ST_CTL_IN_EFFECT: xe-0/0/0: storm control in effect on the port
l2ald[1903]: %DAEMON-1-L2ALD_ST_CTL_IN_EFFECT: xe-0/0/1: storm control in effect on the port
l2ald[1903]: %DAEMON-1-L2ALD_ST_CTL_IN_EFFECT: xe-0/0/0: storm control in effect on the port
l2ald[1903]: %DAEMON-1-L2ALD_ST_CTL_IN_EFFECT: xe-0/0/1: storm control in effect on the port
Although these messages are very important in preventing outage and CPU over utilization on the device, but an erroneous message would give a false notification making it difficult to differentiate between the real threats.
-
Disable Storm Control
Although this is not an advised suggestion, only in cases where there is no traffic being passed through the specific port and it is practically unused, one may choose this option in order to prevent log flooding and fake alerts.
-
Configure Firewall filters/ policers when you have disabled "storm control" to keep track of drop count.
Example configuration below:
>set firewall family ethernet-switching filter burst term t1 then count l2-traffic
>set firewall family ethernet-switching filter burst term t1 then policer l2-traffic
>set firewall family ethernet-switching filter burst term t2 then accept
>set firewall policer l2-traffic if-exceeding bandwidth-limit <xx>
>set firewall policer l2-traffic if-exceeding burst-size-limit <xx>
>set firewall policer l2-traffic then discard
>set firewall family bridge filter l2_filter term t1 from traffic-type unknown-unicast
>set firewall family bridge filter l2_filter term t2 from traffic-type multicast
>set firewall family bridge filter l2_filter term t3 from traffic-type broadcast <-- Considers BUM traffic in this example
>set firewall family bridge filter l2_filter term t1 then policer storm_cntl
>set firewall family bridge filter l2_filter term t2 then policer storm_cntl
>set firewall family bridge filter l2_filter term t3 then policer storm_cntl
>set firewall policer storm_cntl filter-specific if-exceeding bandwidth-limit 15m
-
Enhanced Storm Control:
This is the best solution to get rid of erroneous alerts while making sure that you do not have to disable "storm control". The keyword enhanced makes sure that only when storm control is being hit, the logs are generated. Thus, preventing erroneous logs and false alarms.
user@host# set forwarding-options storm-control ?
Possible completions:
<[Enter]> Execute this command
+ apply-groups Groups from which to inherit configuration data
+ apply-groups-except Don't inherit configuration data from these groups
enhanced Enable enhanced storm control feature
| Pipe through a command​
user@host# set forwarding-options storm-control enhanced​
NOTE: This enhanced storm control feature is available starting in the following releases: 14.1X53-D48, 17.4R3, 18.1R3-S7,18.2R3-S1,18.3R3, 18.4R2-S2, 18.4R2-S5, 18.4R3, 19.1R2,19.2R2,19.3R1.
***WARNING: Please be aware that disabling storm-control might not be an ideal option for certain networks. If the other solution does not work for you, please contact JTAC for your assistance