Ok I cracked this last night, and I'm really excited that it makes sense .... I think :)
Highlights were that with the hub and spoke model the MA has to be at at the hub site, because the hub won't forward MA annoucements out of it's own interface. This is due to the same IP addressing on the interface. So my whole split horizon thinking is getting confused because I'm thinking about routing updates. The need the ip pim nbma-mode on the hub is to fool the L2/L3 aspect of NBMA networks. When applied the mroutes have an ip associated with the interface, simulating the point 2 point style links. To get around the movement of MA to the spoke my options are converting to 1. point to point links from spoke to hub or 2. deployment of GRE tunnel (which I already did). This also got me questioning the ip pim autorp listener command, as you can see in my original thread. My original thought process was that this needs to be deployed on every router in the domain for it to forward these out, via dense mode. What struck me was that my logic is slightly flawed, and what I proved last night was that I could use this command on one router, in my scenario the hub router. This router received the the MA and c-RP announcements from two different routers and 1. dense mode flooded out the details. So it dense-mode flooded the c-RP to the MA, and the MA to everyone else. Exciting stuff for me :) So end result - 1. I proved to myself an environment for nbma-mode is really when you have hub and spoke, with MA at the hub and the hub has a phsyical/multipoint connection. Remembering that physical interfaces are default to multipoint. 2. If you want to move the MA/RP to a spoke you have to change to either a point-to-point or deploy GRE tunnels between spokes. 3. the autorp listener isn't necessarily required everywhere, but really only on the first hop routers from c-RP and MA, but taking care with regards to RPF. 4. the TTL is relevant, 224.0.1.x are routable mcast addresses, 224.0.0.x are local link significant only via the TTL =1 Right track or no? B > From: [email protected] > To: [email protected] > CC: [email protected]; [email protected] > Subject: Re: [OSL | CCIE_RS] Multicasting NBMA Frame-Relay and AutoRP > Date: Thu, 20 Dec 2012 22:06:15 +0000 > > Thanks Marco I realised that after I hit send. Clever me! > > Sent from my iPhone > > On 21/12/2012, at 3:59 AM, "Marko Milivojevic" <[email protected]> wrote: > > > Michael, > > > > You may be mixing up BSR and MA here. BSR is sent to 224.0.0.13 (All > > PIM Routers; link-local) with the TTL of 1. MA sends traffic to > > 224.0.1.40 (globally routable) with the TTL set using the "scope" > > keyword during the configuration. > > > > -- > > Marko Milivojevic - CCIE #18427 (SP R&S) > > Senior CCIE Instructor - IPexpert > > > > On Thu, Dec 20, 2012 at 2:07 AM, Michael Davis - Webquor > > <[email protected]> wrote: > >> Hi there please read this article: > >> http://www.cisco.com/en/US/docs/ios/solutions_docs/ip_multicast/White_papers/frm_rlay.html#wp1029926 > >> It should answer all your questions. It is a good read. > >> I don't think placing the Mapping agent on a spoke is supported and I > >> doubt you would ever need to do it. > >> Remember too if you are using sparse mode, make sure to enable IP pim > >> autorp listener on each router, as it allows those two groups for autorp > >> to run in dense mode. If anyone else has any input or corrections please > >> contribute. > >> > >> > >> Sent from my iPhone > >> > >> On 20/12/2012, at 7:10 PM, "Baldeep Birdy" > >> <[email protected]<mailto:[email protected]>> wrote: > >> > >> Ok so what's the purposed of the TTL in - ip pim send-rp-discovery scope > >> ttl-value > >> > >> I thought by setting this you can control/or permit the flow of your RP > >> MAppings to routers who want to learn??? > >> > >> Thanks > >> B > >> > >>> From: [email protected]<mailto:[email protected]> > >>> To: [email protected]<mailto:[email protected]> > >>> CC: [email protected]<mailto:[email protected]> > >>> Subject: Re: [OSL | CCIE_RS] Multicasting NBMA Frame-Relay and AutoRP > >>> Date: Thu, 20 Dec 2012 07:05:06 +0000 > >>> > >>> Auto RP mapping agent traffic had a ttl of 1. You cannot change that. Hub > >>> must be MA. > >>> > >>> Sent from my iPhone > >>> > >>> On 20/12/2012, at 4:13 PM, "Baldeep Birdy" > >>> <[email protected]<mailto:[email protected]>> wrote: > >>> > >>>> So I've been spending a lot of time on multicasting and today was > >>>> playing with the deployment of AutoRP within a FR Cloud. I have my RP at > >>>> the hub site, with my MA deployed at a spoke. Straight away I ran into > >>>> issues with my MA announcements, on 224.0.1.40, being sent to my other > >>>> spoke routers, to the hub site no issues. Note, that this was intended > >>>> to further cement my understanding of frame-relay concepts and also > >>>> mcast. > >>>> > >>>> Now my thought process was that the 224.0.1.40 annoucements are not > >>>> getting to my spoke, they are being sent to the hub who is not > >>>> forwarding them on. I then remembered that these announcements are sent > >>>> to your PIM neighbours only, and my initial thought was that enabling > >>>> autorp listener on the hub would resolve the issue. Alas no, would like > >>>> someone to explain this. > >>>> > >>>> Second though, ok I need to get the spokes to become neighbours, I > >>>> configured frame-relay map ip statements, with the broadcast command, > >>>> between my spokes but again no result. > >>>> > >>>> Final thought, setup a GRE tunnel between them and configure PIM on the > >>>> tunnel, with the required static mroute to fix my RFP failure, result > >>>> worked. > >>>> > >>>> So going back I'm now a little confused about points 1 and 2. Clearly > >>>> I've got a gap in my theory. > >>>> > >>>> 1. AutoRP listener, causes the router to flood autorp messages within > >>>> the environment, so why not from the hub down to spokes? I configured no > >>>> ip split horizon on the interface thinking is it a split horizon issue, > >>>> but this is for routing right? so a red herring? > >>>> > >>>> 2. With the frame-relay map statements, why didn't my spokes become > >>>> neighbours? I have broadcast statements so the packets would have been > >>>> unicasted out? > >>>> > >>>> I've read that the MA SHOULD be placed at the hub, so it has full > >>>> communication. Short of using a GRE tunnel is this my only option? There > >>>> has to be an alternative, what am I missing. > >>>> > >>>> Thanks > >>>> Bal > >>>> > >>>> _______________________________________________ > >>>> For more information regarding industry leading CCIE Lab training, > >>>> please visit www.ipexpert.com<http://www.ipexpert.com> > >>>> > >>>> Are you a CCNP or CCIE and looking for a job? Check out > >>>> www.PlatinumPlacement.com<http://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 _______________________________________________ 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
