Storm Control Question

I have a question about Storm Control;

In the Solution Guide Vol II, Lab 4, it states the following;

When the threshold of unicast or broadcast traffic is exceeded, traffic in excess of the threshold is dropped.

However in the configuration guide, it states the following:

With each method, the port blocks traffic when the rising threshold is reached. The port remains blocked until the traffic rate drops below the falling threshold (if one is specified) and then resumes normal forwarding.

I try to validate which is correct- all traffic filter or just excessive traffic filtered - , but I found it difficult because the switch only logs when the filter kicks IN not when it kicks out. But from a "eye ball" test, no timestamp verification it appears that all traffic gets filtered.

*Note, I was testing the unicast storm control.

Comments

  • The 3560 config guide states the following under Understanding Storm Control in chapter 23:

     

    The graph in Figure 23-1 shows broadcast traffic patterns on an interface over a given period of time. The example can also be applied to multicast and unicast traffic. In this example, the broadcast traffic being forwarded exceeded the configured threshold between time intervals T1 and T2 and between T4 and T5. When the amount of specified traffic exceeds the threshold, all traffic of that kind is dropped for the next time period. Therefore, broadcast traffic is blocked during the intervals following T2 and T5.

     

    So it looks like ALL traffic is blocked for that traffic type in the next time interval and not just the EXCESSIVE traffic for that traffic type.

     

    Ben,

  • Hi There 1000BaseT,

    How were you testing? Was it ICMP traffic with large packets and a small timeout? Maybe your traffic stream was larger than the configured trafic rate (if it was really small) so all packets got dropped? I believe it should block traffic only when the rising threshold is reached (as per the mechanism described in the comment above) and if no falling threshold is configured then it should start forwarding again as soon as it drops below the rising threshold. Can you test again and post the results, I would be interested to see whats happening.

  • Here is why my first test consisted of:

     

    ·         Storm control configured for the switchport connected to R1s Fa0/0.   

     

    interface FastEthernet0/1

     switchport access vlan 12

     storm-control unicast level pps 350

     

    ·         Then from SW3,  I hammered that port with small pings with a short timeout.

     

    Rack15SW3#ping 192.10.1.1 repeat 500000000 time 0

     

     

    ·         Then from SW1 I attempted a few small pings into R1, with a long timeout.

     

    Rack15SW1#ping 192.10.1.1 timeout 5

     

    Type escape sequence to abort.

    Sending 5, 100-byte ICMP Echos to 192.10.1.1, timeout is 5 seconds:

     

    *Mar  1 23:55:04.847: %STORM_CONTROL-3-FILTERED: A Unicast storm detected on Fa0/1. A packet filter action has been applied on the                 interface.

    *Mar  1 23:55:08.874: %STORM_CONTROL-3-FILTERED: A Unicast storm detected on Fa0/1. A packet filter action has been applied on the                 interface..

    *Mar  1 23:55:12.900: %STORM_CONTROL-3-FILTERED: A Unicast storm detected on Fa0/1. A packet filter action has been applied on the                 interface..

    *Mar  1 23:55:14.913: %STORM_CONTROL-3-FILTERED: A Unicast storm detected on Fa0/1. A packet filter action has been applied on the                 interface.

    *Mar  1 23:55:17.933: %STORM_CONTROL-3-FILTERED: A Unicast storm detected on Fa0/1. A packet filter action has been applied on the                 interface..

    *Mar  1 23:55:19.947: %STORM_CONTROL-3-FILTERED: A Unicast storm detected on Fa0/1. A packet filter action has been applied on the                 interface.

    *Mar  1 23:55:23.973: %STORM_CONTROL-3-FILTERED: A Unicast storm detected on Fa0/1. A packet filter action has been applied on the                 interface..

    *Mar  1 23:55:28.000: %STORM_CONTROL-3-FILTERED: A Unicast storm detected on Fa0/1. A packet filter action has been applied on the                 interface..

    Success rate is 0 percent (0/5)

     

    >>>>>>>>>>>>>>>>>>>>>>>>>> 

     

    I just tried a different approach,

    That was pinging R1 form SW3 with a larger packet, with a 1 sec timeout

     

    Rack15SW3#ping 192.10.1.1 repeat 500000000 time 1 size 1500.

     

     

     

     

    This time I simply keep looking at the storm-control output,  its basically ON or OFF…not really any in between like I would expect if only exceeding traffic was getting dropped.

     

     

    Rack15SW1#show storm-control unicast

    Interface  Filter State   Upper        Lower        Current

    ---------  -------------  -----------  -----------  ----------

    Fa0/1      Forwarding         350 pps      350 pps        1 pps

    Rack15SW1#show storm-control unicast

    Interface  Filter State   Upper        Lower        Current

    ---------  -------------  -----------  -----------  ----------

    Fa0/1      Forwarding         350 pps      350 pps        2 pps

    Rack15SW1#show storm-control unicast

    Interface  Filter State   Upper        Lower        Current

    ---------  -------------  -----------  -----------  ----------

    Fa0/1      Blocking           350 pps      350 pps      365 pps

    Rack15SW1#

    *Mar  2 01:31:09.540: %STORM_CONTROL-3-FILTERED: A Unicast storm detected on Fa0/1. A packet filter action has been applied on the interface.

    Rack15SW1#show storm-control unicast

    Interface  Filter State   Upper        Lower        Current

    ---------  -------------  -----------  -----------  ----------

    Fa0/1      Forwarding         350 pps      350 pps        0 pps

    Rack15SW1#show storm-control unicast

    Interface  Filter State   Upper        Lower        Current

    ---------  -------------  -----------  -----------  ----------

    Fa0/1      Blocking           350 pps      350 pps      353 pps

    Rack15SW1#show storm-control unicast

    Interface  Filter State   Upper        Lower        Current

    ---------  -------------  -----------  -----------  ----------

    Fa0/1      Forwarding         350 pps      350 pps        1 pps

    Rack15SW1#

    *Mar  2 01:31:12.560: %STORM_CONTROL-3-FILTERED: A Unicast storm detected on Fa0/1. A packet filter action has been applied on the interface.

    Rack15SW1#show storm-control unicast

    Interface  Filter State   Upper        Lower        Current

    ---------  -------------  -----------  -----------  ----------

    Fa0/1      Forwarding         350 pps      350 pps        1 pps

    Rack15SW1#show storm-control unicast

    Interface  Filter State   Upper        Lower        Current

    ---------  -------------  -----------  -----------  ----------

    Fa0/1      Blocking           350 pps      350 pps      379 pps

    Rack15SW1#show storm-control unicast

    Interface  Filter State   Upper        Lower        Current

    ---------  -------------  -----------  -----------  ----------

    Fa0/1      Forwarding         350 pps      350 pps        2 pps

    Rack15SW1#

    *Mar  2 01:31:15.580: %STORM_CONTROL-3-FILTERED: A Unicast storm detected on Fa0/1. A packet filter action has been applied on the interface.

    Rack15SW1#show storm-control unicast

    Interface  Filter State   Upper        Lower        Current

    ---------  -------------  -----------  -----------  ----------

    Fa0/1      Forwarding         350 pps      350 pps        2 pps

    Rack15SW1#

    *Mar  2 01:31:18.600: %STORM_CONTROL-3-FILTERED: A Unicast storm detected on Fa0/1. A packet filter action has been applied on the interface.

    Rack15SW1#

     

     

    Based on this, it appears the port drops ALL traffic when the threshold is exceeded.

     

  • Hi There,

    In your first example, you may well be exceeding 350pps every interval. So every subsequent interval would be blocked. The problem with pings is that it should always block or always forward as the sending rate is constant.

    It might be clearer to try something like this:

    1. Get a baseline of how much traffic a certain ping produces on the storm-control interface. Say ping 192.10.1.1 size 1500 time 1 from R4. Lets say this equates to 1Mbps (no idea if thats even close :-))

    2. On the storm-control interface, use the interface bps command thats slightly higher than the baseline. (In this example maybe "storm-control unicast level bps 1010k")

    3. If done correctly, the interface should not block any traffic and all pings should be received.

    4. From another device (say R5) produce a short burst of pings to the same destination to take the interface over 1010k. 

    5. All pings from both sources should now fail for a short period while R5 sends its pings. Once it stops, R4's pings should start again exactly one interval after the last ping from R5.

    I found a good short description here. I think its well written.

    http://packetlife.net/blog/2008/nov/27/storm-control/

     

Sign In or Register to comment.