Hi Saleh,
The frame-relay mappings were present though not with the "broadcast"
 keyword as this is spoke to spoke.All spoke to hub mappings had the
broadcast keyword.
Maybe thats why it can be used to forward multicast traffic?


Regards,
Mo

On Mon, Dec 31, 2012 at 9:07 PM, Saleh Batouq <[email protected]> wrote:

> Hi Naureen,
>
> I replicated your topology using OSPF NMBA mode instead of RIP. It works
> fine.
> And from your output of the show routes it looks that both shared & source
> trees are built.
>
> *For pings to be replied  the spokes need frame-relay maps to each other
> (SPOKE-to-SPOKE). I assume you are missing this.*
>
> My outputs are similar to yours and ping works fine.
>
> SPOKE R1
> ----
>
> (*, 239.1.1.1), 00:10:29/stopped, RP 10.1.1.2, flags: SJCLF
>   Incoming interface: Serial0/0, RPF nbr 172.16.0.2
>   Outgoing interface list:
>     Loopback0, Forward/Sparse, 00:10:29/00:02:12
> !
> (10.1.1.3, 239.1.1.1), 00:00:58/00:02:07, flags: LJT
>   Incoming interface: Serial0/0, RPF nbr 172.16.0.3
>   Outgoing interface list:
>     Loopback0, Forward/Sparse, 00:00:58/00:02:12
> !
>
>
> SPOKE R3
> -----
>
> (*, 239.3.3.3), 00:10:35/stopped, RP 10.1.1.2, flags: SJCLF
>   Incoming interface: Serial0/0, RPF nbr 172.16.0.2
>   Outgoing interface list:
>     Loopback0, Forward/Sparse, 00:10:35/00:02:43
>
> (10.1.1.1, 239.3.3.3), 00:01:06/00:01:56, flags: LJT
>   Incoming interface: Serial0/0, RPF nbr 172.16.0.1
>   Outgoing interface list:
>     Loopback0, Forward/Sparse, 00:01:06/00:02:43
>
> On Mon, Dec 31, 2012 at 7:18 PM, Maureen Maina <[email protected]> wrote:
>
>> Hi,
>> I have a simple scenario of hub and spoke frame-relay. R1-R2-R3. I opt to
>> use pim nbma with sparse mode under the R2 interface to allow multicast
>> traffic from R1 to flow to R3.
>> However due to the fact I was using rip , the next hop remains unchanged
>> for all routes propagated from spoke to spoke. The RP is connected to the
>> hub R2. the source x.x.x.x is connected to R1 . A show ip mroute on R3 is
>> as follows..
>>
>> *NO STATIC RPF workaround needed.*
>
> regards,
>
>
>
>> (*, 232.2.2.2), 04:40:25/stopped, RP 172.16.200.13, flags: SJCL
>>   Incoming interface: Serial0/0/0:0, RPF nbr <R2 address>
>>   Outgoing interface list:
>>     Loopback102, Forward/Sparse, 04:40:25/00:02:24
>>
>> (x.x.x.x, 232.2.2.2), 00:06:07/00:00:43, flags: LJT
>>   Incoming interface: Serial0/0/0:0, RPF nbr <R1 address>
>>   Outgoing interface list:
>>     Loopback102, Forward/Sparse, 00:06:07/00:02:24
>>
>> So on the shared tree, all is well but when it switches to the source
>> based
>> tree , the pings dont go through.
>> When I apply an mroute x.x.x.x 255.255.255.255 <R2 address> it works!
>> Is this a rule of pim nbma that the hub must be seen as rpf neighbor?
>>
>> Regards,
>> Maureen
>> _______________________________________________
>> For more information regarding industry leading CCIE Lab training, please
>> visit www.ipexpert.com
>>
>> Are you a CCNP or CCIE and looking for a job? Check out
>> www.PlatinumPlacement.com
>>
>> http://onlinestudylist.com/mailman/listinfo/ccie_rs
>>
>
>
>
> --
> Best Regards,
>
> Saleh Hassan Batouq
> [email protected]
> Tel: +968 99365607
> Fax: +968 2469690
> P.O.Box:1083- Postal Code:112
> Muscat-Sultanate Of Oman
>
_______________________________________________
For more information regarding industry leading CCIE Lab training, please visit 
www.ipexpert.com

Are you a CCNP or CCIE and looking for a job? Check out 
www.PlatinumPlacement.com

http://onlinestudylist.com/mailman/listinfo/ccie_rs

Reply via email to