Storm Control

A traffic storm occurs when packets flood the LAN, creating excessive traffic and degrading network performance. You can use the traffic storm control feature to prevent disruptions on Layer 2 ports by a broadcast, multicast, or unicast traffic storm on physical interfaces.

Traffic storm control (also called traffic suppression) allows you to monitor the levels of the incoming broadcast, multicast, and unicast traffic over a 1-second interval. During this interval, the traffic level, which is a percentage of the total available bandwidth of the port, is compared with the traffic storm control level that you configured. When the ingress traffic reaches the traffic storm control level that is configured on the port, traffic storm control drops the traffic until the interval ends.

The traffic storm control threshold numbers and the time interval allow the traffic storm control
algorithm to work with different levels of granularity. A higher threshold allows more packets to pass through. The traffic storm control circuitry monitors packets that pass from a Layer 2 interface to the switching bus. Using the Individual/Group bit in the packet destination address, the circuitry determines if the packet is unicast or broadcast, tracks the current count of packets within the 1-second interval, and filters out subsequent packets when a threshold is reached.

Traffic storm control uses a bandwidth-based method to measure traffic. You set the percentage of total available bandwidth that the controlled traffic can use. Because packets do not arrive at uniform intervals, the 1-second interval can affect the behavior of traffic storm control.

The following are examples of traffic storm control behavior;

• If you enable broadcast traffic storm control, and broadcast traffic exceeds the level within the 1-second interval, traffic storm control drops all broadcast traffic until the end of the interval.
• If you enable broadcast and multicast traffic storm control, and the combined broadcast and multicast traffic exceeds the level within the 1-second interval, traffic storm control drops all broadcast and multicast traffic until the end of the interval.
• If you enable broadcast and multicast traffic storm control, and broadcast traffic exceeds the level within the 1-second interval, traffic storm control drops all broadcast and multicast traffic until the end of the interval.
• If you enable broadcast and multicast traffic storm control, and multicast traffic exceeds the level within the 1-second interval, traffic storm control drops all broadcast and multicast traffic until the end of the interval.

When configuring the traffic storm control level, note the following guidelines and limitations;

• You can configure traffic storm control on a port-channel interface.
• Do not configure traffic storm control on interfaces that are members of a port-channel interface. Configuring traffic storm control on interfaces that are configured as members of a port channel puts the ports into a suspended state.
• Specify the level as a percentage of the total interface bandwidth;
  – The level can be from 0 to 100.
  – The optional fraction of a level can be from 0 to 99.
  – 100 percent means no traffic storm control.
  – 0.0 percent suppresses all traffic.

Because of hardware limitations and the method by which packets of different sizes are  counted, the level percentage is an approximation. Depending on the sizes of the frames that make up the incoming traffic, the actual enforced level might differ from the configured level by several percentage points.

Configuring Storm Control

You configure storm control on a per interface bases as follows;

Switch(config-if)#storm-control ?
action     Action to take for storm-control
broadcast  Broadcast address storm control
multicast  Multicast address storm control
unicast    Unicast address storm control

Switch(config-if)#storm-control action ?
shutdown  Shutdown this interface if a storm occurs
trap      Send SNMP trap if a storm occurs

Switch(config-if)#storm-control broadcast level ?
<0.00 – 100.00>  Enter rising threshold
bps              Enter suppression level in bits per second
pps              Enter suppression level in packets per second

Best practice for implementing storm control, you should set the Multicast limit higher than the Broadcast limit. Or at least set them equal. You should never set the Multicast level to be less than the Broadcast level, otherwise, either Broadcasts and Multicasts will be limited by the Multicast level. This will make it pointless that the Storm-Control configuration for the Broadcast level are in place!

Unicast Flooding

LAN switches use forwarding tables (MAC Address Table or Content Addressable Memory (CAM) tables) to direct traffic to specific ports based on the VLAN number and the destination MAC address of the frame. When there is no entry corresponding to the frame’s destination MAC address in the incoming VLAN, the (unicast) frame will be sent to all forwarding ports within the respective VLAN, which causes flooding.

Limited flooding is part of the normal switching process. There are situations, however, when continuous flooding can cause adverse performance effects on the network. Some ports do not require flooding. A port that has only manually assigned MAC addresses and that does not have a network device connected to that port other than the configured MAC address does not need to receive flooded packets. Also a port security– enabled port with a configured secure MAC address or port does not need to receive unknown unicast flooding if the port has already learned the maximum number of MAC addresses.

The very cause of flooding is that destination MAC address of the packet is not in the L2 forwarding table of the switch. In this case the packet will be flooded out of all forwarding ports in its VLAN (except the port it was received on). There are three main causes for unicast flooding;

1. Asymmetric Routing – Packets follow different paths depending on the direction. Large amounts of flooded traffic might saturate low-bandwidth links causing network performance issues or complete connectivity outage to devices connected across such low-bandwidth links. Approaches to limit the flooding caused by asymmetric routing;
   – Bring the router’s ARP timeout and the switches’ forwarding table-aging time close to each other. This will cause the ARP packets to be broadcast. Relearning must occur before the L2 forwarding table entry ages out.
2. Spanning-Tree Protocol Topology Changes – Topology Change Notification (TCN) is designed to correct forwarding tables after the forwarding topology has changed. This is necessary to avoid a connectivity outage, as after a topology change some destinations previously accessible via particular ports might become accessible via different ports. TCN operates by shortening the forwarding table aging time, such that if the address is not relearned, it will age out and flooding will occur. TCNs are triggered by a port that is transitioning to or from the forwarding state. After the TCN, even if the particular  destination MAC address has aged out, flooding should not happen for long in most cases since the address will be relearned. The issue might arise when TCNs are occurring repeatedly with short intervals. The switches will constantly be fast-aging their forwarding tables so flooding will be nearly constant. Ports with the STP portfast feature enabled will not cause TCNs when going to or from the forwarding state. Configuration of portfast on all end-device ports (such as printers, PCs, servers, and so on) should limit TCNs to a low amount.
3. Forwarding Table Overflow – Overflow of the switch forwarding table can result in new addresses cannot be learned and packets destined to such addresses are flooded until some space becomes available in the forwarding table. Forwarding table exhaustion can also be caused by an attack on the network where one host starts generating frames each sourced with different MAC address. This will tie up all the forwarding table resources. Once the forwarding tables become saturated, other traffic will be flooded because new learning cannot occur. This kind of attack can be detected by examining the switch forwarding table. Most of the MAC addresses will point to the same port or group of ports. Such attacks can be prevented by limiting the number of MAC addresses learned on untrusted ports by using the port security feature. The following port command will help to prevent such an attack;
   – Switch(config-if)#switchport port-security violation restrict

The unicast flood-blocking feature prevents the forwarding of unicast flood traffic on unnecessary ports. Restricting the amount of traffic on a per-port basis adds a level of security to the network and prevents network devices from unnecessarily processing nondirected packets. Switches can restrict flooding of unknown multicast MAC-addressed traffic on a per-port basis, in addition to restricting flooding of unknown unicast destination MAC addresses.

Use the following commands to accomplish flood-blocking at the interface level;

Switch(config-if)#switchport block {unicast | multicast}