nts, shown on the graph as To, T1, and SO on. If the type of traffic being monitored does not surpass the configured threshold during a given interval, the next 200 ms interval is unaffected. In this example, when T1 is reached, the threshold has not been exceeded, SO the next interval (ending with T2) is unaffected. However, the configured threshold is exceeded during the T2 interval, SO the packets received during the next interval (T3) are dropped. The important distinction here is that dur- ing each interval, received packets or bytes are counted from the start of that interval only. Traffic is still monitored on the interface during the interval in which packets are being dropped (packets are received, but not passed on to other interfaces within the switch). If the packet rate again exceeds the configured threshold, packets for the next interval are again dropped. If, however, the number of packets received is below the configured threshold, as is the case in the interval T3 in Figure 18-2, packets are allowed for the next interval. Because packets are not received in a smooth pattern, understanding how storm con- trol works will help you understand why it may cause intermittent communication failures in normal applications on a healthy network. For example, if you were to Chapter 18: Catalyst 3750 Features Relevant packets bytes Threshold 200ms Figure 18-2. Actual storm-control function encounter a virus that sent enough broadcasts to trigger your configured storm con- trol, chances are that the port would stop forwarding all broadcasts because the threshold would constantly be exceeded. On the other hand, if you had a healthy network, but your normal broadcast traffic was hovering around the threshold, you would probably end up missing some broadcasts while passing others. Only by closely monitoring your switches can you be sure that you're not impeding normal traffic. If storm control is causing problems in an otherwise healthy network, you probably need to tune the storm-control parameters. Storm contro