Why does a high volume of broadcast traffic degrade overall LAN performance?

Introduction / Context:
Broadcasts are frames addressed to all nodes on a broadcast domain (e.g., IPv4 ARP requests or certain service announcements). While essential for some protocols, excessive broadcasts create CPU and bus overhead on every endpoint and on Layer-2 infrastructure, reducing effective throughput for useful unicast traffic.

Given Data / Assumptions:

• A shared Ethernet or switched LAN with one or more broadcast domains.
• High broadcast rates caused by chatty protocols, misconfiguration, or storms.
• Endpoints must receive Layer-2 broadcasts by design.

Concept / Approach:

Unlike unicast, which is delivered only to the addressed host, broadcasts are delivered to all hosts in the VLAN/broadcast domain. Each host’s NIC and OS networking stack must interrupt, DMA, or otherwise handle the broadcast frame long enough to decide whether to pass it up or drop it. This per-host processing scales linearly with the number of endpoints and directly competes with normal application traffic for CPU and interrupt time.

Step-by-Step Solution:

Verification / Alternative check:

Monitoring tools (SPAN/mirror ports) show rising CPU on endpoints and elevated switch counters (broadcast storms). Limiting broadcasts or segmenting VLANs restores performance, confirming causality.

Why Other Options Are Wrong:

Acknowledgements are not required for Layer-2 broadcasts; Ethernet does not solicit per-host ACKs.

Transmission lockout until ACK: Not how Ethernet works.

Automatically routed to every segment: Routers block broadcasts between subnets by default.

None of the above: Incorrect because endpoint processing is the real reason.

Common Pitfalls:

Assuming switches “eat” broadcasts; they must flood within the VLAN. Confusing broadcast with multicast or unicast flooding behavior.

Final Answer:

Every computer on the network must process each broadcast message