<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto">I’m “guessing” based on all the services that were impacted the outage was likely cause by a change that caused a routing change in their multi-service network which overloaded many network devices, and by isolating the source the routes or traffic the rest of the network was able to recover.<div><br></div><div>But just a guess.</div><div><br></div><div>Shane</div><div><div dir="ltr"><blockquote type="cite">On Jul 11, 2022, at 4:22 PM, Matthew Petach <mpetach@netflight.com> wrote:<br><br></blockquote></div><blockquote type="cite"><div dir="ltr"><div dir="ltr"><div dir="ltr"><br></div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Jul 11, 2022 at 9:01 AM Andrey Kostin <<a href="mailto:ankost@podolsk.ru">ankost@podolsk.ru</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">It's hard to believe that a same time maintenance affecting so many <br>
devices in the core network could be approved. Core networks are build <br>
with redundancy, so that failures can't completely destroy the whole <br>
network. </blockquote><div><br></div><div>I think you might need to re-evaluate your assumption </div><div>about how core networks are built.</div><div><br></div><div>A well-designed core network will have layers of redundancy </div><div>built in, with easy isolation of fault layers, yes.</div><div><br></div><div>I've seen (and sometimes worked on) too many networks </div><div>that didn't have enough budget for redundancy, and were </div><div>built as a string of pearls, one router to the next; if any router </div><div>in the string of pearls broke, the entire string of pearls would </div><div>come crashing down, to abuse a metaphor just a bit too much.</div><div><br></div><div>Really well-thought out redundancy takes a design team that </div><div>has enough experience and enough focused hours in the day </div><div>to think through different failure modes and lay out the design </div><div>ahead of time, before purchases get made.    Many real-world </div><div>networks share the same engineers between design, deployment, </div><div>and operation of the network--and in that model, operation and </div><div>deployment always win over design when it comes time to allocate </div><div>engineering hours.  Likeise, if you didn't have the luxury of being </div><div>able to lay out the design ahead of time, before purchasing hardware </div><div>and leasing facilities, you're likely doing the best you can with locations </div><div>that were contracted before you came into the picture, using hardware </div><div>that was decided on before you had an opportunity to suggest better </div><div>alternatives. </div><div><br></div><div>Taking it a step further, and thinking about the large Facebook outage, </div><div>even if you did well in the design phase, and chose two different vendors, </div><div>with hardware redundancy and site redundancy in your entire core </div><div>network, did you also think about redundancy and diversity for the </div><div>O&M side of the house?   Does each redundant data plane have a </div><div>diverse control plane and management plane, or would an errant </div><div>redistribution of BGP into IGP wipe out both data planes, and both </div><div>hardware vendors at the same time?  Likewise, if a bad configuration </div><div>push isolates your core network nodes from the "God box" that </div><div>controls the device configurations, do you have redundancy in </div><div>connectivity to that "God box" so that you can restore known-good </div><div>configurations to your core network sites, or are you stuck dispatching </div><div>engineers with laptops and USB sticks with configs on them to get </div><div>back to a working condition again?</div><div><br></div><div>As you follow the control of core networks back up the chain, </div><div>you ultimately realize that no network is truly redundant and </div><div>diverse.  Every network ultimately comes back to a single point </div><div>of failure, and the only distinction you can make is how far up the </div><div>ladder you climb before you discover that single point of failure.</div><div><br></div><div>Thanks!</div><div><br></div><div>Matt</div><div><br></div></div></div>
</div></blockquote></div></body></html>