Use these sections to identify and eliminate broadcast storms:
See "Broadcast Storms Reference" for additional conceptual and problem analysis detail.
A broadcast storm means that your network is overwhelmed with constant broadcast or multicast traffic. Broadcast storms can eventually lead to a complete loss of network connectivity as the packets proliferate.
Some devices, like the CoreBuilder 2500 and CoreBuilder 3500, have firewall protection against broadcast storms. If a certain broadcast transmit threshold is reached, the port drops all broadcast traffic. Firewalls are one of the best ways to protect your network against broadcast storms. Determine whether your network devices support this functionality.
"Broadcast Packets" and "Multicast Packets" are a normal part of your network's operation. To recognize a storm, you must be able to identify when broadcast and multicast traffic is abnormal for your network.
You may suspect that a broadcast storm is occurring when your network response times become extremely slow and network operations are timing out. As a broadcast storm progresses, users cannot log in to servers or access e-mail. As the storm worsens, the network becomes unusable.
When your network is operating normally, monitor the percentage of broadcast and multicast traffic. You can then use this data as a baseline to determine when broadcast and multicast traffic is too high.
The process of identifying the problem is discussed in "Identifying a Broadcast Storm".
Storms can occur if network equipment is faulty or configured incorrectly, if the Spanning Tree Protocol is not implemented correctly, or if poorly designed programs that generate broadcast or multicast traffic are used.
The process for solving the problem is discussed in these sections:
When identifying broadcast storms, use the following applications:
Using the Status Watch tools in Table 15, you can identify when and where a broadcast storm is occurring.
For the Broadcast Receive and Broadcast Transmit tools, if the value for receive utilization is less than 10 percent, Status Watch ignores the high rate of broadcast traffic. This way, a broadcast problem is not falsely triggered in Status Watch for a segment on which a majority of traffic is spanning tree or Routing Information Protocol (RIP) packets.
Follow these steps:
1 . Use the Summary View window to examine the Broadcast Transmit tool and Broadcast Receive tool to determine if any thresholds have been exceeded on your monitored devices.
2 . Examine the Asynchronous Transfer Mode (ATM), Ethernet, Fiber Distributed Data Interface (FDDI), and token ring utilization tools to determine if their reported rates are abnormally high. If so, traffic is flooding the network. See "Bandwidth Utilization" for more information.
3 . Search for "Ethernet Packet Loss" as an additional indicator that a broadcast storm is occurring. Increased collisions occur as the network becomes saturated.
After you set a baseline for normal network activity, you can set the Broadcast Transmit tool and Broadcast Receive tool thresholds to alert you when broadcast and multicast traffic is heavier than normal.
Using Traffix Manager, you can monitor all broadcast traffic to identify exactly which devices are generating broadcast traffic.
Follow these steps:
1 . Using the Select Database Traffic to Load dialog box, retrieve data to the Map using the 6-Hourly or Hourly data resolution.
Finer resolutions take longer to load from the database to the Map. However, they are more suitable for in-depth analysis of network traffic than the daily or weekly resolutions. For quicker retrieval of finer resolution data, select a shorter time range.
2 . Open the Protocol Selection dialog box and set all protocols to appear as Other:
3 . In the Map, select MAC Labels to display devices by their MAC addresses.
4 . Use the Find Objects tool to locate the broadcast MAC address ff:ff:ff:ff:ff:ff and select it from the Object List or Map.
5 . From the Display menu, select Show Conversations To and From to display all traffic that is going to and from the broadcast MAC address.
6 . Set the Map all objects button to Map connected objects.
7 . To create a list of the devices that are sending broadcast traffic to the broadcast address, right-click the Traffix group and select Visible Device List.
8 . To generate a baseline of broadcast traffic:
9 . To generate a list of the Top-N sources of broadcast traffic:
Because broadcast storms can ultimately cause your whole network to become unavailable, take action immediately to disable the offending interface. You can enable the interface again after you have corrected the problem.
Use Address Tracker to locate the interface that is causing the broadcast storm. Use Device View to disable the port.
Follow these steps:
1 . In the Find Address window, enter the address of the interface that seems to be receiving the broadcast traffic.
2 . Click Find Now.
3 . Use Transcend Central to launch Device View and disable the port.
Disabling the port stops the broadcast storm before it interferes with all vital network traffic. You can re-enable this interface using Device View or the device's console later.
Spanning Tree does not cause broadcast storms, but a loop in your Spanning Tree topology can create data that looks like a storm. A loop can occur in your topology if:
Use Device View to disable any Spanning Tree port that has a repeater attached to it and to correct Spanning Tree misconfigurations.
To correct Spanning Tree misconfigurations, use Device View to disable Spanning Tree Protocol (STP) for a port on a SuperStack® II Switch 1000, Switch 3000, Switch 3000 10/100, Switch 9000SX, Desktop Switch, LinkBuilder® FMS II Bridge/Management Module, or CoreBuilder 6000.
To disable the STP port state for a port on a SuperStack II switch:
1 . Select a port and click the right mouse button.
2 . From the shortcut menu, select Configure.
3 . In the Port section, click the STP tab.
4 . From the STP Port State list box, select Disabled.
5 . Click Apply.
To disable the STP port state for a port on a LinkBuilder FMS II Bridge/Management Module:
1 . Double-click the module.
2 . From the shortcut menu, select Configure Bridge.
3 . In the Port section, click the STP tab.
This section explains terms that are relevant to broadcast storms and provides additional conceptual and problem analysis detail.
Broadcast packets, which are a normal part of network operation, are transmitted by a device to a broadcast address. For example, IP networks use broadcasts to resolve network addresses using Address Resolution Protocol (ARP); IPX networks use a large number of broadcast packets to operate most effectively.
Problems arise when broadcast packets endlessly propagate throughout the network, which increases the traffic volume on your network and the CPU time that each host spends processing and discarding unwanted broadcast packets.
Multicast packets, which are a normal part of network operation, are transmitted by a device to a multicast group address. Hosts that want to receive the packets indicate that they want to be members of the multicast group, and then multicast packets are distributed to that group. For example, multicast packets support the Spanning Tree Protocol. Multicast applications and underlying multicast protocols control multimedia traffic and shield hosts from processing unnecessary broadcast traffic. However, multicast traffic can also cause storms that saturate your network.