When a device on a network generates a message, it's one of three types - a unicast, a multicast, or a broadcast. A unicast is a message intended for one other host; a multicast is intended for a group of hosts; a broadcast is intended for every host that can possibly receive it - and that's where the trouble can begin.
Why? Because not every other host needs or wants to receive that message, and if "Host A" should not receive broadcasts sent by "Host B", we should configure the network accordingly. Everything we do on a network has a cost in performance, and if a host is regularly processing messages that it doesn't need, that will result in a decline in that host's performance. That decline may be slight, but if the host in question is receiving many unnecessary broadcasts, the decline in performance may be significant. Worse, the impact to our network as a whole may be significant as well.
Broadcasts tend to result in more broadcasts, and if hosts on the network continue to answers broadcasts with broadcasts, we end up with a broadcast storm. Broadcast storms start small, but just like a snowball, they can end up being very big - so big that normal network operations are compromised and/or prevented!
Most of the switches now allow network admins to enable or disable broadcast/multicast storm control and to set a threshold level at which the control applies. These units allow individual port control. This means if the rate at which broadcasts arrive at a port exceeds a defined limit, the switch will block such packets at that port until the rate decreases to a lower threshold. Switches often auto-negotiate baud rate and on such devices broadcast storm control is scaled with the baud rate.
Precautions you can take are:
- Check to see if there is more than one frame type on the servers, routers, etc. If there are, verify if all the applications and /or protocols on the network can run on a single frame type. Using a single frame type reduces the redundant broadcast traffic.
- Check to see if your network is using multiple protocols. Try configuring your applications to one single protocol. Minimizing the number of protocols can lead to fewer broadcasts.
- If possible, disable the spanning tree bridge protocol. Any misconfiguration of the same can lead to a broadcast storm.
- Make sure your WAN/Edge network devices have spoofing and /or filtering enabled. Almost every router/switch today has the functionality for storm control.
- Use network analyzers to perform network baseline analysis. It will define the type of protocols implemented, identify the problematic nodes/areas and also provide other pertinent information relating to network performance at all the layers.
- Enable QoS on your routers. The mapping of the protocol is very important. Packet shapers do a good job of defining the QoS policies by analyzing the network traffic based on ToS and frames.
