On Fri, May 06, 2005 at 10:36:38PM +0100, Stuart Henderson wrote: > --On 06 May 2005 14:35 -0600, Abraham Al-Saleh wrote: > > >uptime, and our SLA only guarantees us 99.999%. So, I'm currently > > You sometimes find that SLA means something like "we'll charge you more > so that when things break, we can pay some of it back"... > > >talking with several companies to have another T1 brought in, and I'm > >planning on using OpenBGPD to provide fault tolerance. The only > >problem? I've never done anything like this before. I'm already > > While BGP can be used to improve reliability, it also gives you > interesting and varied ways to break your network. What's more, it's > quite possible to break your connectivity for extended periods of time > (through flap dampening), and there's nothing that can be done to fix > it, you just have to sit it out. So it must be done with thought and > care. >
Everything you plug into your network gives you interesting and varied ways to break your network. Btw. route flap dampening is considered evil, it was invented to protect the lousy underpowered routers created by Cisco. On a redundant setup route flap dampening should never kick in as the announced network never disappears it just switches between two different pathes. For a good redundant setup you need more than one router. Every uplink goes to one independent OpenBGPD box. From there you should use an IBGP mesh and carp(4) to connect the servers redundant to your backbone. Last note: even bgp normaly needs some time to reroute traffic so getting a real 100% connectivity from all over the world is impossible. e.g. the default holdtime is 90sec and it may take so long until your connection goes down. > >good resources on bgp in particular (books, websites, > > See <http://www.bgp4.as/books> - maybe look at Stewart "BGP4", van > Beijnum "BGP", Halabi "Internet routing architectures". Typically, > config examples are given for IOS, but many concepts are portable. van > Beijnum is probably the easier read, Stewart has good information about > the protocol (probably will help you to understand the RFC better), > Halabi is published by Cisco Press so understandably IOS-centric, quite > a lot of good material. > > A test network is pretty much essential to help you get to grips with > things... > Absolutly, without a real test lab where you can play through different scenarios, you may end up with a worse solution. I remember people connecting fully redundant servers to the same braker or getting two independent uplinks but using the same inhouse cable duct. In both cases there was a longer downtime because of this bad design. -- :wq Claudio
