In this case you will receive the routes with the next-hop of the hub CE. it should be posible to use a route-map based on the next-hop and set the local-prefence in each spoke based on the next-hop.
But, I would go the way of the community. It exists for this kind of situations, is more stable (if you change the IP of the hub, you would need to reconfigure all spokes) and more versatile. Regards, Fernando El 01/08/2013, a las 07:14, vasu varma <ypk...@gmail.com> escribió: > Hi Fernando, > > I will share you the diagram which depicts the physical topology by today EOD. > > Till that time, please find the response that may answer your queries and > gives the overview of the network. > > - Is there a direct bgp neighborhood between hub and spoke? do you use route > reflectors? > No direct BGP neighbourhood, its like CE --- PE1 ----MPBGP with > RR--------PE2-----HUB CE > > - The physical topology is a dual star with each hub conected to the spoke > through a different interface? > Its an MPLS cloud where each CE have one peering with the Provider > network > > Hope it answers your queries, please revert. > > Regards > Yaswanth > > > > On Wed, Jul 31, 2013 at 5:31 PM, Fernando Garcia Fernandez <lis...@cutre.net> > wrote: > Without knowing your physical and logical topology it’s dificult to recommend > a solution. > - Is there a direct bgp neighborhood between hub and spoke? do you use route > reflectors? > - The physical topology is a dual star with each hub conected to the spoke > through a different interface? > > If each hub is connected in each spoke through a different interface, you > could set manually in each spoke a local preference to the route learned > through each interface. > That would be a route-map “in” to each neighbor (a different route-map) > without match an “set local-preference”… > > Regards, Fernando > > El 31/07/2013, a las 13:14, vasu varma <ypk...@gmail.com> escribió: > > > Hi Fernando, > > > > Thanks for your response. > > > > I actually thought of doing this, but this is not our standard practice. Is > > there any other method of achieving this? > > > > Thanks > > Yaswanth > > > > > > On Fri, Jul 26, 2013 at 2:12 PM, Fernando Garcia Fernandez > > <lis...@cutre.net> wrote: > > Hi Yaswanth > > > > I haven’t made it in real life, but doesn’t seem difficult. > > > > What I would do is publish the default route with a different community in > > each hub (i.e. 65000:1 in one hub and 65000:2). In each spoke, depending of > > what you want use the community to set a local preference. > > > > i.e. > > > > in the hub: > > > > router bgp 65000 > > network 0.0.0.0 mask 0.0.0.0 > > neighbor 10.0.0.2 remote-as 65000 > > neighbor 10.0.0.2 send—community > > neighbor 10.0.0.2 route-map NY out > > > > route-map NY permit 10 > > set community 65000:1 > > > > > > in the spoke: > > > > router bgp 65000 > > neighbor 10.0.0.1 remote-as 65000 > > neighbor 10.0.0.1 route-map hub in > > > > route-map hub permit 10 > > match community 65000:1 > > set local-preference 130 > > route-map hub permit 20 > > match community 65000:2 > > set local-preference 90 > > > > Regards, Fernando > > > > El 26/07/2013, a las 07:41, vasu varma <ypk...@gmail.com> escribió: > > > >> Hi Lumbis, > >> > >> Thanks for your response. > >> > >> Its not all about latency, latency may vary depending on the backbone > >> utilization irrespective of closest location. > >> > >> I want in such a way that east locations should prefer the default route > >> from East HUB with West HUB acting as secondary and west locations should > >> prefer the default route from WEST HUB with EAST HUB acting as secondary. > >> > >> One location may be equally destined in terms of latency or distance but we > >> should be able to configure as we desired. > >> > >> Regards > >> Yaswanth > >> > >> > >> On Tue, Jul 23, 2013 at 8:32 PM, Pete Lumbis <alum...@gmail.com> wrote: > >> > >>> If by "closest" you mean "lowest latency" you probably want to look at > >>> something like PfR to do this dynamically for you. > >>> > >>> > >>> On Tue, Jul 23, 2013 at 1:48 AM, vasu varma <ypk...@gmail.com> wrote: > >>> > >>>> Hi Team, > >>>> > >>>> I have a requirement in such a way that there are two HUB's, one in > >>>> Newyork > >>>> and other in LOS Angeles. The spoke locations will access the HUB > >>>> location > >>>> whichever is closer geographically and the other acts as the backup for > >>>> that particular site. > >>>> > >>>> If both the HUB's injects default route into the cloud, how can I > >>>> configure > >>>> the iBGP attributes to select the best path based on the closest physical > >>>> location. > >>>> > >>>> Our's is a MPLS cloud with multiple customers sharing the same Infra. > >>>> > >>>> Can someone assist me with the solution approach and most importantly the > >>>> changes that I need to do in my network. > >>>> > >>>> Regards > >>>> Yaswanth > >>>> _______________________________________________ > >>>> cisco-nsp mailing list cisco-nsp@puck.nether.net > >>>> https://puck.nether.net/mailman/listinfo/cisco-nsp > >>>> archive at http://puck.nether.net/pipermail/cisco-nsp/ > >>>> > >>> > >>> > >> _______________________________________________ > >> cisco-nsp mailing list cisco-nsp@puck.nether.net > >> https://puck.nether.net/mailman/listinfo/cisco-nsp > >> archive at http://puck.nether.net/pipermail/cisco-nsp/ _______________________________________________ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
