[c-nsp] Two HUBS-Location Specific Spokes-Redundant to each other

[Fernando Garcia Fernandez]

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 <ypkcar at 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 <listas at 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 <ypkcar at 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 <alumbis at 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 <ypkcar at 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 at 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 at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-nsp
>> archive at http://puck.nether.net/pipermail/cisco-nsp/