PIM-SM interview questions become easier when you separate receiver joins, source registration and the later forwarding-path change. This guide walks through one fictional IPv4 multicast example; it is not a captured production incident or an executed router lab.
Direct answer: PIM Sparse Mode builds receiver-driven multicast trees. In any-source multicast, the rendezvous point (RP) connects source discovery with a shared tree; receivers can later use a source-specific shortest-path tree (SPT).[1]
What do RP, (*,G) and (S,G) mean?
The RP is the root of the shared tree for a group. (*,G) represents interest in group G without selecting one source; (S,G) identifies source S sending to G.[1]
PIM uses reverse-path information from a routing table rather than requiring a particular unicast routing protocol. Joins travel upstream; multicast data travels in the opposite direction along the resulting tree.[1]
Follow one multicast stream
Use these fictional identifiers on a whiteboard:
- Source S:
192.0.2.10, attached to router FHR. - Receiver: attached to router LHR.
- RP address:
192.0.2.254. - Group G:
239.10.10.10.
Sketch a path through the RP and a second, shorter path between FHR and LHR. Keep control messages and data arrows in different colors.
1. The receiver joins the shared tree
The receiver signals membership with IGMP; its designated router sends a (*,G) Join toward the RP. Each hop adds state until the Join reaches the RP or an existing branch.[1]
2. The source starts; its router registers it
The source simply sends multicast data. Its designated router encapsulates the packets inside unicast PIM Register messages addressed to the RP. The source host does not perform this registration itself.[2]
With interested receivers, the RP forwards the received stream toward them and normally joins toward S for native multicast delivery.[1][2]
3. Native traffic replaces Register encapsulation
When native packets arrive at the RP, it sends Register-Stop to the source DR. Register-Stop can also occur when the RP has no interested downstream receivers; it is not, by itself, proof of a successful end-to-end stream.[2]
4. The receiver-side router switches to the SPT
The last-hop router may send an (S,G) Join toward S. After traffic arrives on that tree, an (S,G,rpt) Prune suppresses that source on the old shared-tree branch, not every source in G.[1]
Two different optimizations—not one event
Do not confuse the RP joining the source tree with the receiver-side router switching away from the RP tree. The former removes ongoing data encapsulation; the latter can shorten the receiver's forwarding path.[2]
On the Cisco implementations described in the optimization guide, the default receiver-side switchover occurs after the first packet. An SPT threshold can delay switching, and infinity can keep receivers on the shared tree. That is a configuration choice, not a universal protocol requirement.[2]
How do routers know the RP?
Options include static group-to-RP configuration, Bootstrap Router (BSR) distribution and Cisco Auto-RP. Verify the mapping for the actual group, not merely whether an RP address appears somewhere in the configuration.[3]
For a small isolated lab, I suggest using a static RP first and adding dynamic discovery only after the stream works. This keeps the exercise focused on the packet flow rather than two simultaneous learning objectives.
Scope matters: SSM is different: receivers identify a source and group, with IGMPv3 supporting source selection in IPv4. SSM does not require RP discovery or the shared-tree/register sequence. Bidirectional PIM is another model and does not perform this PIM-SM SPT switchover.[3]
Troubleshooting checklist: follow the first missing evidence
Cisco's verification workflow starts at the last-hop router and works back toward the source; the cited procedure assumes the default zero SPT threshold.[4]
| Check | Evidence to collect |
|---|---|
| Receiver membership | Group appears on the expected receiver-facing interface. |
| RP mapping | Actual G resolves to the intended RP. |
| PIM path | Expected upstream neighbor exists. |
| Reverse path | RPF lookup toward S selects the expected interface/neighbor. |
| Forwarding state | Incoming interface and outgoing-interface list match the intended stream path. |
| Traffic | Counters increase while the application sends. |
These checks combine the RP configuration and multicast verification guidance.[3][4]
Illustrative IOS/IOS XE read-only commands; availability and output vary by platform/release:[4]
show ip igmp groups
show ip pim neighbor
show ip pim rp mapping
show ip rpf 192.0.2.10
show ip mroute 239.10.10.10
For the shared-tree side, also inspect reverse-path reachability toward the RP rather than checking only the source.[1]
My suggested incident worksheet has three columns: expected observation, actual observation, and next test. Record the exact group and source on every row; do not mix evidence from unrelated streams.
Common pitfalls and a short interview answer
- Do not equate a multicast route entry with working delivery: inspect interfaces and counters.[4]
- Do not treat Register-Stop as an instruction for the application to stop sending; it controls the DR's registration behavior.[2]
- Do not assume all multicast requires an RP: SSM does not.[3]
Interview version: “In PIM-SM ASM, receivers join toward an RP, and the source DR registers the stream there. The RP can obtain native traffic; the last-hop router can separately switch to a source tree. I troubleshoot membership, RP mapping, RPF, forwarding state and counters.”[1][4]
Related reading
- How a Layer 3 Switch Decides Between Switching and Routing
- EVPN/VXLAN BUM Traffic: Head-End Replication vs Multicast
Summary: Keep receiver membership, source registration and path optimization separate in your explanation. Preparing for a network engineering interview? Draw this example from memory, then explain which observation you would collect before changing any configuration.
Post a Comment