YEs they have maps to each other, which includes the broadcast. Pooky = Hub Arlene = Spoke - from which I do my pings Odin - Spoke, where my host is.
On odin - interface Serial0/0 ip address 192.168.234.2 255.255.255.0 ip pim sparse-mode encapsulation frame-relay no ip mroute-cache serial restart-delay 0 clock rate 2000000 frame-relay map ip 192.168.234.3 204 broadcast end Static mroute on odin - ip mroute 3.3.3.3 255.255.255.255 192.168.234.4 On Arlene - interface Serial0/0 ip address 192.168.234.3 255.255.255.0 ip pim sparse-mode encapsulation frame-relay serial restart-delay 0 clock rate 2000000 frame-relay map ip 192.168.234.2 304 broadcast end Agreed that without the inarp I would need the frame-relay map on the hub as well. On Thu, Jan 3, 2013 at 12:22 PM, Saleh Batouq <[email protected]> wrote: > 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
