Controlling
Broadcasts and Multicasts
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. |
