Cases7 cases

4 to 7 of 7

1. IL-0539 KT's internet service failed nationwide for about 89 minutes as wrong routes spread from one router in Busan

   KT2021

   Symptoms

   On 25 October 2021 from about 11:16, traffic to the DNS servers in KT's network rose sharply, and then KT's internet service failed across the whole country. KT recognised the internet outage at 11:20, and the outage lasted about 89 minutes until KT finished recovery at about 12:45.

   Network unreachableService outage

   Trigger

   During the replacement of an enterprise network router at KT's Busan office, worked on remotely from the Busan communication center, a worker entered a routing configuration script that lacked the 'exit' command that should have ended the IS-IS part of the configuration.

   Root cause

   Configuration change

   Component

   Interior routing (IGP)BGP routing

   Contributing factor

   Missed in reviewNo configuration testsChange during peak hoursExcessive blast radius

   Detection

   KT recognised the internet outage at 11:20, four minutes after DNS traffic began to surge at 11:16. The Ministry of Science and ICT saw the traffic increase in its own monitoring, and KT reported the outage to the ministry at 11:40.

   Remediation

   • Isolated the router where the faulty routing configuration was entered
   • Logged in to each regional router, deleted the faulty processes and restarted them

   Action items

   • Check the network management of major carriers, including their work procedures and the systems that stop technical errors from spreading
   • Consider having major carriers introduce simulation systems that diagnose errors from network work in advance
   • Have the NMS center and network operations center of each major carrier check technically that approved work plans are followed
   • Strengthen safeguards in routing work, such as limiting the number of route entries updated at once below a set level
   • Strengthen the monitoring of carriers' outages and develop technology, including AI-based preventive diagnosis, for network stability and resilience
   • Prepare structural measures for a stable network architecture and network survivability
   • Let carriers notify users of outages through SNS, text messages and other means, not only the website

   Lessons

   The investigation named management problems and technical problems. On the management side, work approved for the night was done during the day, partner company workers did the routing work without a work manager, and the work was done with the network still connected. On the technical side, the two pre-verification steps were people reading the script and missed the missing 'exit', there was no virtual testbed for trying the work on a disconnected network, and nothing stopped an error in one region from spreading to the whole country.

   View case
2. IL-0228 IPv4 routing across OVHcloud's global network broke after a router change put the full internet routing table into OSPF

   OVHcloud2021

   Symptoms

   At 09:20 CET on 13 October 2021, during a planned change on a router, IPv4 traffic across OVHcloud's whole network stopped being routed, while all IPv6 traffic stayed reachable. The team detected a problem with the router's performance at 09:21 CET and escalated at once.

   Network unreachableService outage

   Trigger

   A planned change to a router in the Vint Hill datacentre in the United States, meant to strengthen anti-DDoS protection, included a command to regulate the redistribution of BGP into OSPF, and the router did not interpret that command correctly.

   Root cause

   Configuration change

   Component

   Interior routing (IGP)BGP routingBackbone network (WAN)

   Contributing factor

   Ineffective rollbackExcessive blast radius

   Detection

   At 09:21 CET the team detected a problem with the router's performance and started the escalation process.

   Remediation

   • Disconnected the optical equipment to isolate the router's connectivity
   • Powered off the faulty router
   • Stabilised connectivity to restore the remaining services

   Action items

   • Re-evaluate the change procedure for this type of equipment, which applies the command line natively
   • Strengthen the related change process

   View case
3. IL-0221 A backbone maintenance command disconnected all Facebook data centers, and its DNS servers withdrew their BGP routes

   Meta2021

   Symptoms

   On 4 October 2021 Facebook's platforms went down worldwide: every connection in Facebook's global backbone network was lost, and the data centers were cut off from each other and from the internet. The rest of the internet could no longer find Facebook's servers, because Facebook's authoritative DNS servers had become unreachable.

   Service outageDNS resolution failuresNetwork unreachable

   Trigger

   During routine maintenance of the backbone, a command was issued to assess the availability of global backbone capacity, and it unintentionally took down all connections in the backbone network.

   Root cause

   Operator error

   Component

   Backbone network (WAN)BGP routingAuthoritative DNS servers and records

   Contributing factor

   Automation amplificationCircular dependencyLimited debug access

   Remediation

   • Sent engineers onsite to the data centers to debug the issue and restart systems
   • Brought the backbone network back online across the data center regions
   • Brought services back gradually, managing the rising load to avoid crashes from a traffic surge

   Action items

   • Find ways to simulate the global backbone being taken offline in storm drills
   • Strengthen testing, drills and overall resilience

   Lessons

   The hardening that protects Facebook's data centers against unauthorized access slowed recovery from an outage caused by Facebook's own error, and the author judges that tradeoff worth keeping. Storm drills prepared the teams to bring load back safely, although no drill had yet simulated the global backbone going offline.

   View case
4. IL-0258 FastMail was unreachable for almost two hours when the GRE tunnels carrying its traffic from Level 3 went down

   Fastmail2016

   Symptoms

   At 4.50am Melbourne time on Sunday 7 February (evening of 6 February UTC), FastMail became unavailable and stayed unreachable for almost two hours. Traffic to FastMail's public IP range never made it into FastMail's own network.

   Service outageNetwork unreachable

   Trigger

   The GRE tunnels between Level 3 and NYI, which carried FastMail's filtered traffic into its network, went down.

   Root cause

   Dependency failure

   Component

   DDoS protection serviceBGP routing

   Contributing factor

   Limited debug access

   Detection

   NYI, the datacentre provider, noticed the failure quickly.

   Remediation

   • NYI escalated with Level 3's support until FastMail's public IP ranges were pointed back to NYI

   Action items

   • Go back to DDoS protection from Black Lotus under NYI's explicit control
   • Build nginx frontends in the Los Angeles datacentre that reach NYI over the secondary network, and point DNS to them if NYI's primary network fails
   • Add hardware in Amsterdam and change the delivery system so it depends less on NYI
   • Work with NYI to understand its processes for detecting and responding to network faults

   Lessons

   Much of FastMail's and NYI's reliability had come from NYI controlling its own infrastructure. With protection always on at Level 3, NYI could not restore the routes itself, and FastMail calls the resulting delay in restoring service unacceptable.

   View case

By root cause5