PIM Sparse Mode Configuration: RP, RPF Check and Verification

PIM sparse mode is the multicast routing mode you will meet in production, and it fails in a very specific way: the (*,G) entry exists, the receiver joined, and no traffic arrives because the reverse path forwarding (RPF) check is failing. This guide configures PIM-SM from scratch on Cisco IOS XE - enabling multicast routing, turning on PIM on the right interfaces, choosing an RP design, and reading the multicast route table - then walks through the verification and troubleshooting steps that isolate RPF failures in minutes instead of hours.

Enable multicast routing and PIM

Router(config)# ip multicast-routing
Router(config)# ip multicast-routing distributed        ! platform dependent
Router(config)# interface Loopback0
Router(config-if)# ip address 10.0.0.1 255.255.255.255
Router(config-if)# ip pim sparse-mode
Router(config)# interface GigabitEthernet0/0
Router(config-if)# ip pim sparse-mode
Router(config-if)# ip pim dr-priority 100
Router(config-if)# ip pim query-interval 1

Every interface that should participate - toward sources, receivers, and the RP - needs ip pim sparse-mode. A common mistake is enabling PIM only on the interface facing receivers; without PIM toward the source the register process never completes and the (S,G) entry never leaves the shared tree.

Shared Tree, Source Tree and the Switchover

PIM-SM builds two kinds of state and it is worth being precise about which one carries your traffic. The (*,G) entry is the shared tree, rooted at the RP; receivers join it with IGMP and routers propagate explicit joins toward the RP. The (S,G) entry is a source tree, rooted at the source itself, built after the last-hop router learns the source address. The last hop starts on the shared tree and, once traffic exceeds spt-threshold (1 kbps by default), switches to the shortest path tree for that specific source.

That has a direct operational consequence: for the first packets of every group you depend on the RP being correct and reachable, even if the steady-state traffic never touches it again. A group that "works for high-rate streams and fails for trickle" — or the reverse — is usually a threshold or an RP issue, not a routing black hole.

The Register Process, Step by Step

The RP exists because a source does not know who is listening. The sequence is worth knowing by name, because each step has a matching counter in show ip mroute count:

1. The first-hop router receives multicast from the source and encapsulates it in a PIM Register message sent unicast to the RP.
2. With no receivers yet, the RP replies with a Register-Stop and the encapsulated packets are dropped — state exists but no traffic flows.
3. When a receiver joins, the RP creates a (S,G) entry and sends a Join toward the source, building the RP-rooted source tree.
4. Traffic then arrives natively at the RP, which sends Register-Stop; the first hop stops encapsulating and prunes the virtual interface.
5. The last-hop router switches to the source tree and sends a Prune up the shared tree when no other receivers remain on that branch.

Common failures map directly onto these steps: PIM missing on the source interface means no Register at all; an RP that cannot route to the source means the Join goes nowhere; and an accept-register filter that is too strict silently drops the Register while the source keeps retrying.

Define the rendezvous point

! Static RP - the simplest, most deterministic option
Router(config)# ip pim rp-address 10.0.0.1 10

! Anycast RP - same address on two routers, MSDP between them
Router(config)# ip pim rp-address 10.0.0.1 10 override
Router(config)# ip msdp peer 10.0.0.2 connect-source Loopback0
Router(config)# ip msdp originator-id Loopback0

! Auto-RP with sparse-mode listener
Router(config)# ip pim autorp listener
Router(config)# ip pim send-rp-announce Loopback0 scope 16 group-list 10
Router(config)# ip pim send-rp-discovery Loopback0 scope 16

! BSR - standards based
Router(config)# ip pim bsr-candidate Loopback0 0
Router(config)# ip pim rp-candidate Loopback0 group-list 10 interval 60

An access list such as access-list 10 permit 224.0.0.0 15.255.255.255 limits which groups a candidate RP serves. Static RP is the fallback everyone should know: it removes an entire class of "the group never left the shared tree" problems, and it is the fastest way to prove that the rest of your configuration works.

Choosing an RP Design

For a greenfield Cisco shop, static RP plus anycast RP and MSDP is usually the best combination: static for determinism, anycast for redundancy. For mixed-vendor networks, BSR avoids the Cisco-only semantics of Auto-RP. Whichever you pick, document the group range each RP is authoritative for — an RP that silently does not cover a group range produces the classic "some groups work, others do not" ticket.

The RPF check explained in one paragraph

When a multicast packet arrives, the router looks up the source address (or the RP address when only a shared-tree entry exists) in the unicast routing table. If the packet arrived on the interface the unicast table points at, the check passes and traffic is forwarded down the outgoing interface list. If not, the packet is silently dropped. Almost all "multicast is broken" tickets are unicast routing problems wearing a multicast costume.

The RPF Check: Four Ways It Gets Resolved

RPF asks a single question — "would I send a packet back to that source out of the interface this arrived on?" — but the answer can come from four places, and knowing which one is in play is the whole trick:

• Unicast routing table (the default). show ip rpf <source> prints the resolved RPF interface and neighbour straight from here.
• MBGP / MP-BGP when multicast and unicast topologies differ. A separate multicast RIB lets a router accept multicast from a source it would not prefer for unicast.
• Static mroute. ip mroute 10.20.30.0 255.255.255.0 172.16.1.1 overrides the RPF neighbour when the unicast path is asymmetric or when the source sits behind a firewall that does not run multicast routing.
• Special cases. On a shared tree the check is against the RP address, not the source, so a broken path to the RP breaks delivery even when the source is one hop away. Tunnels (GRE, mVPN) change the answer again because the RPF neighbour is the tunnel endpoint.

Recursion matters too: if the RPF interface resolves through a tunnel or a logical construct, verify that show ip rpf reports the resolved interface rather than the logical one, because the resolved value is what the drop decision uses.

Verification commands that actually answer the question

Router# show ip mroute
Router# show ip mroute 239.1.1.1
Router# show ip mroute count
Router# show ip rpf 10.20.30.40
Router# show ip pim rp mapping
Router# show ip pim neighbor
Router# show ip pim interface
Router# show ip pim bsr-router
Router# debug ip mrouting 239.1.1.1
Router# mrinfo 10.20.30.40

Read a mroute entry left to right: the incoming interface must match show ip rpf for the source, the outgoing interface list must contain the interface toward the receiver, and a (*,G) entry with RPF nbr set but no traffic is the classic sign that the RP is filtering or that the source never registers. show ip mroute count separates "no packets are arriving" from "packets arrive and are dropped", which halves the search space immediately.

Scoping and Boundaries

Router(config)# access-list 101 deny ip any 224.0.0.0 15.255.255.255
Router(config)# interface GigabitEthernet0/1
Router(config-if)# ip multicast boundary 101
Router(config-if)# ip multicast ttl-threshold 10
Router(config)# ip pim bsr-border

Three mechanisms, three distinct jobs: a multicast boundary access list stops groups at a router interface (the tool for keeping admin-scoped 239.x ranges local), a ttl-threshold on the outgoing interface prevents short-lived traffic from leaking far, and bsr-border stops candidate RP advertisements from crossing an administrative edge. All three are easy to apply and just as easy to forget — put them in the site template so a new location cannot accidentally advertise itself into another domain's RP election.

A Worked Example

! Source 10.20.30.40 behind R1, receivers behind R3, RP on R2's loopback
R2(config)# ip multicast-routing
R2(config)# interface Loopback0
R2(config-if)# ip pim sparse-mode
R2(config)# ip pim rp-address 10.0.0.2 10
R3(config)# ip multicast-routing distributed
R3(config)# interface GigabitEthernet0/2
R3(config-if)# ip pim sparse-mode
R3(config-if)# ip igmp version 3

! Verify, in this order
R3# show ip rpf 10.0.0.2          ! can I reach the RP the way I think?
R3# show ip pim rp mapping        ! does R3 agree who the RP is?
R3# show ip mroute 239.1.1.1      ! incoming interface vs the (S,G) parent
R3# show ip mroute count          ! arriving, or arriving and dropping?

The ordering is deliberate: prove unicast reachability of the RP and the source first, then confirm the RP mapping agrees on every router, and only then look at multicast-specific counters. Reversing it is exactly how an RPF problem gets misdiagnosed as a multicast configuration problem.

Troubleshooting: Symptom to Command

Tuning and protection

Router(config)# ip pim spt-threshold 100 group-list 20
Router(config)# ip pim spt-threshold infinity group-list 21
Router(config)# ip pim register-rate-limit 100
Router(config)# ip pim accept-register list 30
Router(config)# ip pim bsr-border
Router(config-if)# ip pim sparse-mode border lan

spt-threshold infinity keeps low-rate groups on the shared tree, which reduces state on core routers at the cost of slightly longer paths. register-rate-limit and an accept-register access list protect the RP from a misbehaving source that floods registers. On WAN interfaces use ip pim bsr-border so candidate messages never leak across an administrative boundary.

SSM and When You Can Skip the RP

If the application can use Source-Specific Multicast, most of this machinery disappears. SSM lives in 232.0.0.0/8, requires IGMPv3 on the receivers, needs PIM on the routers but no RP at all, and builds the (S,G) tree directly. That removes RP failures, register storms and shared-tree switchover from the failure model entirely. Prefer SSM where the application allows it; keep PIM-SM knowledge for the many deployments where the sender list is dynamic.

Putting it together

Design order matters: pick RP redundancy first, enable PIM everywhere inside the multicast domain, and verify unicast reachability of sources and RP before you look at anything multicast-specific. Pair this with a working Layer 2 foundation - see IGMP snooping configuration for the access layer and VRF-lite when multicast must stay inside a tenant. For RP redundancy in depth, the design and MSDP peering details in our anycast RP with MSDP guide pick up where this article stops. For packet-level proof that joins are leaving the host, capture with the filters in our tcpdump guide.

原文链接：Cisco - PIM Sparse Mode Configuration