Computer Lab Screen Broadcast: From Slideshow to Multicast Tuning

Sixty student machines in the lab; the teacher clicks "broadcast screen," and the front rows are fine while the back two look like a slideshow — frame rate drops to single digits and the mouse cursor trails outlines. The teacher blames the computers, the IT teacher blames the cabling, and the network admin says "the switch brand doesn't support it." The afternoon I got called in, the room was a loop of "laggy?" "yeah."

Conclusion first: screen-broadcast software defaults to broadcast or sloppy multicast, and a layer-2 loop or dumb switches without IGMP snooping will drag the whole network down. The fix isn't buying a "more expensive broadcast server"; it's changing the traffic from "everyone is forced to listen" to "only the ports that should hear it get it forwarded."

On-site topology and symptoms

Teacher machine + broadcast server: wired into access switch A
Student machines in two rows: up-linked through access switches A and B to the core (or distribution)
Broadcast software: screen mirroring + file distribution; at peak, the teacher machine's outbound traffic can exceed 100 Mbps
Symptoms: teacher machine's ping to the gateway jitters during broadcast; student browsers lag together; kill the broadcast and everything recovers instantly

First, rule out "the student CPUs are weak": in Task Manager the broadcast client isn't maxing CPU, but NIC interrupts and retransmit counters are climbing. Then rule out "one bad cable": swap ports and cables, and the lag follows whether broadcast is on, not which cable is in use.

Capture traffic: broadcast is the killer

With the broadcast running, mirror one access port to a laptop:

# simplified observations
- lots of packets destined for 255.255.255.255 or the subnet broadcast
- some modes use 239.x.x.x multicast, but the switch floods it like broadcast
- student machines "catch the ball" on hard interrupts even without decoding

The vendor docs often say "multicast supported," yet the on-site config page has "compatibility mode / broadcast mode" checked — a default inherited from the old hub era. The bigger the broadcast domain, the more victims.

Three levers: software, layer 2, links

1. Software side: force multicast, turn off broadcast compatibility

In the broadcast console (name varies by vendor), confirm:

Transport mode: multicast, not "auto"
The multicast address sits in a managed 239.0.0.0/8 range and is written into the change ticket, so it doesn't collide with other systems
Frame rate and resolution: 1080p at 15–20 fps is usually enough for teaching and saves an order of magnitude in bursts over 4K@30
Stagger file distribution away from screen-mirror peaks; push big images via an HTTP cache or local repo instead of the broadcast channel

After the change, verify only that the teacher machine's egress stopped hammering broadcast addresses — don't declare victory early.

2. Switches: IGMP snooping + querier

On access and distribution (if present), enable:

IGMP snooping: builds the multicast forwarding table from join/leave messages instead of flooding multicast as broadcast
An IGMP querier somewhere in the L2 network (a layer-3 interface or a designated switch), or the snooping table never learns fully
Port isolation between student ports (re-open by group if teaching needs inter-client traffic); at minimum kill loops — disable students daisy-chaining their own little switches

Sketch (commands vary by brand; the logic is the same):

igmp-snooping enable
igmp-snooping vlan 20 enable
# with no L3 multicast routing, enable pim on the SVI or at least guarantee a querier

If the room has a loop, I run STP/loop detection for a night before touching broadcast settings. Broadcast storms stacked on multicast flooding make every parameter look like it did nothing.

3. Uplinks and QoS: give broadcast a less congested path

Teacher machine port and uplinks:

Fix the teacher port at gigabit full-duplex and disable EEE power-saving (EEE on some budget labs causes burst throughput drops)
Don't share the uplink with a heavily congested "everyone downloads" egress; keep lab traffic inside the building
When possible, give broadcast multicast a simple priority queue so printing and updates don't fight it

Acceptance that reads like engineering, not vibes

Ten minutes of broadcast running; core CPU / switch-chip utilization no longer pegged
Sample 10 student machines; picture latency acceptable (we settled into a teaching-usable range under ~0.5s perceived)
Non-broadcast terminals in the same room see ping-to-gateway jitter back to normal
The change ticket records: multicast address, VLAN, snooping/querier locations, and rollback steps (where the switch back to broadcast mode lives)

Post-mortem

Lab broadcast problems are rarely a single "software is broken" cause. Far more common: default broadcast + unmanaged layer 2 + teaching traffic mixed with office downloads. The network engineer's job is to translate "it's laggy" into a measurable packet path, then close the loop on all three layers at once: software parameters, the layer-2 forwarding table, and link capacity.

At the end-of-term check, the teacher asked one thing: "can it just stay like this?" Yes — as long as nobody factory-resets the switches over the summer and quietly turns IGMP snooping back off. Config backups and a start-of-term inspection checklist matter more than the broadcast license.

Blog