|
|
|
|
|
|
|
|
|
|
|
|
| home | help | back | first | fref | pref | prev | next | nref | lref | last | post |
From: Austin Wilson <austinw@bandcon.com> To: Naveen Nathan <naveen@calpop.com>, "nanog@nanog.org" <nanog@nanog.org> Date: Tue, 30 Dec 2008 17:42:43 -0800 In-Reply-To: <20081231000832.GB6841@armakuni.lastninja.net> Errors-To: nanog-bounces@nanog.org If you don't have control over the other site my best advice would be to us= e the BGP communities your transit providers give you. If you setup your cl= ients 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 w= ill immediately start announcing yours. This works better then AS prepend b= ecause almost all providers override the AS prepend with a higher local pre= f for free peers, local customers, etc. The only other issue would be, how = to stop the primary network from advertising your client's routes automatic= ally. This could be done by the client setting up BGP with the primary prov= ider and then pulling the routes. If your client does not run BGP then it a= ll 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 priv= ate AS BGP session with their provider and just get a default route from th= em. 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 p= rovider 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 som= e type global server load balancing. There are quite a few companies that h= ave solutions for this. But it would take a lot more technical networking k= nowledge 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
|
|
|
|
|
|
|
|
|
|
|
|
| home | help | back | first | fref | pref | prev | next | nref | lref | last | post |