Incident Library
Applied filters Root causeConfiguration changeSymptomNetwork unreachableClear allEvery case under the filters, with no sentence; newest first.
Suggested filters Search, and the values found in your words appear here.

Graph

  • Root cause
  • Component
  • Symptom
  • Contributing factor
  • Case

Cases8 cases

5 to 8 of 8

  1. IL-0266 Eqiad routers looped traffic between each other after a BGP MED change and could not reach other sites' public IPs
    Wikimedia Foundation2021
    Symptoms

    On 23 November 2021 at 09:39, two minutes after a change on the eqiad core routers, alerts fired because Icinga in eqiad could not reach the public text-lb address in eqsin (Singapore). For about 12 minutes eqiad could not reach hosts in other data centers, such as the cache PoPs, through their public IP addresses.

    Network unreachable
    Trigger

    At about 09:37 a change on cr1-eqiad and cr2-eqiad, made as part of task T295672 to influence BGP route selection, removed a BGP setting that sets the BGP "MED" attribute to the OSPF cost of reaching the BGP route's next hop.

    Root cause
    Configuration change
    Component
    BGP routing
    Contributing factor
    Ineffective rollback
    Detection

    Icinga health checks against edge caching clusters alerted at 09:39; the first alert was Icinga in eqiad failing to reach the public text-lb address in eqsin.

    Remediation
    • Reverted the configuration change on both eqiad routers
    • Forced a reset of the BGP session between the two eqiad routers
    Action items
    • Updated T295672 with further detail on the incident and a proposal to adjust the BGP sessions to address the "second IXP port" issue and prevent this from happening again
    View case
  2. 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
  3. 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
  4. IL-0519 Apps on the cloud.gov PaaS became unavailable after an AWS security group change blocked their outbound traffic
    cloud.gov2016
    Symptoms

    From 9:28am Pacific Time on 8 March 2016, applications on the cloud.gov PaaS that relied on outbound traffic to reach the services they depended on became unavailable, and at one point every application on cloud.gov was down.

    Network unreachableService outage
    Trigger

    At 9:28am Pacific Time on 8 March 2016 a contractor at Aquilent changed the AWS security group settings, one of several changes made in the process of achieving ATO for the platform.

    Root cause
    Configuration change
    Component
    VPC route tables and firewall rules
    Contributing factor
    –
    Remediation
    • Added exceptions for individual applications, which restored some of them
    • Rolled back the security group change, which restored all applications
    Action items
    • Put all security group configuration into version control and make changes through pull requests
    • Monitor the applications running on cloud.gov and alert the cloud.gov team when they do not work as expected
    • Use CF security groups instead of AWS security groups and make the current rules visible to the cloud.gov team and the teams using it
    • Create a notification system to reach the key contact of each application on the platform
    • Create a more accurate staging environment to test changes like this
    View case
Check your cluster for this

These 8 cases involve BGP routing and Interior routing (IGP). kubegap audits a Kubernetes cluster for gaps like these, read-only, from Claude Code or Codex; its checks cite public reports like the ones in this library.

Open kubegap

By root cause1

Configuration change8 cases

Component
BGP routing5Interior routing (IGP)3Backbone network (WAN)2VPC route tables and firewall rules2Cloud load balancer1CNI plugin1Node pool1Terraform1
Contributing factor
Excessive blast radius3Ineffective rollback3Unverified assumption2No configuration tests2No staged rollout2Missed in review2Change during peak hours1Limited debug access1Harmful manual action1No safeguard on destructive change1Overlapping failures1Unrepresentative staging1
Organisation
cloud.gov1Jenkins project1KT1Microsoft Azure1OVHcloud1PSBA1Twingate1Wikimedia Foundation1
  1. IL-0400 Public sector sites across Wales lost connectivity for over 8 hours as a PE router wrongly advertised a default route
    PSBA2026
  2. IL-0473 Jenkins infrastructure went fully down after a pod IP range fix deleted every AKS node pool and could not recreate them
    Jenkins project2023
  3. IL-0541 Two Twingate Relay clusters were discoverable but unreachable, so Clients and Connectors could not attach to them
    Twingate2023
  4. IL-0225 An IGP purge command made every Microsoft WAN router recompute routes, causing global latency, timeouts and packet loss
    Microsoft Azure2023
  5. IL-0266 Eqiad routers looped traffic between each other after a BGP MED change and could not reach other sites' public IPs
    Wikimedia Foundation2021
  6. IL-0539 KT's internet service failed nationwide for about 89 minutes as wrong routes spread from one router in Busan
    KT2021
  7. IL-0228 IPv4 routing across OVHcloud's global network broke after a router change put the full internet routing table into OSPF
    OVHcloud2021
  8. IL-0519 Apps on the cloud.gov PaaS became unavailable after an AWS security group change blocked their outbound traffic
    cloud.gov2016