 the ability to specify a rising threshold and a falling thresh- old. When the rising threshold is passed, the configured type of packets will be dropped for the next interval. When the falling threshold is passed, the next interval will be allowed to pass the configured type of packets again. Figure 18-3 shows an example of the effects of configuring rising and falling thresholds. The rising threshold is set higher than the falling threshold. This has a dramatic impact on the number of intervals dropping packets. When T2 exceeds the rising threshold, T3 drops packets, just as it did when only one threshold was config- ured. T3 does not exceed the rising threshold, but because it exceeds the falling threshold, packets are again dropped in T4. Once the rising threshold has been exceeded, traffic of the configured type will continue to be dropped as long as the falling threshold is exceeded. It is not until the interval ending at T5 that the level finally falls below the falling threshold, thus allowing packets of the configured type to be forwarded again during the next interval. The falling threshold is configured after the rising threshold. If no value is entered, the falling threshold is the same as the rising threshold: 3750(config-if)# storm-control broadcast level bps 100 ? <0.0 - 10000000000.0 [k|m|g] Enter falling threshold Here, I've configured the same thresholds using different forms of the same numbers. Either way is valid: 3750(config-if)# storm-control broadcast level bps 100000 90000 3750(config-if)# storm-control broadcast level bps 100m 90k Chapter 18: Catalyst 3750 Features Relevant packets bytes Rising Falling 200ms Figure 18-3. Rising and falling thresholds I think the simplest way to configure storm control is with percentages. This is also the only supported method for older versions of IOS: 3750(config-if)# storm-control multicast level 40.5 30 Be careful when configuring multicast storm control. When multicast packets are suppressed, routing protocols that use multicasts will be affected. C