Practically every network protocol creates
broadcast traffic for one reason or another. For example, consider the
amount of broadcast traffic AppleTalk generates. AppleTalk routers
generate routing updates in the form of broadcast frames every ten
seconds! Broadcasts go to all devices in the broadcast domain and must
be processed by the receiving devices. Further, many multimedia
applications create broadcast and multicast frames that get distributed
across the broadcast domain.
So why do network administrators dislike
broadcast traffic? Broadcasts are necessary to support protocol
operations and therefore are overhead frames in the network. With the
exception of multimedia-based traffic, broadcast frames rarely transport
user data. Since broadcasts tend not to carry user data, they consume
bandwidth in the network, resulting in a reduction of the bandwidth for productive traffic.
Broadcasts also have a profound effect on
the performance of workstations. Any broadcast received by a workstation
interrupts the CPU and prevents it from working on user applications. As
the number of broadcasts per second increases at the interface,
effective CPU utilization diminishes. The actual level of degradation
depends upon the applications running in the workstation, the type of
network interface card and drivers, the operating system, and the
workstation platform.
If broadcasts are creating problems in
the network, creating smaller broadcast domains can mitigate the
negative effects. In VLANs, this means creating additional VLANs and
attaching fewer devices to each one. The effectiveness of this action
depends upon the source of the broadcast. If your broadcasts come from a
local server, you might simply need to isolate the server in another
domain. If your broadcasts come from end stations, creating multiple
domains might help to reduce the number of broadcasts in each domain.