Incident Library
Applied filters Root causeSoftware defectSymptomPacket lossFactorExcessive blast radiusClear 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

Cases3 cases

1 to 3 of 3

  1. IL-0347 About 25% of Scaleway FR-PAR-1 hypervisors lost VPC connectivity when both VPC BGP route reflectors got stuck
    Scaleway2024
    Symptoms

    On 18 October 2024, from 7:50 to 8:01 UTC, about 25% of the hypervisors in Scaleway's FR-PAR-1 availability zone lost VPC connectivity with the rest of the region, and products that use VPC failed with them. Public internet connectivity and Elastic Metal VPC connectivity were not affected.

    Network unreachablePacket lossNode NotReady
    Trigger

    At 6:20 UTC a Top of Rack switch in FR-PAR-1 had a software crash. One of the two BGP route reflectors for VPC ran on a hypervisor in that rack and was left in an abnormal state.

    Root cause
    Software defect
    Component
    Network control plane (SDN)BGP routingNetwork switchDatabaseManaged Kubernetes control plane and provider API
    Contributing factor
    Excessive blast radiusAutomation amplification
    Detection

    Health-check monitoring on both route reflectors detected the anomaly, and the Scaleway Customer Excellence and SRE teams detected the customer impact and opened an incident.

    Remediation
    • Fixed both VPC route reflectors by manual action
    Action items
    • Fixed the autohealing mechanism that had failed to fix route reflectors stuck in a stale state; the fix is https://github.com/FRRouting/frr/pull/17163
    • Run different software versions on the route reflectors so a single bug cannot stop several instances
    • Investigate the software issue that left the route reflectors in a stale state
    View case
  2. IL-0529 New Google Cloud VMs and other instances came up without network connectivity in all zones after VPC controllers stopped
    Google Cloud2024
    Symptoms

    From 15:22 US/Pacific on 16 May 2024, new VMs and other new instances across Google Cloud came up without network programming, so the new instances could not open network connections, and VMs that were migrated or restarted lost connectivity. Changes to virtual network configuration, such as firewall rules and load balancers, were not applied. Internal monitoring alerted Google engineers at 15:41.

    Network unreachablePacket lossCluster or node provisioning stallScale-up failureHigh error rate
    Trigger

    Google's infrastructure team ran a routine maintenance action meant to shut down one unused VPC Controller in a single Google Cloud zone, and the automation shut down VPC controllers in all zones where the controllers were still in use.

    Root cause
    Software defect
    Component
    Network control plane (SDN)Cloud load balancerNAT gateway
    Contributing factor
    Change with a delayed effectIgnored early signalNo safeguard on destructive changeExcessive blast radius
    Detection

    Internal monitoring alerts reached Google engineers at 15:41 US/Pacific, and the investigation started immediately.

    Remediation
    • Paused maintenance operations to prevent the shutdown from repeating
    • Brought the affected VPC Controllers back into a serving state in every zone
    • Stopped the automation responsible for the shutdown until safeguards are in place
    • Recovered partial Apigee proxy deployments by hand
    • Cleaned up VMs left behind by failed Dataproc cluster deletions
    Action items
    • Add safety measures that check that maintenance operations carry correctly scoped zone information
    • Make the underlying tools reject maintenance operations that do not specify zones
    • Tighten on-demand access control so one maintenance invocation cannot work across multiple zones
    • Add safety checks, testing and validation for maintenance operations, including positive and negative test cases for the new safety measures
    View case
  3. IL-0222 Google Cloud US regions had heavy packet loss and some went unreachable after the network control plane was descheduled
    Google Cloud2019
    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.

    Packet lossNetwork unreachableHigh latencyHigh error rateMonitoring outage
    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
    Software defect
    Component
    Network control plane (SDN)BGP routingBackbone network (WAN)
    Contributing factor
    Excessive blast radiusCircular dependencyLimited debug accessIneffective rollback
    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
    View case
Check your cluster for this

These 3 cases involve Network control plane (SDN) 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.

Open kubegap

By root cause1

Software defect3 cases

Component
Network control plane (SDN)3BGP routing2Backbone network (WAN)1Cloud load balancer1Database1Managed Kubernetes control plane and provider API1NAT gateway1Network switch1
Contributing factor
Excessive blast radius3Automation amplification1Circular dependency1Change with a delayed effect1Ignored early signal1Limited debug access1No safeguard on destructive change1Ineffective rollback1
Organisation
Google Cloud2Scaleway1
  1. IL-0347 About 25% of Scaleway FR-PAR-1 hypervisors lost VPC connectivity when both VPC BGP route reflectors got stuck
    Scaleway2024
  2. IL-0529 New Google Cloud VMs and other instances came up without network connectivity in all zones after VPC controllers stopped
    Google Cloud2024
  3. IL-0222 Google Cloud US regions had heavy packet loss and some went unreachable after the network control plane was descheduled
    Google Cloud2019