Controlling Broadcasts and Multicasts

Controlling Broadcasts and Multicasts


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?


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.

Source & Credit to :

104 thoughts on “Controlling Broadcasts and Multicasts

  1. Just building a web page and have some images that will need resizing. I don’t wish to use the MS image editor that now appears to be part of the MS Office package under the regime on my new Windows 7 personal computer – so wonder if anyone knows of a straightforward non-MS tool for re-jigging photos ??

  2. I noticed that the bounce rate on my sites is pretty high – for most visits it is 100%. I believe my content is relevant to the key phrases I am discovered for. What do you believe may be the problem?! What exactly is a normal bounce rate for you?. Help !

Leave a Reply

Your email address will not be published.