Re: Multicast and NBMA again...

From: Daniel Valle (danielfrvalle@gmail.com)
Date: Sat Mar 29 2008 - 22:57:55 ART


Hi Joseph. I'm using Auto RP, not bsr.
I passed all day long working on that and I couldn't get the point yet.

Hi Bob,

Thanks for your explanation I'll try to get this debug and I'll send you
now.. meanwhile, Do you know how can we fix this issue without using gre
tunnel ? I'm making the same scenario with different ospf network types
because I don't know what will be the requirement in the LAB exam... I mean
if they ask me is the ospf questions to not touch network types, I'll fail
the mcast question... so I''m trying to see all the possible solutions,

I'll update you soon and thanks for the help.

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