Multicast RPF Failure Across Asymmetric MPLS Path
A receiver VLAN 100 (172.16.100.0/24) on an access switch joins group 239.1.1.1. The multicast source 192.168.50.10 is behind a PE router in a different MPLS VPN. PIM-SM is enabled on all transit interfaces; the RP is 10.0.0.5, reachable via OSPF. display pim routing-table 239.1.1.1 on the last-hop router shows the (*,G) joined but no (S,G); display pim neighbor shows all neighbors up. The unicast route to 192.168.50.10 points out interface Vlan-interface200 toward the PE, but the actual multicast stream arrives on Vlan-interface300 (a backup path with lower OSPF cost after a recent link change). RPF check fails.
1. Explain why the (S,G) never forms and what the RPF check is comparing.
Read the worked answer
Why no (S,G): PIM-SM builds the shortest-path tree only after the last-hop router receives the source's traffic and passes the RPF check. The RPF check compares the incoming interface of the multicast packet against the interface the unicast routing table uses to reach the source (192.168.50.10).
The mismatch: Unicast route to 192.168.50.10 = Vlan-interface200 (per OSPF cost). Actual multicast arrives on Vlan-interface300. Incoming interface (300) != RPF interface (200) => RPF check fails => packet dropped => no (S,G) created. The (*,G) exists because it was built toward the RP, and the RP path is consistent.
Key point: PIM does not 'follow' the packet; it trusts the unicast RIB. Asymmetric unicast/multicast paths are the classic RPF failure. The recent link change made the unicast best path diverge from the actual multicast path - the two must agree for PIM to work.
2. Propose two fixes and the trade-off of each.
Read the worked answer
Fix 1 - Make paths symmetric: Adjust OSPF cost so the unicast best path to 192.168.50.10 is Vlan-interface300, matching the multicast path. Simple, keeps RPF semantics intact. Trade-off: changes all unicast traffic for that destination, may create suboptimal unicast routing and affects other prefixes on that link.
Fix 2 - Static multicast RPF route: Configure a static multicast route (ip rpf-route-static 192.168.50.10 32 <next-hop-on-Vlan300>) so PIM's RPF lookup uses Vlan-interface300 while unicast stays on 200. Preserves unicast optimality. Trade-off: operational overhead, must be maintained when topology changes, and a stale static RPF route silently black-holes multicast if the path moves again.
Recommendation: Prefer Fix 1 if the link change was a permanent design change (symmetric is simpler and self-healing). Prefer Fix 2 only if unicast optimality on Vlan-interface200 is business-critical. Either way, verify with display pim routing-table 239.1.1.1 that an (S,G) with correct incoming interface appears, and check display multicast rpf-info 192.168.50.10.