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

7 to 8 of 8

  1. 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.

    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
    Component
    Contributing factor
    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
  2. 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.

    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
    Component
    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
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.

By root cause1

Configuration change8 cases

  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
  3. IL-0541 Two Twingate Relay clusters were discoverable but unreachable, so Clients and Connectors could not attach to them
  4. IL-0225 An IGP purge command made every Microsoft WAN router recompute routes, causing global latency, timeouts and packet loss
  5. IL-0266 Eqiad routers looped traffic between each other after a BGP MED change and could not reach other sites' public IPs
  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
  8. IL-0519 Apps on the cloud.gov PaaS became unavailable after an AWS security group change blocked their outbound traffic