Cases3 cases

1 to 3 of 3

1. IL-0293 Cloud Bigtable in us-central1 had higher latency and connection errors for about 32 hours from low-rate packet loss

   Google Cloud2023

   Symptoms

   From 19:50 US/Pacific on 4 December 2023, Cloud Bigtable customers in us-central1 saw higher latency and a low level of connection errors, affecting about 0.06% of Bigtable dataplane requests. Automated monitoring first detected the problem at 23:35.

   High latencyHigh error ratePacket lossIntermittent connection failures

   Trigger

   A change that caused an isolation failure on the machines running Cloud Bigtable servers.

   Root cause

   Faulty deployment

   Component

   Database

   Contributing factor

   –

   Detection

   Automated monitoring detected the problem at 23:35 US/Pacific on 4 December 2023.

   Remediation

   • Redirected some traffic away from a subset of the affected machines
   • Rolled back the change that triggered the isolation failure

   Action items

   • Put controls in place to prevent a recurrence

   View case
2. IL-0530 Virtual router controllers in us-central1 ran out of memory in a loop, cutting networking for new and migrated VMs

   Google Cloud2023

   Symptoms

   On 5 October 2023 in us-central1, newly created VMs waited a long time before their networking worked, and VMs that had been live migrated lost connectivity for a long time after the migration. Networking telemetry showed cross-region packet loss to and from us-central1 from 03:08 US/Pacific. Health check state of VMs reached load balancers late.

   Packet lossNetwork unreachableOOMKilledStale endpoint routingCluster or node provisioning stall

   Trigger

   A management plane behaviour change, meant to decouple the processing of API updates to Instance Groups and Network Endpoint Groups used as load balancer backends, was deployed in us-central1 after rolling out to several other regions without incident.

   Root cause

   Faulty deployment

   Component

   Network control plane (SDN)Cloud load balancer

   Contributing factor

   Excessive blast radiusNo alert on limit

   Detection

   Engineers were alerted to slowness in the virtual network control plane in us-central1 at 21:45 US/Pacific on 4 October, before the packet loss started, and to controller failures from memory exhaustion at 02:11 on 5 October. Networking telemetry showed cross-region packet loss from 03:08.

   Remediation

   • Increased the memory allocated to the virtual network router controllers
   • Rolled back the management plane change in us-central1
   • Restarted by hand the routers that were still not accepting updates

   Action items

   • Alert proactively on memory risks and unexpected memory increases
   • Refactor the deployment configuration so engineers can reallocate memory much faster
   • Re-evaluate existing practices and add safety mechanisms for API reconciliation
   • Make management plane changes more visible across teams so the changes can be correlated faster
   • Adjust the deployment footprint so a regional API change is less likely to exhaust memory across the region at once
   • Optimise memory use in the traffic routers and their controllers

   View case
3. IL-0532 Azure Software Load Balancer sent packets of one flow to different backends, dropping Firewall and Private Link traffic

   Microsoft Azure2022

   Symptoms

   From 05:26 UTC on 28 June 2022, some Azure customers saw intermittent network failures and packet loss when connecting to resources behind a Software Load Balancer (SLB). Telemetry showed a small increase in errors and customers raised support requests, but the failures were intermittent and were not linked to a recent deployment at first.

   Intermittent connection failuresPacket lossMisrouted requests

   Trigger

   A new SLB code deployment, rolled out through Safe Deployment Practices, made some MUX instances store the backend DIPs of load balancers with more than 15 DIPs in a different order.

   Root cause

   Faulty deployment

   Component

   Cloud load balancer

   Contributing factor

   Ignored early signal

   Detection

   Telemetry showed a small increase in errors and customers raised support requests, but the health checks of Safe Deployment Practices did not correlate these intermittent signals with the deployment until the code had reached 14 regions.

   Remediation

   • Mitigated the VIPs of customers identified as impacted with targeted manual operations
   • Built and tested a hotfix and rolled it out in phases under Safe Deployment Practices
   • Ran automation that scanned all VIPs every five minutes and fixed VIPs in an inconsistent state until the hotfix was out
   • Restored consistent ordering of the backend instances to the state before the incident

   Action items

   • Add Azure Firewall monitoring that detects when the upstream and downstream packets of one flow do not reach the same DIP
   • Keep the IPv6 flow identifier consistent for the lifetime of a connection so all its packets land on one MUX
   • Improve packet capture support for firewalls
   • Add logging of TCP flows, including invalid packets and RST, FIN and FIN-ACK packets
   • Onboard more Azure services to the Gandalf AIOps solution suite for end-to-end monitoring during safe deployments

   Lessons

   Microsoft wrote that the incident showed the need for more thorough end-to-end monitoring during safe deployments.

   View case

By root cause1