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
Conditional advertisements might be what you're looking for: http://www.cisco.com/en/US/tech/tk365/technologies_configuration_example0918... Regards, Chris Ely On Wed, 31 Dec 2008, Naveen Nathan wrote:
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
On Tue, Dec 30, 2008 at 6:13 PM, Chris Ely <cely@internap.com> wrote:
Conditional advertisements might be what you're looking for:
http://www.cisco.com/en/US/tech/tk365/technologies_configuration_example0918...
I did something just like this recently. Apologies if this is redundant, but it might be useful to some. showipbgp.com's BGP Topology 7 (at the bottom of the page) seems to match your request. http://www.showipbgp.com/ 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. hth, -Doug
If the infrastructure is the same in both locations, why not load balance with stateful failover? If it's not the same in both locations, what are they doing for replication and the such in the event a site does go down? - Chandler On Dec 30, 2008, at 7:08 PM, Naveen Nathan wrote:
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
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? Mike -----Original Message----- From: Chandler Bassett [mailto:chandler.bassett@gmail.com] Sent: Tuesday, December 30, 2008 4:15 PM To: Naveen Nathan Cc: nanog@nanog.org Subject: Re: Failover solution using BGP If the infrastructure is the same in both locations, why not load balance with stateful failover? If it's not the same in both locations, what are they doing for replication and the such in the event a site does go down? - Chandler On Dec 30, 2008, at 7:08 PM, Naveen Nathan wrote:
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
-- THIS E-MAIL MESSAGE AND ANY FILES TRANSMITTED HEREWITH, ARE INTENDED SOLELY FOR THE USE OF THE INDIVIDUAL(S) ADDRESSED AND MAY CONTAIN CONFIDENTIAL, PROPRIETARY OR PRIVILEGED INFORMATION. IF YOU ARE NOT THE ADDRESSEE INDICATED IN THIS MESSAGE (OR RESPONSIBLE FOR DELIVERY OF THIS MESSAGE TO SUCH PERSON) YOU MAY NOT REVIEW, USE, DISCLOSE OR DISTRIBUTE THIS MESSAGE OR ANY FILES TRANSMITTED HEREWITH. IF YOU RECEIVE THIS MESSAGE IN ERROR, PLEASE CONTACT THE SENDER BY REPLY E-MAIL AND DELETE THIS MESSAGE AND ALL COPIES OF IT FROM YOUR SYSTEM.
Hi, Am 31.12.2008 01:19 Uhr, Braun, Mike schrieb:
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. Kind regards, Malte -- Malte v. dem Hagen Abteilung Technik - Network Operations Centre ----------------------------------------------------------------- Host Europe GmbH - http://www.hosteurope.de/ Welserstrasse 14 - D-51149 Köln - Germany Telefon 0800-4 67 83 87 - Telefax 01805-66 32 33 HRB 28495 Amtsgericht Koeln - UST ID DE187370678 GF: Uwe Braun - Alex Collins - Mark Joseph - Patrick Pulvermüller -----------------------------------------------------------------
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. Use this link to find common communities: http://www.onesc.net/communities/ 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. Austin -----Original Message----- From: Naveen Nathan [mailto:naveen@calpop.com] Sent: Tuesday, December 30, 2008 5:09 PM 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
On Tue, Dec 30, 2008 at 7:08 PM, Naveen Nathan <naveen@calpop.com> wrote:
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.
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. Regards, Bill Herrin -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004
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. Happy Holidays everyone. - Naveen
* Naveen Nathan:
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.
On Dec 31, 2008, at 11:59 AM, Naveen Nathan wrote:
Also they didn't want to subnet the space for the failover location, so it's all or nothing style routing.
Have they considered doing GSLB via DNS rather than playing routing games? Seems as if it might answer better, be less complex, et. al. ----------------------------------------------------------------------- Roland Dobbins <rdobbins@cisco.com> // +852.9133.2844 mobile All behavior is economic in motivation and/or consequence.
* Roland Dobbins:
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).
On Dec 31, 2008, at 11:36 PM, Florian Weimer wrote:
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. ----------------------------------------------------------------------- Roland Dobbins <rdobbins@cisco.com> // +852.9133.2844 mobile All behavior is economic in motivation and/or consequence.
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> _________________________________________________________________ Send e-mail faster without improving your typing skills. http://windowslive.com/online/hotmail?ocid=TXT_TAGLM_WL_hotmail_acq_speed_12...
participants (11)
-
Austin Wilson -
Braun, Mike -
Bryant Valencia -
Chandler Bassett -
Chris Ely -
Doug Schaapveld -
Florian Weimer -
Malte von dem Hagen -
Naveen Nathan -
Roland Dobbins -
William Herrin