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.

1. Storm Control enabled 
2. Every small traffic drop starts getting counted as a drop triggered due to the storm control feature.

1. 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.

2. 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

3. 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​