Multicast is fundamentally a "fire and forget" protocol, where a sender blasts packets into the network and has no idea if anyone is listening.
Imagine you’ve got a live video stream going out over multicast. Your server is sending packets to a specific multicast IP address, say 239.1.1.1. Now, who’s going to receive those packets? Not everyone on the network, thankfully. Only the devices that have explicitly said, "Hey, I’m interested in 239.1.1.1," will get them. This "interest" is managed through IGMP (Internet Group Management Protocol).
Here’s a look at a simple multicast setup in action. Let’s say we have a sender host (192.168.1.10) and two receiver hosts (192.168.1.20 and 192.168.1.30), all on the same subnet, and a router (192.168.1.1) connecting this subnet to other parts of the network. The sender wants to send to 239.1.1.1.
On receiver 192.168.1.20, you’d typically see IGMP join messages being sent to the router.
# On receiver 192.168.1.20, simulating a multicast application joining a group
# (Actual application would do this, but we can check the effect)
# On Linux, tools like `vlc` or `ffplay` can join groups.
# Let's assume a process is running that has joined 239.1.1.1
On the router (192.168.1.1), you can inspect the IGMP state.
# On a Cisco router:
show ip igmp groups
# Output might look like:
# IGMP Connected to 192.168.1.0/24
# Group Address Runtime Report Count Group Expiry Ports
# 239.1.1.1 00:01:30 1 00:02:30 2 (192.168.1.20, 192.168.1.30)
This output tells us that the multicast group 239.1.1.1 is active on the 192.168.1.0/24 interface, and two hosts (192.168.1.20 and 192.168.1.30) have joined it. The router knows to forward multicast traffic for 239.1.1.1 to this subnet.
Now, for multicast to work beyond this local subnet, routers need to know how to forward multicast traffic between subnets. This is where multicast routing protocols come in, like PIM (Protocol Independent Multicast). PIM doesn’t rely on unicast routing tables alone; it builds its own multicast forwarding tables.
Imagine the sender is on subnet A and receivers are on subnet B. The sender starts sending to 239.1.1.1.
- Sender (Subnet A): Sends packets to
239.1.1.1. - Router 1 (Connects Subnet A): Receives the multicast packets. If PIM is enabled and it has a way to learn about receivers (either directly on its subnet or from other routers), it will start forwarding these packets.
- Inter-Router Link: Router 1 might send these packets to Router 2 (which connects Subnet B) based on PIM’s rules. PIM uses a concept called "shared trees" (Rendezvous Point - RP) and "shortest path trees" (Source-Specific Multicast) to efficiently deliver traffic.
- Router 2 (Connects Subnet B): Receives the PIM-encapsulated multicast traffic. It checks its multicast forwarding table. If it knows there are IGMP members for
239.1.1.1on Subnet B, it will forward the packets out to Subnet B. - Receiver (Subnet B): Receives the packets because it previously sent an IGMP join message.
The key problem PIM solves is avoiding flooding multicast traffic everywhere. It builds explicit paths (trees) from the source to the receivers, or from a central point (RP) to both sources and receivers.
A common PIM mode is PIM-SM (Sparse Mode), which is designed for networks where multicast groups are not universally popular. It relies on a Rendezvous Point (RP) – a designated router that acts as a meeting point for sources and receivers.
Here’s a simplified PIM-SM configuration snippet on a router:
interface GigabitEthernet0/0
ip address 192.168.1.1 255.255.255.0
ip pim sparse-mode
!
interface GigabitEthernet0/1
ip address 10.0.0.1 255.255.255.0
ip pim sparse-mode
!
ip pim rp-address 192.168.1.100 # RP is at 192.168.1.100
In this config, GigabitEthernet0/0 is the interface facing the local subnet with potential receivers, and GigabitEthernet0/1 faces another part of the network. ip pim sparse-mode enables PIM in sparse mode. The ip pim rp-address command tells this router where to find the RP for the network.
When a receiver joins 239.1.1.1, it sends an IGMP join to its directly connected router. That router, if it’s PIM-enabled, will then send a PIM JOIN message towards the RP for that group. Simultaneously, the sender will start sending multicast traffic. The first packet from the sender will typically be sent to the RP (via a mechanism called "register encapsulation" by the first PIM router), and the RP will then learn about the source and build a path.
The most surprising thing about PIM’s RP mechanism is that the RP doesn’t actually need to receive the multicast data itself for the initial tree-building process. When a source starts sending, the first PIM router that sees the traffic encapsulates it in a PIM REGISTER message and sends it directly to the RP. The RP then receives this REGISTER message, extracts the original multicast packet, and uses it to populate its multicast forwarding table. Crucially, it also sends a JOIN message back towards the source’s network to build the optimal path (shortest path tree). Once this JOIN message reaches the router connected to the source, that router will start forwarding the actual multicast traffic directly to the RP, and then the RP forwards it to receivers. The REGISTER encapsulation is dropped, and traffic flows efficiently.
The underlying principle is that PIM routers build multicast forwarding tables (similar to unicast routing tables, but for multicast) based on IGMP reports from receivers and PIM messages exchanged between routers. The state for a multicast group is only created on the paths where it’s needed, rather than being flooded everywhere.
The next concept you’ll typically encounter is how to handle multiple sources for the same multicast group or how to optimize traffic flow when the RP is not on the shortest path to the source.