There's a Reddit user claiming he works at CL who says the reason were some faulty Infinera DTN-X instances.<div><br></div><div><a href="https://www.reddit.com/r/centurylink/comments/aa2qa4/comment/ecovgab">https://www.reddit.com/r/centurylink/comments/aa2qa4/comment/ecovgab</a><br><br>(dunno though why the user posted that to Reddit and not here)<br><br><div class="gmail_quote"><div dir="ltr">30 Dec. 2018 г., 20:19 Saku Ytti <<a href="mailto:saku@ytti.fi">saku@ytti.fi</a>>:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hey John,<br>
<br>
Your criticism is warranted, but would also be addressed by<br>
explanation DCN/OOB being the source of the problem.<br>
<br>
At any rate, I am looking forward to stop speculating and start<br>
reading post-mortem written by someone who knows how networks work.<br>
<br>
On Sun, 30 Dec 2018 at 18:28, John Von Essen <<a href="mailto:john@essenz.com" target="_blank">john@essenz.com</a>> wrote:<br>
><br>
> One thing that is troubling when reading that URL is that it appears several steps of restoration required teams to go onsite for local login, etc.,. Granted, to troubleshoot hardware you need to be physically present to pop a line card in and out, but CTL/LVL3 should have full out-of-band console and power control to all core devices, we shouldn't be waiting for someone to drive to a location to get console or do power cycling. And I would imagine the first step to alot of the troubleshooting was power cycling and local console logs.<br>
><br>
><br>
> -John<br>
><br>
><br>
><br>
> On 12/30/18 10:42 AM, Mike Hammett wrote:<br>
><br>
> It's technical enough so that laypeople immediately lose interest, yet completely useless to anyone that works with this stuff.<br>
><br>
><br>
><br>
> -----<br>
> Mike Hammett<br>
> Intelligent Computing Solutions<br>
> <a href="http://www.ics-il.com" rel="noreferrer" target="_blank">http://www.ics-il.com</a><br>
><br>
> Midwest-IX<br>
> <a href="http://www.midwest-ix.com" rel="noreferrer" target="_blank">http://www.midwest-ix.com</a><br>
><br>
> ________________________________<br>
> From: "Saku Ytti" <<a href="mailto:saku@ytti.fi" target="_blank">saku@ytti.fi</a>><br>
> To: "nanog list" <<a href="mailto:nanog@nanog.org" target="_blank">nanog@nanog.org</a>><br>
> Sent: Sunday, December 30, 2018 7:42:49 AM<br>
> Subject: CenturyLink RCA?<br>
><br>
> Apologies for the URL, I do not know official source and I do not<br>
> share the URLs sentiment.<br>
> <a href="https://fuckingcenturylink.com/" rel="noreferrer" target="_blank">https://fuckingcenturylink.com/</a><br>
><br>
> Can someone translate this to IP engineer? What did actually happen?<br>
> From my own history, I rarely recognise the problem I fixed from<br>
> reading the public RCA. I hope CenturyLink will do better.<br>
><br>
> Best guess so far that I've heard is<br>
><br>
> a) CenturyLink runs global L2 DCN/OOB<br>
> b) there was HW fault which caused L2 loop (perhaps HW dropped BPDU,<br>
> I've had this failure mode)<br>
> c) DCN had direct access to control-plane, and L2 congested<br>
> control-plane resources causing it to deprovision waves<br>
><br>
> Now of course this is entirely speculation, but intended to show what<br>
> type of explanation is acceptable and can be used to fix things.<br>
> Hopefully CenturyLink does come out with IP-engineering readable<br>
> explanation, so that we may use it as leverage to support work in our<br>
> own domains to remove such risks.<br>
><br>
> a) do not run L2 DCN/OOB<br>
> b) do not connect MGMT ETH (it is unprotected access to control-plane,<br>
> it  cannot be protected by CoPP/lo0 filter/LPTS ec)<br>
> c) do add in your RFP scoring item for proper OOB port (Like Cisco CMP)<br>
> d) do fail optical network up<br>
><br>
> --<br>
>   ++ytti<br>
><br>
<br>
<br>
-- <br>
  ++ytti<br>
</blockquote></div></div>