Send one packet, deliver it to a hundred receivers, and put exactly one copy on each link along the way. That is the entire promise of IP multicast, and it is the delivery model behind market data feeds, IPTV, live enterprise video, and OS imaging at scale. This article covers what multicast actually is, why unicast and broadcast both fail at the same job, and the group and tree concepts everything else builds on. It is the starting point for the full IP multicast guide.
The Three Delivery Models
IPv4 gives you three ways to deliver a packet (IPv6 adds anycast, but that is a story for the IPv6 guide). Unicast is one-to-one: every receiver gets its own copy, generated by the source. Broadcast is one-to-all: one copy per segment, but every host on the segment processes it whether it cares or not, and routers refuse to forward it. Multicast is one-to-many: one copy per link, replicated by the network only where paths to interested receivers split, and delivered only to hosts that asked.
The key phrase is "hosts that asked". Multicast is an opt-in model. Receivers subscribe to a group address, the network tracks who subscribed where, and traffic follows the subscriptions. Nobody polls the source, and the source never learns who is listening. It just sends to the group.
Why Unicast Doesn't Scale for One-to-Many
Do the arithmetic on a real workload. A market data server publishes a 5 Mbps feed. With 200 subscribers over unicast, the server transmits 200 identical streams: 1 Gbps out of its NIC, 1 Gbps across its first-hop link, and duplicated load on every shared link downstream. Double the subscribers and you double all of it. The source becomes the bottleneck, and the links closest to it melt first.
The same feed over multicast: the server sends 5 Mbps. One copy crosses each link, no matter whether the far side holds one subscriber or ten thousand. Replication happens inside the routers, at the exact points where receiver paths diverge. Subscriber growth costs the source nothing.
Groups: Addresses That Name a Service, Not a Host
A multicast group is a class D IP address (224.0.0.0 through 239.255.255.255) that identifies a stream of content rather than a machine. Nothing "owns" 239.1.1.10; sources send to it and receivers listen to it, and the two sides never need to know each other. Group addresses never appear as a source address in an IP header, only as a destination.
Membership is signaled with IGMP. When an application on a host joins a group, the host's IP stack sends an IGMP membership report on the local segment, and the first-hop router adds that interface to its delivery state. This is real output from the lab's edge router the moment a Debian host joined a group (the deep-dive is in IGMP explained):
R1# show ip igmp groups
IGMP Connected Group Membership
Group Address Interface Uptime Expires Last Reporter
239.1.1.10 Ethernet0/0 00:00:21 00:02:39 169.254.147.59Distribution Trees: How the Network Replicates
Between the source and its receivers, routers build a distribution tree: a loop-free set of paths with the traffic origin at the root and receivers at the leaves. Each router in the tree knows one incoming interface (toward the root) and a list of outgoing interfaces (toward the leaves). A packet arrives once and is copied to every outgoing interface. That per-router state is exactly what show ip mroute displays.
Trees come in two flavors. A source tree, written (S,G), is rooted at one specific source and follows the shortest unicast path to every receiver: optimal paths, but one tree of state per source. A shared tree, written (*,G), is rooted at a rendezvous point that all sources for the group transit: one tree regardless of source count, at the price of a potentially longer path. PIM sparse mode uses both, starting receivers on the shared tree and switching them to source trees when traffic flows; that mechanism is the subject of PIM sparse mode explained.
Here is a real source tree entry on the lab's last-hop router while a stream was flowing:
R1# show ip mroute 239.1.1.10
(10.0.30.10, 239.1.1.10), 00:00:05/00:02:54, flags: JT
Incoming interface: Ethernet0/1, RPF nbr 10.0.12.2
Outgoing interface list:
Ethernet0/0, Forward/Sparse, 00:00:05/00:02:54Read it as: traffic from source 10.0.30.10 to group 239.1.1.10 must arrive on Ethernet0/1, and gets copied out Ethernet0/0. The "must arrive on" part is enforced by the RPF check, multicast's loop-prevention mechanism, covered in the RPF check.
The Protocol Stack at a Glance
Three protocol layers cooperate, and it helps to keep their jobs separate from day one:
- IGMP runs between hosts and their first-hop router. It answers exactly one question: which groups are wanted on this segment?
- PIM runs between routers and builds the trees. It is "protocol independent" because it has no topology discovery of its own; it borrows the unicast routing table for every decision.
- Your IGP (in the PingLabz lab, OSPF area 0) provides that unicast table. Broken underlay means broken multicast, every time.
End to end, it looks like this in practice. A real Linux VM subscribed to a group, and a Python sender on the far side of a four-router topology started transmitting:
j@llmbits:~$ python3 /tmp/mcast_recv.py 239.1.1.10 5001
joined 239.1.1.10:5001 on 192.168.99.100 (IGMP membership active)
rx 32 bytes from 10.0.30.10: PingLabz mcast 239.1.1.10 pkt 53
rx 32 bytes from 10.0.30.10: PingLabz mcast 239.1.1.10 pkt 54
rx 32 bytes from 10.0.30.10: PingLabz mcast 239.1.1.10 pkt 55The receiver never contacted the source. It told its router what it wanted (IGMP), the routers built the tree (PIM, over OSPF), and packets arrived.
From Join to Packets: The Ten-Thousand-Foot Walkthrough
It is worth walking one delivery end to end, because the division of labor confuses everyone at first. Say the VM at 192.168.99.100 wants the stream on 239.1.1.10, and a server four hops away is sending to it.
First, the application opens a UDP socket and asks the OS to join the group. The kernel programs the NIC to accept the mapped multicast MAC and sends an IGMP membership report out the interface. That report reaches R1, the first-hop router, which records "Ethernet0/0 has a member of 239.1.1.10" and nothing more; IGMP's job is done.
Second, R1 needs the traffic to actually arrive from somewhere. It creates forwarding state for the group and sends a PIM join upstream. Which neighbor counts as "upstream" is decided by the unicast routing table, and in sparse mode the initial join travels toward the rendezvous point. Each router along the way repeats the process: create state, add the interface the join arrived on to the outgoing list, forward the join upstream. The tree builds itself backwards, from receiver toward root, one hop at a time.
Third, when the server sends, its packets flow down that tree. Each router checks the packet arrived on the expected upstream interface (the RPF check), then copies it to every interface in the outgoing list. R1 copies it onto the receiver segment, the NIC accepts the MAC, the kernel matches the group to the socket, and the application reads a datagram. Rip out any one of the three layers (membership, tree, or underlay routing) and delivery stops, which is exactly how the troubleshooting article is organized.
What Multicast Does Not Give You
Multicast is a delivery optimization, not a transport upgrade, and its constraints shape application design. Everything rides UDP: TCP's handshake and retransmission model is meaningless when one sender feeds ten thousand receivers, so there is no built-in reliability, ordering, or congestion control. A dropped packet is simply gone unless the application layer fixes it, which is why serious multicast applications ship with their own recovery mechanisms: sequence numbers plus a unicast retransmission channel (market data), forward error correction (video), or reliable multicast frameworks like PGM.
Flow control does not exist either. The source transmits at whatever rate it chooses, and the slowest receiver's problems are its own. In practice this pushes multicast networks toward careful QoS design, since a bursting stream competes with everything else on every branch of the tree at once; the QoS guide covers the queuing side of that story. None of this diminishes the model: it just means multicast solves distribution, and the application still owns end-to-end semantics.
What Actually Uses Multicast
You touch multicast more often than you might think, even before deploying it deliberately:
- Routing protocols themselves. OSPF hellos ride 224.0.0.5/6, EIGRP uses 224.0.0.10, PIM uses 224.0.0.13. Link-local multicast, never forwarded, but multicast all the same.
- Financial market data. Exchange feeds are the canonical latency-sensitive one-to-many workload, usually as SSM.
- IPTV and enterprise video. One encoder, thousands of set-top boxes or desks watching an all-hands.
- Imaging and provisioning. Pushing one OS image to a lab of 300 machines simultaneously.
- Service discovery. mDNS (224.0.0.251) and SSDP find printers and cast targets on your home network right now.
The common thread: identical data, many consumers, at the same time. When consumers need different data or need it at different times (video on demand, software downloads), unicast plus caching wins, which is why the public internet's streaming runs on CDNs instead.
Key Takeaways
- Multicast is opt-in, one-to-many delivery: one copy per link, replicated by routers where receiver paths diverge, delivered only to hosts that joined.
- Unicast cost grows linearly with receivers; multicast cost is flat for the source. That difference is the whole business case.
- A group address (224.0.0.0/4) names a stream, not a machine. Sources send to it; receivers join it; neither knows the other.
- Forwarding state is a tree: (S,G) rooted at a source for optimal paths, (*,G) rooted at an RP for shared state. Both appear in
show ip mroute. - IGMP handles host-to-router membership, PIM builds router-to-router trees, and the unicast IGP underneath feeds every RPF decision.
Next in the cluster: multicast addressing covers the ranges and the MAC mapping, and the complete guide holds the full reading order.
