This is the purpose of learning from your mistakes in the past.  Create a maintenance plan so it doesn't happen again!<br><br>Fool me once...<br><br clear="all">Josh Luthman<br>Office: 937-552-2340<br>Direct: 937-552-2343<br>

1100 Wayne St<br>Suite 1337<br>Troy, OH 45373<br><br>"When you have eliminated the impossible, that which remains, however improbable, must be the truth."<br>--- Sir Arthur Conan Doyle<br>
<br><br><div class="gmail_quote">On Thu, Oct 22, 2009 at 10:43 PM, George Herbert <span dir="ltr"><<a href="mailto:george.herbert@gmail.com">george.herbert@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

<div class="im">On Thu, Oct 22, 2009 at 7:03 PM, Jay R. Ashworth <<a href="mailto:jra@baylink.com">jra@baylink.com</a>> wrote:<br>
> ----- "Jeremy Chadwick" <<a href="mailto:outages@jdc.parodius.com">outages@jdc.parodius.com</a>> wrote:<br>
>> On Tue, Oct 20, 2009 at 09:28:21AM -0700, Scott Howard wrote:<br>
>> > Looks like it's all back up as of about 30 mins ago.<br>
>> ><br>
>> > Apparently either a core switch or router failed, which took down much of<br>
>> > their network in Atlanta, as well as Memphis and Nashville.<br>
>><br>
>> Level 3 has a single router or switch handling packets at a major<br>
>> POP?<br>
>> I doubt this, but the outage is confirmation something bad happened.<br>
>> That said: where's the redundancy, and why didn't it kick in?<br>
><br>
> Oh; you're *always* asking that.<br>
><br>
> :-)<br>
><br>
> The Internet Backbone<tm> has been a commercial, rather than an engineering,<br>
> construct for over 15 years now.<br>
<br>
</div>The RFO that went out somewhat after he asked that was more useful...<br>
N=2 redundancy was in place.  However, when primary had hardware<br>
failure, secondary had (unknown / unstated) software, config, or<br>
hardware failure that hadn't been detected or checked, and it didn't<br>
work either.<br>
<br>
It's hard to test clusters of things well when they have near-100%<br>
uptime requirements.  The dependability of the untested failover unit<br>
is low, as you're not testing it well.<br>
<br>
Sometimes you can test failovers in stream.  But sometimes those<br>
supposedly harmless failover tests fail for baroque reasons, taking<br>
down a service when the primary was in fact just fine.<br>
<br>
This isn't (just) an economics problem.  Reliability of complex<br>
problems is an mathematically exponentially hard problem to crack from<br>
the engineering and theoretical levels.<br>
<br>
Some people don't try - and get what they deserve - and some people<br>
give it a good or best commercial reasonable effort, and still fail.<br>
Doing better than that is really hard.<br>
<font color="#888888"><br>
<br>
--<br>
-george william herbert<br>
<a href="mailto:george.herbert@gmail.com">george.herbert@gmail.com</a><br>
</font><div><div></div><div class="h5">_______________________________________________<br>
outages mailing list<br>
<a href="mailto:outages@outages.org">outages@outages.org</a><br>
<a href="https://puck.nether.net/mailman/listinfo/outages" target="_blank">https://puck.nether.net/mailman/listinfo/outages</a><br>
</div></div></blockquote></div><br>