Multicast Networking Explained: How It Works

Picture 131 million people watching Eurovision simultaneously online. Somewhere, a server has to send each of them a copy of the same video stream — the same bytes, over and over, to every single viewer. That's not just expensive. At scale, it's genuinely absurd. The bandwidth required to replicate a single high-bitrate stream to that many destinations is the kind of number that makes infrastructure engineers reach for antacids.

This is the problem multicast was designed to solve. And in a recent video, the creator behind apalrd's adventures walks through how multicast actually works — not just conceptually, but hands-on, with live Wireshark captures, FFmpeg commands, and a router running FRRouting (FRR). It's a 26-minute deep dive that earns its runtime.

One copy in, many copies out

The core idea behind multicast is elegant: instead of a server generating millions of identical packets, it sends one. The network itself — switches and routers — handles duplication as the stream fans out toward whoever's actually listening.

As the video explains: "Instead of sending 131 million copies from the server down to each possible destination, instead we send one copy out from the server. The router then at the next layer sees I need to send maybe five copies out different paths, etc., all the way down the tree until we have 131 million copies at the very end."

That shift in where duplication happens is what makes multicast so bandwidth-efficient. The bottleneck moves from the source to the edge — which is exactly where you want it.

But multicast isn't magic. The network only knows to send a stream somewhere if devices request it, and that's where things get interesting.

Tree pruning and listener discovery

Ethernet networks are trees by design — Spanning Tree Protocol enforces that structure. Multicast takes advantage of it. If you know which branches of the tree contain devices that actually want a stream, you can prune every branch that doesn't. No unnecessary traffic, no wasted airtime on your Wi-Fi.

The mechanism that makes pruning possible is called Multicast Listener Discovery (MLD) in IPv6, or IGMP in legacy IPv4. Devices periodically broadcast "I want this stream" reports to the network. Switches that support IGMP/MLD snooping read those reports and update their forwarding tables accordingly — ports that haven't subscribed to a multicast group simply don't receive those packets.

The video demonstrates this live: before launching a video player, Wireshark shows almost no multicast traffic. The moment the player opens and sends an MLD report, the stream floods in. Close the player, wait for the switch to time out that port, and the packets stop. The network is doing exactly what it should.

This behavior matters most on Wi-Fi. Wireless spectrum is shared, and flooding it with multicast streams nobody asked for is a real performance problem. Proper MLD/IGMP snooping keeps that traffic contained to devices that actually need it.

Where multicast actually gets used

Here's the honest part of the story: most of us never encounter multicast in the wild, and there are good reasons for that.

The video identifies two niches where large-scale routed multicast genuinely earns its complexity. The first is live video — especially in broadcast production environments where uncompressed feeds are enormous, or in IPTV systems where replication at the head end would be catastrophically expensive. The second is high-frequency trading. "If we had to replicate the packet to send to each destination, they would possibly receive it at a different time because it took us nanoseconds to actually send those packets — that could be unfair." Multicast delivers market data to all subscribers simultaneously, eliminating even nanosecond-scale latency advantages between trading firms.

For the rest of us — home labs, small offices, campus networks — multicast is mostly the invisible plumbing behind mDNS (how your printer magically appears when you plug it in) and IPv6 neighbor discovery. The video makes a fair point: properly filtering mDNS via multicast snooping sounds great in theory, but if 99 out of 100 devices on your network speak mDNS anyway, you're adding control-plane overhead to save basically nothing.

True routed multicast — streaming across subnets and VLANs — only makes sense when you have enough bandwidth demand to justify the setup complexity.

Setting it up: FFmpeg + FRRouting

If you do have a use case, the video's practical section is where it gets genuinely useful. The setup uses FFmpeg to encode a video source as an MPEG transport stream and push it to a multicast IPv6 address. FFmpeg's format support is broad enough to cover HLS streams, DVB devices, files, and basically anything else digital video can be encoded as — making it a reasonable universal entry point regardless of your source.

The multicast address format itself carries meaningful information. In IPv6, multicast addresses start with FF, followed by digits that encode the address type (well-known, source-specific, etc.) and the scope — how far the stream should travel. Scope 2 is link-local (same VLAN, one hop only). Scope 5 is site-local (your whole house or campus). The video demonstrates the practical consequence of scope: streaming to an FF02 address works fine on a single subnet, but the moment you try to route it across a router, it dies — you need FF35 (source-specific, site-scoped) and a higher hop limit.

For cross-subnet routing, the video deploys FRRouting on a small multi-port mini PC, using its PIM (Protocol Independent Multicast) support to handle MLD and build the multicast routing table. The result: ip6mroute shows the stream arriving on one interface and forwarding out another, with the router pruning interfaces that have no subscribers — "even if your switches don't support MLDD or IGMP snooping, the router still does."

One real-world caveat the video is upfront about: popular router distributions like OPNsense include FRR but haven't compiled in PIM support. You'd need vanilla Debian Linux or OpenWRT (with individual daemons installed separately) to get this working today. That's a genuine friction point for anyone hoping to bolt multicast onto an existing home router setup without diving deeper.

The bigger picture

What the video is really demonstrating is a networking primitive that the consumer internet largely bypassed. The rise of CDNs — content delivery networks that push cached copies of content geographically close to users — solved the same scale problem multicast was designed for, and did it in a way that works over the existing unicast internet without requiring every ISP in the chain to support multicast routing. That's why multicast IPTV is common in Europe (where ISPs control the entire delivery path from head end to home) but never took off on the open internet.

For home labs and curious engineers, the stack the video describes — FFmpeg pushing MPEG-TS to a multicast group, FRR routing it across subnets, and IGMP/MLD snooping keeping the traffic contained — is real, functional, and surprisingly approachable once you understand the address scoping rules and the backwards routing logic (you route away from the source, not toward the destination, which takes a minute to sit right in your brain).

The creator's next stated goal is extending this to a GPON (passive optical network) setup, building out a mock ISP IPTV system complete with multicast-to-unicast conversion for end devices — which is exactly how the major European IPTV providers actually work. Whether that project lands is worth watching.

And somewhere in a corner of the video, there's a 1989 PAL television that someone is hoping to feed analog RF signals derived from a multicast stream. Which is either the most elaborate way to watch TV ever conceived, or the perfect use case — depending on how you feel about the kitchen needing a 35-year-old CRT.

---

— Tyler Nakamura, Consumer Tech & Gadgets Correspondent, BuzzRAG