Protocol Independent Multicast Sparse Mode (PIM-SM) forwards multicast traffic along tree paths built from unicast routing information and multicast control messages. Reverse path forwarding (RPF) checks are central to loop prevention: a router expects packets from a particular source or rendezvous-point direction to arrive on the correct upstream interface. When packets arrive elsewhere, they may be dropped even if ordinary unicast reachability appears healthy.
A multicast outage must be diagnosed as a control-plane and forwarding-path problem, not merely a missing UDP stream. Operators should identify the source, multicast group, receiver, expected upstream RPF neighbor, and tree state. The resulting sequence narrows whether the issue is unicast route selection, PIM adjacency, joins, rendezvous-point behavior, or actual packet delivery.
Establish the multicast source and group
Start with the source address and group address that the application uses. Confirm that the sender is transmitting the expected traffic and that receivers request membership through the appropriate IGMP mechanisms on the local subnet. Without a real sender and receiver state, configuring PIM joins can produce an apparently correct tree with no useful data.
Check the scope of the group and whether the environment uses ASM, SSM, or another supported multicast model. In source-specific multicast, receiver joins and source-specific tree behavior differ from traditional shared-tree operation. A troubleshooting command that assumes a rendezvous point is required for every group can mislead when SSM is in use.
The multicast enterprise design should establish where multicast offers measurable application value and where boundary controls are needed. The routing protocol cannot compensate for an application that sends an unexpected group or uses a TTL too small to cross the intended hops.
A source reachable through two routed uplinks illustrates the failure. After an OSPF metric change, the router’s unicast lookup points back to the multicast sender over uplink B, but packets still arrive over uplink A due to the upstream source tree. The router may discard the arriving packets on the RPF check while other unicast services continue working. Confirm the selected RPF neighbor and observed inbound interface, then determine whether the underlying metric or multicast tree needs correction. Lowering an unrelated interface cost without understanding the design can move the mismatch elsewhere rather than restoring delivery consistently.
Identify the expected RPF interface
The RPF check typically examines the routing information that leads back toward the multicast source or relevant tree root. The selected upstream interface can differ from the one an operator expects based on network topology diagrams. Use current unicast routing, administrative distance, protocol preference, and multicast routing state to determine the expected arrival interface.
Inspect the exact source route and its next hop. A recent BGP policy or OSPF metric change can cause the RPF neighbor to move while traffic still arrives through an older or asymmetric path. Unicast ping reachability may remain intact even as multicast packets fail RPF checks because the incoming interface is not preferred by the router’s calculation.
Check multicast RPF tables and platform commands with the actual source and group, not only general interface counters. A router may have correct RPF information for one source and fail for another due to more-specific routing or policy. This is particularly common when overlapping prefixes or multiple routing domains are involved.
Follow the joins toward the upstream neighbor
PIM-SM builds forwarding state as interested downstream routers send Join messages toward the relevant tree root. If a downstream router has no interested receiver, it may not establish the expected outgoing interface list. Inspect PIM neighbors and join/prune state hop by hop from the receiver toward the source or RP.
A missing PIM adjacency on an interface can prevent tree construction despite correct unicast routes. Verify multicast routing is enabled and PIM is configured on every required Layer 3 hop, subject to platform features. Do not enable PIM indiscriminately on an untrusted boundary simply to make a join appear.
Outgoing interface lists should be evaluated with local receiver information. A router may have an upstream path but no valid downstream outgoing interfaces because membership reports are missing or filtered. Distinguish an RPF failure from a missing downstream join before changing unicast route preference.
In an ASM design, a receiver may initially receive traffic along an RP-centered shared tree and later establish source-specific state. If the switchover changes which upstream neighbor is expected, an RPF mismatch can interrupt an otherwise working stream. Compare (*,G) and (S,G) state at the affected router before and after the interruption, and verify that the router’s route to the RP and route to the actual source are both correct. In SSM, do not spend time debugging RP discovery for a group whose control model does not use the RP in the first place.
In sparse-mode multicast, the initial rendezvous-point path and the shortest-path tree may involve different incoming interfaces. A receiver can join successfully toward the RP but then lose traffic when a router switches to the source tree and its unicast RPF lookup points somewhere unexpected. During diagnosis, inspect the relevant (*,G) and (S,G) state separately and identify the selected incoming interface for each. Correlate changes in the source’s unicast reachability, not just the multicast group’s RP address. If a new unicast default route causes the router to choose a different RPF neighbor, an apparently harmless routing optimization can interrupt established multicast groups.
Understand RP and source-tree transitions
In traditional ASM PIM-SM, a rendezvous point helps build a shared tree for group discovery. Routers may later switch to a shortest-path tree for source traffic according to implementation behavior and thresholds. A failure can therefore appear during the transition even when the initial shared tree was functioning.
Check RP configuration, mapping, reachability, and consistency where the group relies on an RP. A router using a different RP mapping can produce join state that points to the wrong part of the network. Static and dynamic RP assignment must agree with design intent and current software support.
An RPF failure may discard multicast traffic even when a unicast route appears usable, because the incoming interface does not satisfy reverse-path expectations; 350-401 ENCOR diagnosis must inspect tree state. The 350-401 ENCOR enterprise core scope includes multicast concepts and routing behavior; understanding the meaning of tree states helps explain why one source works while another fails within the same group.
Investigate asymmetric paths and ECMP
Multicast RPF logic can be sensitive to route selection when unicast traffic uses equal-cost multipath or asymmetric network design. Different routers may choose distinct valid paths according to their tables and tie-breaking rules. A multicast flow arriving on an interface not selected as upstream can be discarded even if the network provides other healthy unicast paths.
Capture forwarding state and actual packet arrival during the fault. A PIM neighbor may exist on the desired link while the selected RPF interface is elsewhere. Adjusting PIM alone does not change a unicast route that drives RPF selection. Determine whether policy or metric changes should be made in the underlying routing design.
Where supported, review multicast-specific routing policy and static multicast routes carefully. Using a special route to force RPF can be a legitimate architecture tool, but it can conceal an inconsistent unicast design and must be tested through failover to avoid becoming a persistent black hole.
Inspect control-plane and data-plane evidence
Compare PIM neighbor state, RPF entries, join/prune messages, outgoing interface lists, interface counters, and multicast packet observations. A router receiving packets and incrementing RPF failure counters supplies direct evidence of the forwarding rejection. A lack of incoming packets may instead point farther upstream.
Confirm that ACLs, group boundaries, or multicast filtering do not block the traffic even when RPF succeeds. Some environments intentionally restrict permitted group ranges or sources; a policy drop is not necessarily a routing failure. Review intended security and group-access rules before relaxing filters.
Check whether the stream itself sends packets with TTL and source addressing consistent with the network. A sender using an unexpected source interface can change the selected RPF route, invalidating the assumptions used when the tree was built.
A repeatable acceptance case uses one source and two receivers located in different routing areas. Capture source transmission rate, received packet rate, PIM join state, RPF choice, and outgoing interface lists before changing a routing policy. Withdraw the preferred unicast path and measure multicast reconvergence while receivers remain active. When the preferred path returns, confirm tree state converges again without persistent RPF drops. A passing ping to the source should be recorded as supporting unicast evidence, not as proof that multicast traffic resumed. This separation keeps the diagnostic conclusions technically precise.
A practical validation table should include source address, multicast group, receiver VLAN, RP address, expected RPF next hop, upstream interface, and observed outgoing interface list. Run one join from each relevant receiver site before the routing change, after the first convergence, and after failback. A stream may work near the sender while remote receivers fail because only the remote branch has the incorrect unicast view. Check counters for RPF drops and missing joins, but distinguish them from data packets filtered by ACLs or TTL thresholds. Each symptom requires a different corrective action; blanket multicast flooding is not a safe substitute for repairing the specified tree.
Test multicast after routing changes
A core route-policy update may move the preferred path back toward a source without affecting unicast application traffic materially. That subtle change can invalidate a multicast tree. Include multicast RPF checks and representative receiver streams in post-change validation when the environment depends on PIM.
For each critical group, record expected source, RP or SSM mode, RPF neighbor, receiver VLANs, and valid outgoing interfaces. During failover testing, verify that the tree converges and that actual stream continuity meets application needs. A PIM adjacency recovering is not the same as useful video or telemetry returning.
Avoid treating all packet loss as multicast routing loss. Network congestion, source encoder failure, or receiver application problems can also interrupt a stream. Reconcile forwarding counters with source and receiver observations to isolate whether packets were blocked by routing or lost elsewhere.
Preserve a clear operational multicast map
Maintain group allocation, source ownership, RP or SSM policy, PIM-enabled links, and intended unicast return-path dependencies. Multicast often becomes fragile when source devices move subnets but routing and PIM assumptions are not revisited.
When a PIM RPF issue is fixed, document whether the cause was changed unicast next hop, missing adjacency, inconsistent RP mapping, incorrect join state, or a deliberate policy boundary. The remedy differs for each, and a good runbook should teach the distinction rather than prescribing one universal command.
PIM-SM RPF troubleshooting succeeds when the operator proves which upstream interface the router expects and why actual multicast traffic did or did not arrive there. Combining unicast route evidence with PIM tree state and packet counters makes multicast failures diagnosable without accidental changes to unrelated routes or security policy.
