[119132] in North American Network Operators' Group
RE: Failover how much complexity will it add?
daemon@ATHENA.MIT.EDU (John.Herbert@ins.com)
Sun Nov 8 13:09:56 2009
From: <John.Herbert@ins.com>
To: <sethm@rollernet.us>, <nanog@nanog.org>
Date: Sun, 8 Nov 2009 12:09:11 -0600
In-Reply-To: <4AF6FEA9.1020204@rollernet.us>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
Seth Mattinen [sethm@rollernet.us] said:
>Forget all of that and just multihome to two separate providers with BGP
--Assuming that you're advertising PI space or can work around that appropr=
iately with your providers, I agree, that's the ideal situation.
>Having multiple circuits to one provider *will not* back anything up if th=
at provider
>has an outage as they are %99.999 likely to be part of the same larger cir=
cuit=20
--True - if you don't specify otherwise when you're ordering, then why woul=
d they make the effort? Comments made in some of the other responses in thi=
s thread are also valid even with a single service provider - diverse entry=
points into your facility, diverse upstream circuit routing, and homing to=
different POPs - which may mean backhauling your secondary circuit away fr=
om your local POP and taking a hit for the higher latency on that second li=
nk. The moral of this is that whether you're using one provider or more tha=
n one, state your diversity requirements clearly up front, and then stay in=
volved and make sure that what's presented to you is _actually_ diverse (ol=
dsflash: even the best intentioned people sometimes make mistakes, especial=
ly when there's a handoff to a different last mile provider who may not hav=
e been clear on the requirement ). Of course, all of this is potentially wa=
sted effort if the data center you're providing connectivity for does not a=
lso maintain the same kind of diversity itself in terms of power, connectiv=
ity, architecture, etc.
>and certainly share the same infrastructure at the provider.
--If you enter a single provider's network at diverse points, then that loc=
al infrastructure isn't the same at least. But by the same measure, if that=
provider has a major BGP issue for example, then yeah - they're both screw=
ed... in which case we loop back to the dual provider scenario you mentione=
d in the first place :)
Ultimately choosing the appropriate solution will boil down to the what lev=
el of service unavailability one can tolerate in the first place, and put a=
business value on that impact. From that one can derive technical options,=
then go cap in hand with a business case to the poor soul paying the bill =
;-)
j.=
