spoke-to-spoke mapping is required but hence Maureen have to use word broadcast with mapping in case of RIP else multicast wont work out because it will be spoke to spoke mapping! but if you suppose to use OSPF with multipoint-to-multipoint ospf on frame-relay interfaces issue will be solved, because now OSPF itself is responsible to carry the Multicast traffic over frame-relay not the frame-relay.
Regards Sheraz > Date: Thu, 3 Jan 2013 03:38:05 +0400 > From: [email protected] > To: [email protected] > Subject: [OSL | CCIE_RS] Fwd: pim nbma mode > > ---------- Forwarded message ---------- > From: Saleh Batouq <[email protected]> > Date: Thu, Jan 3, 2013 at 3:36 AM > Subject: Re: [OSL | CCIE_RS] pim nbma mode > To: Maureen Maina <[email protected]> > > > Hi Maureen, > > I don't think so. The broadcast keyword is needed only once per each dlci. > so if you add it in the map statement to the hub its enough. Why its needed > for SPOKE-to-SPOKE is because the multicast ping is sourced from that spoke > ip-address so a map is needed for it in order to be replied to. Plus as you > mention RIP and OSPF (NBMA) does not change the next-hop address so spoke > to spoke reachability is required and the only way is to have FR-MAPS to > each other. > > Are you using GNS or real Racks. Sometimes GNS has some issues with > multicasts. Try to repeat the ping several times you should get a response. > > Good luck mate. > > > On Wed, Jan 2, 2013 at 4:49 PM, Maureen Maina <[email protected]> wrote: > > > 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 > >> > > > > > > > -- > Best Regards, > > Saleh Hassan Batouq > [email protected] > Tel: +968 99365607 > Fax: +968 2469690 > P.O.Box:1083- Postal Code:112 > Muscat-Sultanate Of Oman > > > > -- > 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 _______________________________________________ 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
