multicast - Will PIM-SM do spt switchover even without an RP?

Unanswered Question
Apr 14th, 2008


R1 --> R4 --> R3 --> R5 --> R6


R4 is a static RP on all routers.

R1 rpf interface to R4 is serial 1/2.

R3 rpf interface to R4 is serial 1/3.

R1 (s1/1) is also connected to R3 (s1/3)

R6 is statically joined to and

What normally happens:

R1 is the source of the multicast and pings

R3 initiates SPT switchover after 1 packet (default?).

R6 responds to the pings (sometimes R1 gets 2 replies...).

Abnormal behavior (or not?):

When I restrict the groups for which R4 can act as RP,

R3 still performs a switchover for other groups...

ip pim rp-address

ip pim accept-rp 8

access-list 8 permit


Type escape sequence to abort.

Sending 1, 100-byte ICMP Echos to, timeout is 2 seconds:

Reply to request 0 from, 292 ms

R6 still replies even though R4 refused to be the RP!


00:38:09: %PIM-1-INVALID_RP_REG: Received Register from for, not willing to be RP

R3#show ip mroute

IP Multicast Routing Table

Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,

L - Local, P - Pruned, R - RP-bit set, F - Register flag,

T - SPT-bit set, J - Join SPT, M - MSDP created entry,

X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,

U - URD, I - Received Source Specific Host Report,

Z - Multicast Tunnel, z - MDT-data group sender,

Y - Joined MDT-data group, y - Sending to MDT-data group

Outgoing interface flags: H - Hardware switched, A - Assert winner

Timers: Uptime/Expires

Interface state: Interface, Next-Hop or VCD, State/Mode

(*,, 00:15:07/00:03:22, RP, flags: SF

Incoming interface: Serial1/3, RPF nbr

Outgoing interface list:

Serial1/1, Forward/Sparse, 00:14:54/00:03:22

(,, 00:00:53/00:02:43, flags: FT

Incoming interface: Serial1/0, RPF nbr

Outgoing interface list:

Serial1/1, Forward/Sparse, 00:00:53/00:03:22

All interfaces are PIM-SM not sparse-dense mode.

I originally thought that maybe was acting in PIM-DM, but

I don't think that is the issue.

Am I misunderstanding how this should work?

I think that R4 should refuse to be RP for and thus no traffic for this group should be allowed to flow toward R6.



I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Harold Ritter Mon, 04/14/2008 - 17:38


- R5 is the one that will send the pim join towards the SPT upon reception of the first multicast packet.

- It is normal behavior for the receiver to get duplicate packets while transitioning from the RPT to the SPT.

- As for the accept-rp command on R3, I suppose that the multicast flow, was already started before you configured the command. If you want to see the command take effect, just clear the mroute for that flow on R3.


Harold Ritter Mon, 04/14/2008 - 19:14


Just a clarification. If the stream was already started before you applied the accept-rp, you need to stop the receiver and clear the mroute on r3 and r5. Otherwise, the join will go up the SPT and the accept-rp has no effect.



This Discussion