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

[dodgerfan78]

Topology:

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 239.0.0.6 and 239.0.0.8

What normally happens:

R1 is the source of the multicast and pings 239.0.0.6.

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 4.4.4.4

ip pim accept-rp 4.4.4.4 8

access-list 8 permit 239.0.0.6

R1#ping 239.0.0.8

Type escape sequence to abort.

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

Reply to request 0 from 172.12.25.6, 292 ms

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

R4#

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

R3#show ip mroute 239.0.0.8

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

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

Incoming interface: Serial1/3, RPF nbr 172.12.34.4

Outgoing interface list:

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

(172.12.13.1, 239.0.0.8), 00:00:53/00:02:43, flags: FT

Incoming interface: Serial1/0, RPF nbr 0.0.0.0

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 239.0.0.8 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 239.0.0.8 and thus no traffic for this group should be allowed to flow toward R6.

Thanks,

Bryan

[Harold Ritter]

Bryan,

- 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 172.12.13.1,239.0.0.8 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.

Regards,

[Harold Ritter]

Bryan,

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.

Regards,