04-14-2008 04:25 PM - edited 03-03-2019 09:33 PM
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
04-14-2008 05:38 PM
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,
04-14-2008 07:14 PM
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,
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide