[110247] in North American Network Operators' Group
RE: Failover solution using BGP
daemon@ATHENA.MIT.EDU (Braun, Mike)
Tue Dec 30 19:20:02 2008
Date: Tue, 30 Dec 2008 16:19:33 -0800
In-Reply-To: <267D7CFC-E71D-40FD-8A27-4526CD8FF254@gmail.com>
From: "Braun, Mike" <MBraun@firstam.com>
To: <nanog@nanog.org>
Errors-To: nanog-bounces@nanog.org
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]=20
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 =20
balance with stateful failover?
If it's not the same in both locations, what are they doing for =20
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 =20
> 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.
>
> --=20
> 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, P=
ROPRIETARY OR PRIVILEGED INFORMATION. IF YOU ARE NOT THE ADDRESSEE INDICAT=
ED IN THIS MESSAGE (OR RESPONSIBLE FOR DELIVERY OF THIS MESSAGE TO SUCH PER=
SON) YOU MAY NOT REVIEW, USE, DISCLOSE OR DISTRIBUTE THIS MESSAGE OR ANY FI=
LES TRANSMITTED HEREWITH. IF YOU RECEIVE THIS MESSAGE IN ERROR, PLEASE CON=
TACT THE SENDER BY REPLY E-MAIL AND DELETE THIS MESSAGE AND ALL COPIES OF I=
T FROM YOUR SYSTEM.
