PIM-SM RPF Failure and an SSM Group Joined with IGMPv2
An enterprise runs PIM-SM with a static RP at 10.255.0.1 on core router C1. A source at 10.10.1.50 on VLAN 10 sends a feed to 239.1.1.1. A receiver in VLAN 30 on access switch A1 sends an IGMPv2 join. On A1, show pim join shows (*,239.1.1.1) with an incoming interface toward the RP, but no (S,G) entry. On C1, show pim rpf for 10.10.1.50 reports RPF neighbor 10.0.0.2 via ge-0/0/1, while the source is actually reachable via ge-0/0/2. show pim statistics shows RPF failures incrementing. The unicast route to 10.10.1.0/24 is learned from an OSPF summary 10.10.0.0/16 pointing at ge-0/0/1. A second feed uses 232.1.1.1, and the receiver operating system supports only IGMPv2.
1. Explain why no (S,G) entry forms and why the RPF check fails, then give the fix and the verification commands.
Read the worked answer
PIM-SM builds the shortest-path tree toward the source only after the RP or the last-hop router has a working RPF path to that source. The RPF check does not use the RP address or the group; it uses the unicast route to the source. Here the best route to 10.10.1.50 is the /16 summary via ge-0/0/1, so PIM selects 10.0.0.2 on ge-0/0/1 as the RPF neighbor. Data and PIM Register messages from 10.10.1.50 actually arrive on ge-0/0/2, fail the check, and are dropped. The RP never accepts the source, so no (S,G) state is created and only the shared-tree (*,G) join remains.
Fixes, in order of preference:
- Make the unicast route match the topology: allow the specific 10.10.1.0/24 into OSPF or adjust the summary so it points at ge-0/0/2. RPF is only as correct as the unicast routing table.
- If routing changes are not possible, install a static multicast route (static mrouted) pointing 10.10.1.50 out ge-0/0/2. This is a targeted exception and must be documented.
Verify with show pim rpf 10.10.1.50, show pim join extensive for the group, and show pim statistics to confirm RPF failures stop. Then confirm the (S,G) entry appears and the receiver's stream recovers.
2. The 232.1.1.1 feed never reaches the receiver even after the RPF issue is fixed. Explain the interaction between the group range and IGMPv2, and give two workable solutions.
Read the worked answer
232.0.0.0/8 is the default SSM range in Junos. SSM requires the receiver to signal both the group and the source, which IGMPv3 provides; IGMPv2 can only signal the group. When an IGMPv2 host joins 232.1.1.1, the router has no source information, so the join is treated as an ASM (*,G) join and the router looks for an RP and a shared tree. If no source is registered for that group, or the RP path is not usable, the receiver sees nothing. The group is in the SSM range, but the host is not speaking SSM.
Solutions:
- Enable IGMPv3 on the receiver-facing interface and on the host, if the operating system can be upgraded. The host then sends an INCLUDE mode report with the source address, and PIM builds the (S,G) tree directly without an RP.
- Configure SSM mapping on the last-hop router, mapping 232.1.1.1 to source 10.10.1.50 so IGMPv2 joins are translated into SSM state.
- As a fallback, move the feed to a group outside 232/8 and keep it as ASM, accepting the shared-tree behavior.
Verify with show igmp group and show pim join extensive on the last-hop router; the expected result after the fix is an (S,G) entry with the correct incoming interface.