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 <[email protected]> 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 <[email protected]> > 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 [email protected] >>>> https://puck.nether.net/mailman/listinfo/cisco-nsp >>>> archive at http://puck.nether.net/pipermail/cisco-nsp/ >>>> >>> >>> >> _______________________________________________ >> cisco-nsp mailing list [email protected] >> https://puck.nether.net/mailman/listinfo/cisco-nsp >> archive at http://puck.nether.net/pipermail/cisco-nsp/ _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
