Incident Library
Applied filters ComponentBackbone network (WAN)Clear 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

Cases12 cases

11 to 12 of 12

  1. Symptoms

    On Sunday 2 June 2019, with user impact beginning between 11:47 and 11:49 US/Pacific, Google Cloud projects in several US regions saw elevated packet loss from network congestion, and some regions became unreachable. Customers saw higher latency, intermittent errors and lost connectivity to instances in us-central1, us-east1, us-east4, us-west2, northamerica-northeast1 and southamerica-east1, while us-west1, Europe and Asia had no regional congestion.

    Trigger

    At 11:45 US/Pacific a relatively rare type of datacenter maintenance event started in one physical location, and the automation that runs it descheduled logical clusters that also held network control plane jobs in other physical locations.

    Root cause
    Component
    Contributing factor
    Detection

    Google engineers were alerted to the failure two minutes after it began and started the incident process used for the most serious production incidents. The first customer notice appeared on the status page at 12:53 US/Pacific.

    Remediation
    • Lowered the priority of less critical network traffic classes to reduce congestion
    • Halted the datacenter automation software responsible for the maintenance event
    • Rescheduled the network control plane and its supporting infrastructure in each location
    • Rebuilt and redistributed the lost network control plane configuration, rolling it out from 14:03
    • Directed service traffic away from the affected regions
    • Moved the Cloud VPN control plane in three regions out of its fail-safe state
    Action items
    • Keep the maintenance automation off until safeguards stop it descheduling jobs in several physical locations at once
    • Harden the cluster management software to reject such requests whatever their origin
    • Reconfigure the network control plane to reject maintenance requests of the type involved
    • Make the network control plane in each location persist its configuration
    • Let the network stay in fail static mode longer when the control plane is lost
    • Review, update and test emergency response tooling and procedures, including customer communication tooling, for such network failures
    • Extend continuous disaster recovery testing to this and similarly catastrophic failures
  2. Symptoms

    At about 08:49 UTC on 2 June 2019, Packet's internal network monitoring alerted on serious reachability and performance problems in several of Packet's global datacenter locations. The first investigation found routing loops and traffic being blackholed to specific internal and Internet destinations.

    Trigger

    A trans-continental US backbone link in the network of Packet's upstream provider Zayo had a hardware failure and blackholed IP traffic routed over it.

    Root cause
    Component
    Contributing factor
    –
    Detection

    Packet's internal network monitoring alerted at 08:49 UTC on reachability issues in several global datacenter locations, and engineers confirmed them at 08:52.

    Remediation
    • Migrated traffic to an alternative network and removed Zayo from the provider mix
    • Applied route filters to return service to normal
    • Optimised specific routing policies to improve latency across the backbone with the new traffic mix
    Action items
    • Expand internal connectivity monitoring and alerting of on-call operations teams
    • Expand network automation and routing so traffic can be balanced across all available backbone paths and an operator can trigger automated re-routes across all Packet datacenters in a major provider incident
    • Make Packet's provisioning systems less dependent on third party network providers and inter-datacenter connectivity
Check your cluster for this

These 12 cases involve Backbone network (WAN) and BGP routing. 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 cause5

Configuration change3 cases

  1. IL-0394 A Cloudflare router in Miami leaked IPv6 BGP routes to peers and providers for 25 minutes, congesting the backbone
  2. IL-0225 An IGP purge command made every Microsoft WAN router recompute routes, causing global latency, timeouts and packet loss
  3. IL-0228 IPv4 routing across OVHcloud's global network broke after a router change put the full internet routing table into OSPF

Capacity exhaustion1 case

Contributing factor
–
Organisation
  1. IL-0564 Linode's Miami, Milan and Sao Paulo data centers had packet loss as traffic moved onto congested alternate paths
    Linode2025

Operator error2 cases

Organisation
  1. IL-0348 Scaleway's FR-PAR region lost public internet connectivity when one 100 Gbps backbone link was saturated
  2. IL-0221 A backbone maintenance command disconnected all Facebook data centers, and its DNS servers withdrew their BGP routes
    Meta2021

Software defect3 cases

  1. IL-0344 Linode's US-West data centers in Fremont and Santa Clara lost connectivity as the fibre circuits between them failed
    Linode2023
  2. IL-0256 Basecamp was fully down twice in two days as hardware load balancers crashed and routers lost sync after failover
  3. IL-0222 Google Cloud US regions had heavy packet loss and some went unreachable after the network control plane was descheduled

Dependency failure3 cases

  1. IL-0267 Wikimedia's eqsin cache site went unreachable when both of its transport links to the core data centers were down
  2. IL-0255 Basecamp's two redundant links between data centers dropped together and a Redis replica resync loop stalled chat
  3. IL-0358 Packet Public Cloud locations had high latency and unreachable paths from routing loops and blackholed traffic
    Packet2019