Hi Baldeep, This post is interesting, I noticed that you relied on Inverse-ARP so broadcast capability is on. I used static maps so I needed the broadcast on the hub.
Can you please tell us: 1- Does your spokes have maps to each other? 2- What are the static mroutes that you used. (Syntax please). On Thu, Jan 3, 2013 at 4:33 AM, Bal Birdy <[email protected]> wrote: > Saleh, > > Do we really need the frame-relay map broadcast on the hub !? Assume for a > moment that the hub is using physical interface for frame-relay connection, > then that supports broadcast by default (see output below), but > irrespective we have psuedo-broadcast capability - > > > Pooky#show frame-relay map > Serial0/0 (up): ip 192.168.234.2 dlci 402(0x192,0x6420), dynamic, > * broadcast,* > CISCO, status defined, active > Serial0/0 (up): ip 192.168.234.3 dlci 403(0x193,0x6430), dynamic, > * broadcast,* > CISCO, status defined, active > > What I noted was that in my debugs from the hub (see below), my pings > work. Then my spoke 192.168.234.2 sets the RPT so going into share tree > mode. So hub prunes my PIM NBMA interface to my spoke. Then everything > stops. > > *Mar 1 02:31:40.291: IP(0): s=3.3.3.3 (Serial0/0) d=224.1.1.1 (Serial0/0) > id=227, ttl=253, prot=1, len=100(100), mforward > *Mar 1 02:31:40.299: IP(0): s=3.3.3.3 (Serial0/0) d=224.1.1.1 > (FastEthernet1/0) id=227, ttl=253, prot=1, len=100(100), mforward > *Mar 1 02:31:40.311: IP(0): s=3.3.3.3 (Serial0/0) d=224.1.1.1 (Serial0/0) > id=227, ttl=253, prot=1, len=100(100), mforward > *Mar 1 02:31:40.319: IP(0): s=3.3.3.3 (Serial0/0) d=224.1.1.1 > (FastEthernet1/0) id=227, ttl=253, prot=1, len=100(100), mforward > *Mar 1 02:31:40.327: IP(0): s=192.168.234.3 (Serial0/0) d=224.1.1.1 > id=227, ttl=254, prot=1, len=104(100), mroute olist null > *Mar 1 02:31:40.327: IP(0): s=192.168.234.3 (Serial0/0) d=224.1.1.1 > id=227, ttl=254, prot=1, len=104(100), mroute olist null > *Mar 1 02:31:40.359: PIM(0): Received v2 Join/Prune on Serial0/0 from > 192.168.234.2, to us > **Mar 1 02:31:40.363: PIM(0): Prune-list: (3.3.3.3/32, 224.1.1.1) > RPT-bit set > *Mar 1 02:31:40.367: PIM(0):* *Prune Serial0/0/192.168.234.2 from ( > 3.3.3.3/32, 224.1.1.1) - deleted* > **Mar 1 02:31:40.383: PIM(0): Received v2 Join/Prune on Serial0/0 from > 192.168.234.2, to us > *Mar 1 02:31:40.383: PIM(0): Prune-list: (3.3.3.3/32, 224.1.1.1) RPT-bit > set* > **Mar 1 02:31:42.299: IP(0): s=192.168.234.3 (Serial0/0) d=224.1.1.1 > id=228, ttl=254, prot=1, len=104(100), mroute olist null > *Mar 1 02:31:42.311: IP(0): s=192.168.234.3 (Serial0/0) d=224.1.1.1 > id=228, ttl=254, prot=1, len=104(100), mroute olist null* > *Mar 1 02:31:42.319: IP(0): s=3.3.3.3 (Serial0/0) d=224.1.1.1 > (FastEthernet1/0) id=228, ttl=253, prot=1, len=100(100), mforward > *Mar 1 02:31:42.323: IP(0): s=3.3.3.3 (Serial0/0) d=224.1.1.1 > (FastEthernet1/0) id=228, ttl=253, prot=1, len=100(100), mforward > *Mar 1 02:31:42.931: PIM(0): Received v2 Join/Prune on FastEthernet1/0 > from 192.168.45.5, to us > *Mar 1 02:31:42.935: PIM(0): Prune-list: (3.3.3.3/32, 224.1.1.1) > *Mar 1 02:31:42.939: PIM(0): Prune FastEthernet1/0/224.1.1.1 from ( > 3.3.3.3/32, 224.1.1.1) > *Mar 1 02:31:42.943: PIM(0): Insert (3.3.3.3,224.1.1.1) prune in nbr > 192.168.234.3's queue - deleted > *Mar 1 02:31:42.947: PIM(0): Building Join/Prune packet for nbr > 192.168.234.3 > *Mar 1 02:31:42.951: PIM(0): Adding v2 (3.3.3.3/32, 224.1.1.1), S-bit > Prune > *Mar 1 02:31:42.951: PIM(0): Send v2 join/prune to 192.168.234.3 > (Serial0/0) > Pooky# > Pooky# > *Mar 1 02:31:44.315: IP(0): s=192.168.234.3 (Serial0/0) d=224.1.1.1 > id=229, ttl=254, prot=1, len=104(100), mroute olist null > *Mar 1 02:31:44.323: IP(0): s=192.168.234.3 (Serial0/0) d=224.1.1.1 > id=229, ttl=254, prot=1, len=104(100), mroute olist null > Pooky# > > If I add back in the static mroute everything works again. > > > *Mar 1 02:47:34.855: PIM(0): Received v2 Join/Prune on Serial0/0 from > 192.168.234.2, to us > *Mar 1 02:47:34.859: PIM(0): Join-list: (3.3.3.3/32, 224.1.1.1), S-bit > set > *Mar 1 02:47:34.863: PIM(0): Add Serial0/0/192.168.234.2 to (3.3.3.3, > 224.1.1.1), Forward state, by PIM SG Join > *Mar 1 02:47:34.867: PIM(0): Insert (3.3.3.3,224.1.1.1) join in nbr > 192.168.234.3's queue > *Mar 1 02:47:34.871: PIM(0): Received v2 Join/Prune on Serial0/0 from > 192.168.234.2, to us > *Mar 1 02:47:34.875: PIM(0): Join-list: (3.3.3.3/32, 224.1.1.1), S-bit > set > > > *Mar 1 02:47:34.879: PIM(0): Update Serial0/0/192.168.234.2 to (3.3.3.3, > 224.1.1.1), Forward state, by PIM SG Join > Pooky# > *Mar 1 02:47:34.883: PIM(0): Building Join/Prune packet for nbr > 192.168.234.3 > *Mar 1 02:47:34.887: PIM(0): Adding v2 (3.3.3.3/32, 224.1.1.1), S-bit > Join > *Mar 1 02:47:34.891: PIM(0): Send v2 join/prune to 192.168.234.3 > (Serial0/0) > *Mar 1 02:47:35.751: IP(0): s=3.3.3.3 (Serial0/0) d=224.1.1.1 (Serial0/0) > id=244, ttl=253, prot=1, len=100(100), mforward > *Mar 1 02:47:35.759: IP(0): s=3.3.3.3 (Serial0/0) d=224.1.1.1 (Serial0/0) > id=244, ttl=253, prot=1, len=100(100), mforward > > Now in this situation everything is going through the hub, so the prunes > and joins are going in and out of the same sub interface, so to override > the prune I guess we need to force a join via the Hub, using the static > mroute. > > Alternative methods are point-to-mupoint or point to point, or a GRE > tunnel from spoke to spoke. I dont think Unicast communication between > spokes is enough. Would like to hear thoughts more on this. > > B > > > > > On Thu, Jan 3, 2013 at 10:38 AM, Saleh Batouq <[email protected]>wrote: > >> ---------- 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 >> > > -- 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
