From: Daniel Valle (danielfrvalle@gmail.com)
Date: Sun Mar 30 2008 - 12:23:54 ART
Hi Shine,
Good to you it is working! I tried that with BSR and Auto-RP. and it didn't
work,... I thought at first sight it was a dynamips problem, but then I rent
a rack session and the problem persisted.
this is the same config I set for my lab and it stops working afer the SPT
is prunned.
can you re-run your tests please and send me the debug?
Thanks in advance,
Daniel.
On Sat, Mar 29, 2008 at 10:25 PM, Shine Joseph <shinepjoseph@iprimus.com.au>
wrote:
> Daniel,
>
> I have labbed up your topology and I don't see the issue what you are
> experiencing. Please see below the details. R1 and R3 are spokes, R2 is
> hub
> with non-broadcast network type. I have got the same results with
> broadcast
> and point-multipoint ospf network types.
>
> R1
> ip address 172.16.123.1 255.255.255.0
> ip pim sparse-mode
> encapsulation frame-relay
> ip ospf network non-broadcast
> ip ospf hello-interval 1
> ip ospf priority 0
> no dce-terminal-timing-enable
> frame-relay map ip 172.16.123.1 102
> frame-relay map ip 172.16.123.2 102 broadcast
> frame-relay map ip 172.16.123.3 102
> no frame-relay inverse-arp
>
>
> R2
> interface Serial0/0
> ip address 172.16.123.2 255.255.255.0
> ip pim nbma-mode
> ip pim sparse-mode
> encapsulation frame-relay
> ip ospf network non-broadcast
> ip ospf hello-interval 1
> no dce-terminal-timing-enable
> frame-relay map ip 172.16.123.1 201 broadcast
> frame-relay map ip 172.16.123.2 203
> frame-relay map ip 172.16.123.3 203 broadcast
> no frame-relay inverse-arp
>
> ip pim bsr-candidate Loopback0 0
> ip pim rp-candidate Loopback0
>
> R3
> ip address 172.16.123.3 255.255.255.0
> ip pim sparse-mode
> encapsulation frame-relay
> ip ospf network non-broadcast
> ip ospf hello-interval 1
> ip ospf priority 0
> no dce-terminal-timing-enable
> frame-relay map ip 172.16.123.1 302
> frame-relay map ip 172.16.123.2 302 broadcast
> frame-relay map ip 172.16.123.3 302
> no frame-relay inverse-arp
>
> interface Ethernet1/0
> ip address 172.16.3.3 255.255.255.0
> ip igmp join-group 224.3.3.3
>
>
> R1(config-if)#do ping 224.3.3.3 repe 10
>
> Type escape sequence to abort.
> Sending 10, 100-byte ICMP Echos to 224.3.3.3, timeout is 2 seconds:
>
> Reply to request 0 from 172.16.123.3, 36 ms
> Reply to request 1 from 172.16.123.3, 36 ms
> Reply to request 2 from 172.16.123.3, 132 ms
> Reply to request 3 from 172.16.123.3, 36 ms
> Reply to request 4 from 172.16.123.3, 132 ms
> Reply to request 5 from 172.16.123.3, 36 ms
> Reply to request 6 from 172.16.123.3, 132 ms
> Reply to request 7 from 172.16.123.3, 132 ms
> Reply to request 8 from 172.16.123.3, 36 ms
> Reply to request 9 from 172.16.123.3, 36 ms
>
> Regards,
> Shine
>
>
> -----Original Message-----
> From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
> Daniel Valle
> Sent: Sunday, 30 March 2008 10:52 AM
> To: groupstudy
> Subject: Multicast and NBMA again...
>
> I know this has been over and over... but there are always new guys
> around.... so here it is again...
>
> I need your expertise . I am labbing up a Hub and spoke scenario.
>
> 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
>
> I'm running ospf in all networks.... all is area 0 ( very simple!)
>
> this is the isse I'm facig. 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.
>
> In one network type, or in the other, all unicasts pings works fine...
>
> with few investigation I saw that when My topology is set to
> non-broadcast,
> the mcast group gets "P"runned with 3 packets or less.... If the network
> is
> set to P2M, the ping works fine, the network does not get prunned and the
> "T" flag is set.
>
> I know P2M modifies the nex-hop value of the routes, but I know know what
> else could that make in order to make my topology not to work., I really
> don't knwo how that come... the pings stops because the network get's all
> prunned... not because of RF failure...actually neigher scenarios I face
> RPF
> problems.
>
>
> Thank you !!
>
> Daniel.
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
This archive was generated by hypermail 2.1.4 : Tue Apr 01 2008 - 07:53:54 ART