RE: IP Multicast - tunnel between Spokes in NBMA

From: Ali Sheeraz Mehdi (ali.mehdi@atosorigin-me.com)
Date: Wed Dec 06 2006 - 19:44:31 ART


Thanks for the help Bob. I will read more about spt cutover.

Regards
Ali

-----Original Message-----
From: Bob Sinclair [mailto:bsinclair@netmasterclass.net]
Sent: Thursday, December 07, 2006 2:44 AM
To: ali.mehdi@atosorigin-me.com
Cc: 'Cisco certification'
Subject: RE: IP Multicast - tunnel between Spokes in NBMA

Ali,

No, if your spoke 1 is the source it would not need a static mroute.
Consider that if spoke 1 is the source, then it really has no need for the
multicast redistribution tree; it does not need PIM at all to initiate
multicast traffic.

The most common reason I have seen for your problem - a ping or two then
nothing - is failure of the spt cutover. Not sure what is going on in your
case.

HTH,

-Bob Sinclair
CCIE 10427, CCSI 30427
www.netmasterclass.net

-----Original Message-----
From: Ali Sheeraz Mehdi [mailto:ali.mehdi@atosorigin-me.com]
Sent: Wednesday, December 06, 2006 5:32 PM
To: 'Bob Sinclair'
Cc: 'Cisco certification'
Subject: RE: IP Multicast - tunnel between Spokes in NBMA

Hi Bob,

Actually I moved on to the next practice lab. But I did configure 'static
mroute to tunnel interface' on Spoke 2. Do I need to configure it on Spoke 1
as well? Spoke 1 has actually initiated ping and router behind spoke 2 has
igmp join-group. Also I verified several times that the incoming interface
is tunnel. But it shows OIL as null on Spoke 1.

Regards
Ali

-----Original Message-----
From: Bob Sinclair [mailto:bsinclair@netmasterclass.net]
Sent: Wednesday, December 06, 2006 5:32 PM
To: 'Ali Sheeraz Mehdi'
Cc: 'Cisco certification'
Subject: RE: IP Multicast - tunnel between Spokes in NBMA

Ali,

This is typical of what happens spt-cutover fails. It is possible that the
shared tree (*,G) tree is working (you have a good rpf lookup to the RP),
but the RPF lookup to the source (S,G) is wrong. When you examine the (S,G)
state, using show ip mroute, what is the "incoming interface"? Make sure it
is the tunnel by using a static mroute. Can you send the output from "show
ip mroute"?

Bob Sinclair
CCIE 10427 CCSI 30427
www.netmasterclass.net

-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of Ali
Sheeraz Mehdi
Sent: Wednesday, December 06, 2006 5:39 AM
To: ccielab@groupstudy.com
Subject: IP Multicast - tunnel between Spokes in NBMA

Hi Guys,

 

I have a problem in PIM-Sparse mode, there is a restriction not to use ip
pim nbma-mode on Hub, so the only option left is tunnel between spokes. I
did that, the tunnel is up, (no Tunnel-Recursive error as well), but when I
try to ping to a multicast group from Spoke 1 to a router behind Spoke 2,
only first ping is successful. After that all the requests fail. Need help
to resolve this issue.

 

Thanks

Ali

 

 

 

 

Rack1R4#ping 226.26.26.26 source fas0/0

 

Type escape sequence to abort.

 

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

 

Packet sent with a source address of 187.1.4.4

 

Reply to request 0 from 187.1.17.7, 176 ms

 

 

Rack1R4#ping 226.26.26.26 source fas0/0

 

Type escape sequence to abort.

 

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

 

Packet sent with a source address of 187.1.4.4

 

.

 

 

Rack1R4#ping 226.26.26.26 source fas0/0

 

Type escape sequence to abort.

 

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

 

Packet sent with a source address of 187.1.4.4

 

 

Debug Output

 

 *Mar 2 11:47:24.347: PIM(0): Received v2 Join/Prune on Tunnel0 from
187.1.14.1, to us

 

*Mar 2 11:47:24.347: PIM(0): Join-list: (*, 228.34.28.100), RPT-bit set,
WC-bit set, S-bit set

 

*Mar 2 11:47:24.347: PIM(0): Update Tunnel0/187.1.14.1 to (*,
228.34.28.100), Forward state, by PIM *G Join

 

*Mar 2 11:47:24.347: MRT(0): Update Tunnel0/224.0.0.2 in the olist of (*,
228.34.28.100), Forward state - MAC not built.

 

*Mar 2 11:47:26.047: PIM(0): Received v2 Bootstrap on Serial2/0.134 from
187.1.134.3

 

*Mar 2 11:47:26.047: PIM(0): Update (224.0.0.0/5, RP:187.1.134.4), PIMv2

 

*Mar 2 11:47:26.047: PIM(0): Update (232.0.0.0/5, RP:187.1.235.5), PIMv2

 

*Mar 2 11:47:36.663: PIM(0): Received v2 Join/Prune on Tunnel0 from
187.1.14.1, to us

 

*Mar 2 11:47:36.663: PIM(0): Join-list: (187.1.4.4/32, 226.26.26.26), S-bit
set

 

*Mar 2 11:47:36.663: PIM(0): Update Tunnel0/187.1.14.1 to (187.1.4.4,
226.26.26.26), Forward state, by PIM SG Join

 

*Mar 2 11:47:36.663: MRT(0): Update Tunnel0/224.0.0.2 in the olist of
(187.1.4.4, 226.26.26.26), Forward state - MAC built

 

*Mar 2 11:47:40.535: PIM(0): Received v2 Register on Serial2/0.134 from
187.1.134.1

 

*Mar 2 11:47:40.535: PIM(0): Send v2 Register-Stop to 187.1.134.1 for
0.0.0.0, group 0.0.0.0

 

Rack1R4#

 

*Mar 2 11:47:42.055: PIM(0): Building Periodic Join/Prune message for
226.26.26.26

 

*Mar 2 11:47:43.767: PIM(0): Received v2 Join/Prune on Tunnel0 from
187.1.14.1, to us

 

*Mar 2 11:47:43.767: PIM(0): Join-list: (*, 226.26.26.26), RPT-bit set,
WC-bit set, S-bit set

 

*Mar 2 11:47:43.767: PIM(0): Update Tunnel0/187.1.14.1 to (*,
226.26.26.26), Forward state, by PIM *G Join

 

*Mar 2 11:47:43.767: MRT(0): Update Tunnel0/224.0.0.2 in the olist of (*,
226.26.26.26), Forward state - MAC built

 

*Mar 2 11:47:43.767: PIM(0): Update Tunnel0/187.1.14.1 to (187.1.4.4,
226.26.26.26), Forward state, by PIM *G Join

 

*Mar 2 11:47:43.767: MRT(0): Update Tunnel0/224.0.0.2 in the olist of
(187.1.4.4, 226.26.26.26), Forward state - MAC built

 

*Mar 2 11:47:43.767: PIM(0): Prune-list: (187.1.14.4/32, 226.26.26.26)
RPT-bit set

 

*Mar 2 11:47:59.055: PIM(0): Send RP-reachability for 226.26.26.26 on
Tunnel0



This archive was generated by hypermail 2.1.4 : Tue Jan 02 2007 - 07:50:37 ART