IP multicast is designed for one-to-many delivery without forcing the sender to transmit a separate copy of the same stream to every receiver. That efficiency requires coordination between hosts and routers: hosts have to signal which multicast traffic they want, and routers have to build forwarding state toward the source.
The current 350-401 ENCOR v1.2 blueprint significantly expands multicast coverage. It explicitly names Reverse Path Forwarding, PIM Sparse Mode, IGMPv2/v3, Source-Specific Multicast, bidirectional PIM, and MSDP. A useful 350-401 multicast practice case separates a reverse-path forwarding failure from missing group membership and asks which observation supports the diagnosis.
Start with the delivery model
A multicast sender transmits to a multicast group rather than to each receiver individually.
Unicast and multicast delivery differ in where traffic replication happens. Separate unicast streams consume a sender-to-receiver path for each destination, while multicast forwards toward subscribed receivers and branches only where needed. In troubleshooting, a missing multicast receiver may indicate an IGMP membership or PIM state problem even when ordinary unicast routing to that subnet works.
That efficiency is useful for live video, market data, telemetry, conferencing, and other one-to-many applications.
The challenge is state: the network needs to know which receivers want a group and where the source can be reached.
Multicast forwarding is efficient because replication occurs only where the distribution tree branches. A single packet can cross the shared part of a path and then be copied near the receivers instead of making the sender transmit one unicast stream per destination.
That efficiency depends on correct state at several layers. The receiving host must express interest, the last-hop router must represent that interest in multicast routing, intermediate routers must know which interfaces belong to the tree, and every router must be able to verify the reverse path toward the source. A failure at any one of those stages can produce the same user symptom: no stream arrives.
IGMP handles receiver membership on IPv4 LANs
Internet Group Management Protocol is used between IPv4 hosts and their local multicast router.
A host uses IGMP to signal interest in multicast group traffic. The local router maintains membership state and can then participate in multicast routing on behalf of the attached receivers.
IGMPv2 supports group membership but does not give the receiver the same source-selection capability as IGMPv3.
IGMPv3 adds source filtering. A receiver can express interest in traffic for a specific source and group relationship.
That ability is essential to Source-Specific Multicast.
IGMP membership is local to the receiver-facing IPv4 segment. Routers do not use IGMP as the protocol for building the entire routed multicast tree across the network. That is the job of PIM.
At Layer 2, IGMP snooping is another separate mechanism. A switch can listen to membership messages so multicast frames are sent only toward interested ports instead of flooding the whole VLAN. Snooping can improve efficiency inside the LAN, but it does not replace the first-hop or last-hop router’s IGMP state and it does not replace PIM between routers.
PIM does not discover receivers directly
Protocol Independent Multicast, or PIM, runs between routers.
The “protocol independent” name means PIM does not require one specific unicast routing protocol. It relies on the unicast routing table for reachability decisions.
That leads to the Reverse Path Forwarding check.
When multicast traffic arrives, the router verifies whether the packet came in on the interface that provides the best unicast path back toward the source. If it did not, the packet may be discarded to prevent loops and duplicate forwarding.
RPF therefore connects multicast forwarding to the underlying unicast routing table.
Reverse Path Forwarding (RPF) validates the expected upstream interface, but the lookup depends on the multicast tree. With source-specific (S,G) state, a router checks the route back toward source S. With a PIM-SM shared tree represented by (*,G) state and no explicit source tree, the RPF check follows the route toward the rendezvous point (RP). A packet arriving on the wrong interface is discarded even if PIM neighbor relationships appear healthy. Identify the current multicast forwarding state before choosing which upstream route to investigate.
This means an unrelated unicast routing change can break multicast even when the multicast configuration did not change. Asymmetric designs, missing routes, or a less-specific route toward the source can change the RPF interface and cause traffic to be discarded. Checking show ip route toward the source and the multicast forwarding state together is often more revealing than checking PIM neighbors alone.
PIM Sparse Mode builds shared and source trees
PIM Sparse Mode assumes receivers are relatively sparse and does not flood multicast traffic everywhere by default.
In the traditional any-source model, a Rendezvous Point provides a meeting location between sources and receivers.
A receiver-side router can join toward the RP for the multicast group. A source-side router can register the source with the RP. The network can then build the necessary multicast state and, depending on the implementation and traffic, move toward a source-specific shortest-path tree.
This creates two important forms of state:
(*,G)— traffic for any source sending to group G(S,G)— traffic from a specific source S to group G
Understanding those symbols makes PIM tables much easier to interpret.
In PIM-SM, the receiver side can initially build a shared tree toward the RP, represented by (*,G) state. Once the source is known, routers can build source-specific (S,G) state and, depending on policy and implementation, transition traffic toward a shortest-path tree.
The RP therefore solves source discovery and rendezvous in the any-source model; it is not supposed to become a permanent choke point for every packet in every design. Understanding the change from shared-tree state to source-specific state helps explain why a router can show both forms during normal operation.
SSM removes the need for an RP for the SSM range
Source-Specific Multicast changes the receiver model.
Instead of asking for “any source sending to group G,” the receiver subscribes to a specific (S,G) channel.
Cisco’s current IOS XE documentation describes PIM-SSM as derived from PIM Sparse Mode and notes that IGMPv3 is required for native source-specific receiver signaling.
For groups in the SSM range, the network does not build the traditional shared RP tree. Routers use source-specific joins toward the known source.
That reduces control-plane complexity when the application already knows which source it wants.
The commonly used IPv4 SSM range is 232.0.0.0/8. Within the SSM model, the receiver already knows the source it wants, so the network can send a source-specific join toward S without first discovering that source through an RP.
That simpler control model also changes the failure questions. If an SSM receiver gets no traffic, confirm that the application requested the correct source and group, that IGMPv3 state reflects the expected (S,G) interest, and that unicast routing supports the RPF path toward the source. Looking for an RP problem in a correctly designed SSM range sends the investigation in the wrong direction.
Why IGMPv3 matters to SSM
IGMPv3 can send include-mode membership reports that name the sources from which the host wants traffic.
That gives the last-hop router the information needed to construct (S,G) state directly.
IGMPv2 does not provide native source-specific membership signaling in the same way.
This is why SSM discussions should not reduce IGMPv3 to “a newer IGMP version.” The source-filtering capability changes what the multicast network can build.
IGMPv3 can express INCLUDE and EXCLUDE source filters. SSM most naturally uses source-specific INCLUDE semantics: receive group G from source S. That is more precise than simply joining G and accepting traffic from any active source.
The application matters because the host must actually make a source-aware request. Enabling IGMPv3 on a router interface does not force every application into SSM behavior. Cisco also documents SSM mapping mechanisms for certain legacy receiver scenarios, but native IGMPv3 support is the cleanest model when the host and application support it.
MSDP belongs to the any-source multicast world
Multicast Source Discovery Protocol is associated with PIM Sparse Mode deployments that need RPs in different domains to learn about active sources.
MSDP distributes source-active information between peers so receivers behind one RP can discover sources registered elsewhere.
That role makes much more sense when contrasted with SSM.
In SSM, the receiver already specifies the desired source, so the network does not need the same RP/source-discovery mechanism for the SSM range.
This is one of the reasons SSM can be operationally simpler.
Bidirectional PIM solves a different multicast pattern
Bidirectional PIM is designed for many-to-many applications where multiple receivers may also be sources.
Rather than optimizing toward source-specific shortest-path trees in the same way as PIM Sparse Mode, bidir PIM uses a shared tree.
It therefore belongs in the same multicast toolbox but solves a different traffic pattern.
For ENCOR, the useful distinction is conceptual: PIM-SM, SSM, and bidir are not simply three names for “multicast mode.” They make different assumptions about sources, receivers, and how trees should be built.
MSDP becomes relevant when an any-source multicast design has multiple RPs that need to exchange source-active information. Its purpose is source discovery across those RP domains, not receiver membership on the local LAN and not the forwarding of user packets itself.
That distinction is useful when reading a topology. If the problem is a host that never joined, MSDP is too far upstream. If the problem is that one RP domain cannot discover a source registered in another, MSDP becomes much more relevant. Troubleshooting improves when each protocol is matched to the state it actually owns.
A practical multicast troubleshooting order
When multicast fails, separate receiver signaling, routing, and forwarding state.
- Confirm the receiver is actually joining the group.
- Check the IGMP version and membership state on the last-hop router.
- Verify unicast routing toward the source so the RPF check can succeed.
- Inspect PIM neighbors on the expected routed interfaces.
- Check the multicast routing table for
(*,G)or(S,G)state. - In PIM-SM, verify RP information where relevant.
- In SSM, confirm the receiver is using IGMPv3 and subscribing to the correct source.
- Confirm the source traffic is actually entering the multicast domain.
A normal ping test does not validate multicast state. The network can have perfect unicast reachability while multicast membership or tree construction is broken.
The cleanest multicast model is to assign each mechanism one job. IGMP represents receiver interest on the local IPv4 LAN. The unicast table supplies the reverse-path information used by RPF. PIM builds the routed distribution tree. An RP supports source discovery for the PIM-SM any-source model, while SSM replaces that discovery problem with an explicit source-and-group subscription. Once those ownership boundaries are clear, (*,G) and (S,G) entries become evidence instead of cryptic notation.