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

Fri Aug 2 03:35:35 EDT 2013

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 <ypkcar at 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 <listas at 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 <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/