From: E Toohs (mr_fantasy_1978@yahoo.com)
Date: Mon Apr 14 2008 - 21:33:32 ART
Hello,
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
em
Pass the CCIE in six weeks, Guaranteed!
http://www.certscience.com/CCIE
This archive was generated by hypermail 2.1.4 : Thu May 01 2008 - 08:25:51 ART