From: Daniel Valle (danielfrvalle@gmail.com)
Date: Sat Mar 29 2008 - 23:45:32 ART
Hi Bob,
This is exactly what's happening (I enabled PIM and mpacket debug)
********************************
***************************
Rack1R2
00:27:54: PIM(0): Building Periodic (*,G) Join / (S,G,RP-bit) Prune message
for 224.3.3.3
00:27:55: PIM(0): Received v2 Join/Prune on Serial1/0 from 1.1.123.3, to us
00:27:55: PIM(0): Join-list: (*, 224.3.3.3), RPT-bit set, WC-bit set, S-bit
set
00:27:55: PIM(0): Update Serial1/0/1.1.123.3 to (*, 224.3.3.3), Forward
state, by PIM *G Join
00:28:11: IP(0): s=1.1.123.1 (Serial1/0) d=224.3.3.3 (Serial1/0) id=26,
ttl=254, prot=1, len=100(100), mforward
00:28:11: PIM(0): Received v2 Register on Serial1/0 from 1.1.123.1
00:28:11: for 1.1.11.1, group 224.3.3.3
00:28:11: PIM(0): Insert (1.1.11.1,224.3.3.3) join in nbr 1.1.123.1's queue
00:28:11: PIM(0): Forward decapsulated data packet for 224.3.3.3 on
Serial1/0
00:28:11: PIM(0): Building Join/Prune packet for nbr 1.1.123.1
00:28:11: PIM(0): Adding v2 (1.1.11.1/32, 224.3.3.3), S-bit Join
00:28:11: PIM(0): Send v2 join/prune to 1.1.123.1 (Serial1/0)
00:28:11: PIM(0): Received v2 Register on Serial1/0 from 1.1.123.3
00:28:11: for 1.1.123.1, group 224.3.3.3
00:28:11: PIM(0): Send v2 Register-Stop to 1.1.123.3 for 1.1.123.1, group
224.3.3.3
00:28:12: PIM(0): Received v2 Join/Prune on Serial1/0 from 1.1.123.3, to us
00:28:12: PIM(0): Prune-list: (1.1.123.1/32, 224.3.3.3) RPT-bit set
00:28:12: PIM(0): Prune Serial1/0/1.1.123.3 from (1.1.123.1/32, 224.3.3.3) -
deleted
00:28:12: PIM(0): Prune-list: (1.1.11.1/32, 224.3.3.3) RPT-bit set
00:28:12: PIM(0): Prune Serial1/0/1.1.123.3 from (1.1.11.1/32, 224.3.3.3)
00:28:12: PIM(0): Insert (1.1.11.1,224.3.3.3) prune in nbr 1.1.123.1's queue
- deleted
00:28:12: PIM(0): Building Join/Prune packet for nbr 1.1.123.1
00:28:12: PIM(0): Adding v2 (1.1.11.1/32, 224.3.3.3), S-bit Prune
00:28:12: PIM(0): Send v2 join/prune to 1.1.123.1 (Serial1/0)
00:28:13: IP(0): s=1.1.123.1 (Serial1/0) d=224.3.3.3 id=27, ttl=254, prot=1,
len=104(100), mroute olist null
00:28:13: PIM(0): Received v2 Register on Serial1/0 from 1.1.123.1
00:28:13: for 1.1.11.1, group 224.3.3.3
00:28:13: PIM(0): Send v2 Register-Stop to 1.1.123.1 for 1.1.11.1, group
224.3.3.3
00:28:13: PIM(0): Forward decapsulated data packet for 224.3.3.3 on
Serial1/0
00:28:15: IP(0): s=1.1.123.1 (Serial1/0) d=224.3.3.3 id=28, ttl=254, prot=1,
len=104(100), mroute olist null
00:28:17: IP(0): s=1.1.123.1 (Serial1/0) d=224.3.3.3 id=29, ttl=254, prot=1,
len=104(100), mroute olist null
00:28:19: IP(0): s=1.1.123.1 (Serial1/0) d=224.3.3.3 id=30, ttl=254, prot=1,
len=104(100), mroute olist null
***************************
***************************
HUB:
!
interface Loopback0
ip address 1.1.2.2 255.255.255.0
ip pim sparse-mode
!
!
interface Serial1/0
ip address 1.1.123.2 255.255.255.0
ip pim nbma-mode
ip pim sparse-mode
encapsulation frame-relay
no ip mroute-cache
ip ospf hello-interval 2
ip ospf priority 255
serial restart-delay 0
frame-relay map ip 1.1.123.3 203 broadcast
frame-relay map ip 1.1.123.1 201 broadcast
frame-relay map ip 1.1.123.2 201
no frame-relay inverse-arp
!
router ospf 2
router-id 1.1.2.2
log-adjacency-changes
network 1.1.2.2 0.0.0.0 area 0
network 1.1.123.2 0.0.0.0 area 0
neighbor 1.1.123.1
neighbor 1.1.123.3
!
!
ip pim send-rp-announce Loopback0 scope 255 group-list MCAST interval 10
ip pim send-rp-discovery Loopback0 scope 255 interval 10
!
ip access-list standard MCAST
permit 224.3.3.3
!
***************************
SKOPE R1 (ROUTER IS SENDING THE PINGS)
interface Loopback0
ip address 1.1.1.1 255.255.255.0
!
interface FastEthernet0/0
ip address 1.1.11.1 255.255.255.0
ip pim sparse-mode
speed 100
full-duplex
!
interface Serial1/0
ip address 1.1.123.1 255.255.255.0
ip pim sparse-mode
encapsulation frame-relay
no ip mroute-cache
ip ospf hello-interval 2
ip ospf priority 0
serial restart-delay 0
frame-relay map ip 1.1.123.3 102
frame-relay map ip 1.1.123.1 102
frame-relay map ip 1.1.123.2 102 broadcast
no frame-relay inverse-arp
!
router ospf 2
router-id 1.1.1.1
log-adjacency-changes
network 1.1.1.1 0.0.0.0 area 0
network 1.1.11.1 0.0.0.0 area 0
network 1.1.123.1 0.0.0.0 area 0
!
!
***************************
SPOKE R3 ( SITE IS THE CLIENT)
!
interface Loopback0
ip address 1.1.3.3 255.255.255.0
!
interface FastEthernet0/0
ip address 1.1.33.3 255.255.255.0
ip pim sparse-mode
ip igmp join-group 224.3.3.3
speed 100
full-duplex
!
interface Serial1/0
ip address 1.1.123.3 255.255.255.0
ip pim sparse-mode
encapsulation frame-relay
no ip mroute-cache
ip ospf hello-interval 2
ip ospf priority 0
serial restart-delay 0
frame-relay map ip 1.1.123.3 302
frame-relay map ip 1.1.123.1 302
frame-relay map ip 1.1.123.2 302 broadcast
no frame-relay inverse-arp
!
router ospf 2
router-id 1.1.3.3
log-adjacency-changes
network 1.1.3.3 0.0.0.0 area 0
network 1.1.33.3 0.0.0.0 area 0
network 1.1.123.3 0.0.0.0 area 0
!
===============================================
===============================================
Well. Is this something unfixable ? I mean, there is no way to have such
requirement with non-broadcast network type in this Multicast scenario ?
Thanks again !!
Daniel.
On Sat, Mar 29, 2008 at 10:02 PM, Bob Sinclair <bob@bobsinclair.net> wrote:
> Daniel Valle wrote:
> > R2 is the MA and is also the RP for the mcast groups
> >
> > R1 and R3 are Spokes
> >
> > R3 f0/0 is set to ip igmp join-group 224.3.3.3
> >
> > If I set the FR network as OSPF network
> > point-to-multipoint the R1 ( spoke) pings 224.3.3.3 just fine, if I set
> the
> > network to the default ( non broadcast), it does not work.
> >
> >
> >
> Daniel,
>
> I assume you are running NBMA-mode on the hub. As I understand your
> scenario: with the non--broadcast OSPF network type you get a few pings
> then nothing.
>
> Here is what could explain this:
>
> You get a few packets on the shared tree and R3 responds. R3 sends a
> source-tree join, gets another packet on the shared tree, and sends a
> shared tree prune. R2, the hub, ignores the source tree join because it
> does not have its address as the upstream neighbor. The source-tree
> join has R3's address. With the non-broadcast OSPF network type the
> routers model the underlying Layer 2 as multi-access.
>
> In sparse mode, R3 is not supposed to prune off the shared tree until it
> gets packets on the source tree. The failure of the source tree is
> hidden by the fact that on R3 the shared tree RPF and the source tree
> RPF are the same interface.
>
> Try repeating the experiment while sending debug ip pim to the buffer.
> I would expect you to see the ping fail after the shared tree prune goes
> out to R2. You can tell the shared tree prune: it will be sent to R2
> (actually multicast to 224.0.0.13, but addressed in the data portion)
> and it will have the RPT bit set.
>
> HTH,
>
> Bob Sinclair
> Netmasterclass.net
This archive was generated by hypermail 2.1.4 : Tue Apr 01 2008 - 07:53:54 ART