I would appreciate insight and experience for the following situation.
I have a client that would like to announce a /18 & /19 over BGP in
Sacramento and LA, us being the second location in LA. Our location
will be a failover location incase Sacramento goes down.
They want failover for extreme cases when they're completly down in
Sacramento. They have strict requirements so that traffic to their blocks
should exclusively go to Sacramento or LA.
This seems difficult to automate and they are aware of this. They will
contact their provider to stop announcing the blocks and subsequently
contact us to announce their routes.
I am wondering is there a better way to approaching the situation
without resorting to announcing the routes when the client calls us
and tells us to failover. This seems to be the inherent problem aswell
because the customer wants this to be a manual process.
If you don't have control over the other site my best advice would be to use the BGP communities your transit providers give you. If you setup your clients routes to a lower Local Perf on your transit provider's network, your transit provider will always pick the primary provider's routes first. The moment the primary site stops announcing the route your transit provider will immediately start announcing yours. This works better then AS prepend because almost all providers override the AS prepend with a higher local pref for free peers, local customers, etc. The only other issue would be, how to stop the primary network from advertising your client's routes automatically. This could be done by the client setting up BGP with the primary provider and then pulling the routes. If your client does not run BGP then it all depends on how the ips are setup on the primary side. My best advice is if they don't have BGP to tell them to set it up. Tell them to setup a private AS BGP session with their provider and just get a default route from them. This way they use just about any piece of networking equipment and they don't need their own external AS. Then they can either shutdown the port, BGP session, or pull the route (all they can do themselves) to have their provider pull the route from the internet.
Otherwise, the customer could get around this whole issue by setting up some type global server load balancing. There are quite a few companies that have solutions for this. But it would take a lot more technical networking knowledge on the client side.
Why not just AS prepend your secondary site if the services to the
Internet are the same at both sites and tied to the same IP addresses?
because that simply does not work (reliably). It would depend on
AS-paths of the same length from every possible source.
Simple, reliable and quite stylish is another way:
Choose primary and secondary location by announcing more specifics at
Sacramento, e.g. all networks as /20 subnets. As "longest match always
wins", any source seeing both routes for an IP address will choose
Sacramento.
The only way traffic could reach LA would be a missing route to
Sacramento. In any other case, Sacramento is chosen. Thus, if Sacramento
(manually or automatically) stops announcing the /20s, LA's /18 and /19
will be chosen.
CAVE: This is no failover solution for single services, just for whole
subnets depending on the announcement at Sacramento.
CAVE2: My suggestion creates inconsistent announcements for the source
AS. That may or may not be a problem.
Announce from Sacramento normally.
Announce from LA with an AS prepend 3 or 4 deep.
GRE tunnel from LA back to Sacramento diverting the few packets which
insist on going to LA back to Sacramento during normal operation.
Or conditionally announce in LA based on a monitoring process which
watches Sacramento and deal with the extra complexity and longer
restoration time.
Thank to everyone that took the time to respond with their ideas.
To those who asked, the client didn't provide details on the application.
However they were insistent that it wasn't possible to have it run in an
active/active configuration, so load balancing at either the application
or BGP level wasn't an option. Also they didn't want to subnet the space
for the failover location, so it's all or nothing style routing.
Of the several solutions presented the two that seem to be simple to
implement and guarantee traffic were conditional route advertisements
or using more specific routes.
I was unable to find information for conditional route advertisements in
JunOS, so it seems like advertising specific routes at the primary option
will be the easiest option. If anyone has information on conditional
routing for JunOS, I would be much appreciative if you could send this
to me.
Of the several solutions presented the two that seem to be simple to
implement and guarantee traffic were conditional route advertisements
or using more specific routes.
One thing you need to consider is what happens if your AS is split.
In this case, traffic will probably flow to both locations.
If an IBGP link is possible then you could automate this with the proper attributes. > Date: Wed, 31 Dec 2008 00:08:32 +0000> From: naveen@calpop.com> To: nanog@nanog.org> Subject: Failover solution using BGP> > Hi,> > I would appreciate insight and experience for the following situation.> > I have a client that would like to announce a /18 & /19 over BGP in> Sacramento and LA, us being the second location in LA. Our location> will be a failover location incase Sacramento goes down.> > They want failover for extreme cases when they're completly down in> Sacramento. They have strict requirements so that traffic to their blocks> should exclusively go to Sacramento or LA.> > This seems difficult to automate and they are aware of this. They will> contact their provider to stop announcing the blocks and subsequently> contact us to announce their routes.> > I am wondering is there a better way to approaching the situation> without resorting to announcing the routes when the client calls us> and tells us to failover. This seems to be the inherent problem aswell> because the customer wants this to be a manual process.> > -- > Naveen Nathan> > To understand the human mind, understand self-deception. - Anon>
Have they considered doing GSLB via DNS rather than playing routing
games? Seems as if it might answer better, be less complex, et. al.
I suspect they want to solve the split brain problem, which would
explain the strong, non-negotiable requirement of traffic flow to only
one site. DNS tweaks won't help with that (and to be honest, BGP
doesn't address it, either).
After all, there ought to be an internal line of communication as well as the external one, and the availability probes can be set up with logic such that if one side has bidirectional comms and the other doesn't, the desired behavior (whatever that may be, dependent upon which side has full comms) can be enforced.
Couple that with a stateless front-end - which could also afford active/active in that tier, even if the back-end is monolithic - and it's more nearly a complete solution, with more options, granularity, and safeguards available, than one based upon routing alone.
Example configs for Cisco are provided. I'm not familiar with JunOS,
but conditional route advertisement seems like a reasonably simple
request. Note that it would probably be the customer's routers that
need to support the conditional route advertisement.