Introduction

The first step in controlling broadcast and multicast traffic is to identify which devices are involved in a broadcast or multicast storm. The following protocols can send broadcast or multicast packets:

• Address Resolution Protocol (ARP)
• Open Shortest Path First (OSPF)
• IP Routing Information Protocol Version 1 (RIP1)
• Service Advertising Protocol (SAP)
• IPX Routing Information Protocol (RIP)
• NetWare Link Services Protocol (NLSP)
• AppleTalk Address Resolution Protocol (AARP)

After identifying the source of the broadcast or multicast storm, you must examine the packets to find out which protocol or application triggered the broadcast or multicast storm. For example, if a single device is responsible for a broadcast storm, you can examine the device's broadcast traffic to determine exactly what the device was doing. For example, you can find out what the device was looking for or what the device was announcing.

Broadcast or multicast storms are often caused by a fault that occurs during the device discovery process. For example, if an IPX-based printing environment has been misconfigured, a print driver client may continually send SAP packets to locate a specific print server. Unanswered broadcast or multicast requests usually indicate that a device is missing or has been misconfigured.

Examine the broadcast traffic on your company's network. Do you see numerous unanswered, repeat queries? Do you see protocols (such as IP RIP1, SAP, and IPX RIP) that just "blab" all day even when no other devices may be listening?

Or, is the majority of the broadcast and multicast traffic on your company's network purposeful? That is, does the broadcast and multicast traffic have a request-reply communication pattern? For example, are broadcast lookups answered?

Do broadcast packets contain meaningful information? For example, if a network has numerous routers, do broadcast packets contain routing update information?

Is the broadcast rate acceptable? Does your company's network need RIP updates every 30 seconds, or can you increase the interval to one minute?

BROADCAST/MULTICAST DOMAINS

If your company's network is experiencing excessive broadcast or multicast traffic, you should also check the scope of the broadcast or multicast domain. (A broadcast or multicast domain is the range of devices that are affected by a broadcast or a multicast packet.) Understanding broadcast and multicast domains can help you determine how harmful a broadcast storm can be from any point on the network.

The scope of a broadcast and multicast domain depends, to some degree, on the network design. For example, the picture below shows two networks, a switched network and a routed network:

On a switched network, Device 1 sends a broadcast or multicast packet that is propagated to all ports of the switch. (A typical layer-2 switch does not filter either broadcast or multicast traffic.)

On a routed network, however, a router does not forward broadcast traffic. If Device 1 sends a broadcast packet, only Device 2 and the router see the broadcast packet. If appropriate, the router processes the broadcast packet and sends a reply. Because the broadcast packet is not forwarded, it does not affect Devices 3 or 4.