From: Chan Hong (chan_hong33@yahoo.com)
Date: Thu Dec 06 2007 - 00:55:40 ART
I tried it on my lab and found something interesting. My lab is using 3
routers to similate your case.
R1(fa0/0)---(fa0/0)R2(fa0/1)---(fa0/1)R3(fa0/0, ip igmp join 233.23.23.23)
R3
is C-RP & MA. R2 is able to ping 233.23.23, R1 isn't.
sh ip mroute
233.23.23.23 on R1:
r1>sh ip mroute 233.23.23.23
Group 233.23.23.23 not found
Ping on R2 and sh ip mroute again on R1
r2>ping 233.23.23.23
IP broadcast
ping disallowed from EXEC user level
r2>en
r2#ping 233.23.23.23
Type escape
sequence to abort.
Sending 1, 100-byte ICMP Echos to 233.23.23.23, timeout is
2 seconds:
Reply to request 0 from 155.1.23.3, 4 ms
r2#
r1#sh ip mroute
233.23.23.23
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
Y - Joined MDT-data group, y - Sending to MDT-data
group
Outgoing interface flags: H - Hardware switched
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 233.23.23.23),
00:00:03/stopped, RP 150.1.3.3, flags: SP
Incoming interface:
FastEthernet0/0, RPF nbr 155.1.129.2
Outgoing interface list: Null
(155.1.129.2, 233.23.23.23), 00:00:03/00:02:56, flags: PT
Incoming
interface: FastEthernet0/0, RPF nbr 0.0.0.0
Outgoing interface list: Null
r1#sh ip pim rp map
PIM Group-to-RP Mappings
Group(s) 224.0.0.0/4
RP
150.1.3.3 (?), v2v1
Info source: 150.1.3.3 (?), elected via Auto-RP
Uptime: 00:29:27, expires: 00:02:19
r1#
After that, R1 is able to ping
233.23.23.23!
r1#ping 233.23.23.23
Type escape sequence to abort.
Sending 1,
100-byte ICMP Echos to 233.23.23.23, timeout is 2 seconds:
Reply to request 0
from 155.1.23.3, 4 ms
r1#ping 233.23.23.23
Then clear ip mroute * on R2, R1
isn't able to ping again. below is the debug all message when R1 don't have rp
mapping and r2 is pinging to 233.23.23.23
r1#debug all
This may severely
impact network performance. Continue? (yes/[no]): yes
All possible debugging
has been turned on
r1#
*Mar 1 00:05:15.463: OSPF: Send hello to 224.0.0.5
area 0 on FastEthernet0/0 from 155.1.129.1
*Mar 1 00:05:15.463: IP:
s=155.1.129.1 (local), d=224.0.0.5 (FastEthernet0/0),len 80, sending
broad/multicast
*Mar 1 00:05:16.123: IP-ST: if_list try 0
*Mar 1
00:05:16.123: IP-ST: gw_list total 0, try 0, completed list TRUE
*Mar 1
00:05:16.123: IP-Static: all_list, time elapsed 0 ms
*Mar 1 00:05:17.451:
MRT(0): Start 0x838A0D48 [1738] expire timer (*, 233.23.23.23) delay 180 sec
*Mar 1 00:05:17.451: MRT(0): Start 0x838A0D34 [2939] mdfs_mroute_update check
(*, 233.23.23.23) delay 0 msec
*Mar 1 00:05:17.451: MRC(0): Fast-switch flag
for (0.0.0.0/32, 233.23.23.23), off -> on, caller ip_add_mroute
*Mar 1
00:05:17.451: MRT(0): Start 0x838A0CD0 [535] send join timer (*, 233.23.23.23)
delay 59 sec
*Mar 1 00:05:17.451: PIM(0): Check RP 150.1.3.3 into the (*,
233.23.23.23) entry
*Mar 1 00:05:17.451: MRT(0): Create (*,233.23.23.23), RPF
FastEthernet0/0/155.1.129.2
*Mar 1 00:05:17.455: MRT(0): Start 0x838A0D48
[1738] expire timer (*, 233.23.23.23) delay 180 sec
*Mar 1 00:05:17.455:
MRT(0): Stop 0x838A0D48 [1738] expire timer (*, 233.23.23.23)
*Mar 1
00:05:17.455: MRT(0): Start 0x838A0D48 [1738] expire timer (155.1.129.2,
233.23.23.23) delay 180 sec
*Mar 1 00:05:17.455: MRT(0): Create
(155.1.129.2,233.23.23.23), RPF FastEthernet0/0/0.0.0.0
*Mar 1 00:05:17.455:
MRT(0): Start 0x838A0CE4 [2939] mdfs_mroute_update check (155.1.129.2,
233.23.23.23) delay 0 msec
*Mar 1 00:05:17.459: MRC(0): Fast-switch flag for
(155.1.129.2/32, 233.23.23.23), off -> on, caller ip_add_mroute_update
ignored, SPT-flag
*Mar 1 00:05:17.459: MRT(0): Start 0x838A0CA8 [2939] send
prune timer (155.1.129.2, 233.23.23.23) delay 0 msec
*Mar 1 00:05:17.459:
MRC(0): Fast-switch flag for (155.1.129.2/32, 233.23.23.23), off -> on, caller
ip_set_mdb_flag
*Mar 1 00:05:17.459: IP(0): s=155.1.129.2 (FastEthernet0/0)
d=233.23.23.23 id=2, prot=1, len=114(100), mroute olist null
*Mar 1
00:05:17.527: MRT(0): Processing send prune timer (155.1.129.2, 233.23.23.23)
*Mar 1 00:05:17.527: MRT(0): Processing mdfs_mroute_update check
(155.1.129.2,233.23.23.23)
*Mar 1 00:05:17.527: MRT(0): Processing
mdfs_mroute_update check (*, 233.23.23.23)
*Mar 1 00:05:17.563: IP:
s=155.1.129.2 (FastEthernet0/0), d=224.0.0.5, len 80,rcvd 0
*Mar 1
00:05:17.563: OSPF: rcv. v:2 t:1 l:48 rid:202.2.2.2 aid:0.0.0.0 chk:1D8B
aut:0 auk: from FastEthernet0/0
*Mar 1 00:05:17.563: OSPF: Rcv hello from
202.2.2.2 area 0 from FastEthernet0/0 155.1.129.2
*Mar 1 00:05:17.563: OSPF:
End of hello processing
*Mar 1 00:05:17.735: CDP-EV: Unrecognized type (16)
seen in TLV
*Mar 1 00:05:17.735: CDP-PA: Packet received from sw1 on
interface FastEthernet0/0
*Mar 1 00:05:17.735: **Entry found in cache**
*Mar
1 00:05:17.939: IP: s=155.1.129.2 (FastEthernet0/0), d=224.0.0.13, len 54,
rcvd 0
*Mar 1 00:05:17.939: PIM(0): Received v2 hello on FastEthernet0/0 from
155.1.129.2
*Mar 1 00:05:18.619: SNMP: HC Timer 8369C8A4 fired
*Mar 1
00:05:18.619: SNMP: HC Timer 8369C8A4 rearmed, delay = 5000
*Mar 1
00:05:19.919: PIM(0): Send periodic v2 Hello on FastEthernet0/0
*Mar 1
00:05:19.919: IP: s=155.1.129.1 (local), d=224.0.0.13 (FastEthernet0/0), len
54, sending broad/multicast
*Mar 1 00:05:21.303: MRT(0): Start 0x838A0D48
[1776] expire timer (155.1.129.2, 233.23.23.23) delay 180 sec
un all
All
possible debugging has been turned off
r1#
*Mar 1 00:05:23.619: SNMP: HC
Timer 8369C8A4 fired
*Mar 1 00:05:23.619: SNMP: HC Timer 8369C8A4 rearmed,
delay = 5000
*Mar 1 00:05:24.435: --> pm_eswilp_extend_trust_for_idb
*Mar 1
00:05:24.435: --> pm_eswilp_extend_trust_for_idb
*Mar 1 00:05:24.435: CDP-PA:
version 2 packet sent out on FastEthernet0/0
*Mar 1 00:05:24.435: -->
pm_eswilp_extend_trust_for_idb
*Mar 1 00:05:24.435: -->
pm_eswilp_extend_trust_for_idb
*Mar 1 00:05:24.435: CDP-PA: version 2 packet
sent out on FastEthernet0/1
*Mar 1 00:05:24.491:
*Mar 1 00:05:24.491: Rudpv1
Sent: Pkts 0, Data Bytes 0, Data Pkts 0
*Mar 1 00:05:24.491: Rudpv1 Rcvd:
Pkts 0, Data Bytes 0, Data Pkts 0
*Mar 1 00:05:24.491: Rudpv1 Discarded: 0,
Retransmitted 0
*Mar 1 00:05:24.491: sh ip mroute 233.23.23.23
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
Y - Joined
MDT-data group, y - Sending to MDT-data group
Outgoing interface flags: H -
Hardware switched
Timers: Uptime/Expires
Interface state: Interface,
Next-Hop or VCD, State/Mode
(*, 233.23.23.23), 00:00:26/stopped, RP 150.1.3.3,
flags: SP
Incoming interface: FastEthernet0/0, RPF nbr 155.1.129.2
Outgoing interface list: Null
(155.1.129.2, 233.23.23.23), 00:00:26/00:02:37,
flags: PT
Incoming interface: FastEthernet0/0, RPF nbr 0.0.0.0
Outgoing
interface list: Null
r1#
----- 6l%s-l%s ----
1H%s$H!R "Gupta, Gopal (NWCC)"
<gopal.gupta@hp.com>
&,%s$H "Gupta, Gopal (NWCC)" <gopal.gupta@hp.com>; Chan
Hong <chan_hong33@yahoo.com>; Gregory Gombas <ggombas@gmail.com>
0F%;(CC)
Cisco certification <ccielab@groupstudy.com>
6G0e$i4A!R 2007 &~ 12$k 6 $i
,P4A%| $W$H 12:36:18
%DCD!G RE: Re!G PIM Auto-RP
M sorry for that i meant
to say SPARSE mode and not DENSE mode
From: Gupta, Gopal (NWCC)
Sent:
Wednesday, December 05, 2007 21:53
To: 'Chan Hong'; Gregory Gombas
Cc: Cisco
certification
Subject: RE: Re!G PIM Auto-RP
Hi Chan,
i agree with you that
using static RP on R5 or create an tunnel between R5 & R4 can overcome this
problem...
but my problem is it is happening without tunnel without static RP
and without auto RPListener (ALL being in DENSE mode)
Thanks
Gopal
From:
Chan Hong [mailto:chan_hong33@yahoo.com]
Sent: Wednesday, December 05, 2007
21:05
To: Gregory Gombas; Gupta, Gopal (NWCC)
Cc: Cisco certification
Subject:
Re!G PIM Auto-RP
Dear Gopal,
I think R5 can't know the RP address of the
groups 224.0.1.39&40. Do you think that using static RP on R5 or create an
tunnel between R5 & R4 can overcome this problem?
Dear Gombas,
With
frame-relay inverse arp, dynamic mapping occur on frame-relay circuit. In
dense mode, the multicast traffic just push to the interface and every mapping
are able to receive the multicast traffic. In sparse mode, without ip pim nbma
, all mapping should able to receive the multicast traffic also.
Please
correct me if wrong.
Thanks & Regards,
Howard
----- 6l%s-l%s ----
1H%s$H!R
Gregory Gombas <ggombas@gmail.com>
&,%s$H "Gupta, Gopal (NWCC)"
<gopal.gupta@hp.com>
0F%;(CC) Cisco certification <ccielab@groupstudy.com>
6G0e$i4A!R 2007 &~ 12$k 5 $i ,P4A$T $U$H 10:06:49
%DCD!G Re: PIM Auto-RP
Hi
Gopal,
Is it possible the MA has a 0.0.0.0 mapping for R5 in its frame relay
mapping table and its multicasting out the DLCI?
I've seen similar issues when
forgetting to disable frame-relay inverse arp...
On Dec 4, 2007 7:41 AM,
Gupta, Gopal (NWCC) <gopal.gupta@hp.com> wrote:
> Hi Gurus
> There is one
question, am scratching my head
>
> Topology
>
> R5->R1->R4
> |
>
R3
> |
> R2
>
> R4 is MA and R3 is RP
>
> Question
is w/o using IP Pim autorp listener and all interfaces in
> Sparse mode, R4 is
still sending the group-RP mappings to all the
> Routers including R5; is this
the default behavior ??
> The problem is R5 should not recv these mappings
from R4 coz all is
> running in Sparse mode.
>
> R5:-->
>
> R5#sh ip mr
>
>
(*, 224.0.1.40), 01:10:44/stopped, RP 0.0.0.0, flags: DCL
> Incoming
interface: Null, RPF nbr 0.0.0.0
> Outgoing interface list:
>
Serial1/0.504, Forward/Sparse, 01:10:44/00:01:32
>
> (204.12.1.4, 224.0.1.40),
01:10:43/00:02:54, flags: PLTX
> Incoming interface: Serial1/0.504, RPF nbr
155.1.15.1
> Outgoing interface list: Null
>
> R5#sh ip pim rp ma
> PIM
Group-to-RP Mappings
>
> Group(s) 224.0.0.0/4
> RP 150.1.3.3 (?), v2v1
>
Info source: 204.12.1.4 (?), elected via Auto-RP
> Uptime: 01:10:47,
expires: 00:02:49
>
> As far as i have studied till now is we need either PIM
Sparse-dense
> mode or pim AutoRP Listener for getting group to RP mappings
and it is
> working W/O those commands.
> Hope you will throw some light on
this.
>
> Many Thanks,
> Gops
>
>
This archive was generated by hypermail 2.1.4 : Tue Jan 01 2008 - 12:04:29 ARST