Cases5 cases

1 to 5 of 5

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

   Linode2025

   Symptoms

   Customers using Linode's US-MIA (Miami) and IT-MIL (Milan) data centers saw packet loss and brief performance problems on 14 September 2025 from 17:42 to 18:43 UTC. BR-GRU (Sao Paulo) had the same packet loss on 15 September 2025 from 01:44 to 04:22 UTC.

   Packet loss

   Trigger

   A gradual increase in prefixes pushed the routing between the core router and the edge router past the maximum number of permitted prefixes.

   Root cause

   Capacity exhaustion

   Component

   BGP routingBackbone network (WAN)

   Contributing factor

   –

   Remediation

   • Raised the prefix limit on all the data center routers

   Action items

   • Raise the thresholds of the sessions between Akamai's backbone and the data center ECOR routers
   • Improve the existing alerting and check its severity before limits are reached, with escalation to the right team for immediate action

   View case
2. IL-0341 Traffic between Cloudflare and AWS us-east-1 had high latency, packet loss and origin failures for almost four hours

   Cloudflare2025

   Symptoms

   From 16:27 UTC on 21 August 2025, users connecting to Cloudflare from servers in AWS us-east-1, or receiving connections from Cloudflare there, saw high latency, packet loss and failures to reach origins. Cloudflare's network team was alerted to internal congestion in Ashburn (IAD) at 16:44 UTC.

   Packet lossHigh latencyIntermittent timeouts

   Trigger

   At about 16:27 UTC a single customer began sending many requests from AWS us-east-1 to Cloudflare for objects in Cloudflare's cache, doubling the total traffic from Cloudflare to AWS.

   Root cause

   Capacity exhaustion

   Component

   Transit gateway or network interconnectBGP routingCDN and edge network

   Contributing factor

   No headroomHarmful manual actionExcessive blast radius

   Detection

   Cloudflare's network team was alerted to internal congestion in Ashburn (IAD) at 16:44 UTC, and an incident was raised for customer impact at 17:45 UTC.

   Remediation

   • Rate limited the single customer whose traffic caused the surge
   • Took further traffic engineering actions that fully resolved the congestion
   • Asked AWS to revert its BGP prefix withdrawals, which AWS finished at 20:07 UTC

   Action items

   • Build a mechanism to deprioritise a customer's traffic when it congests the network enough to affect others
   • Speed up the Data Center Interconnect upgrades to add network capacity
   • Work with AWS so the two companies' BGP traffic engineering actions do not conflict
   • Build a traffic management system that gives each customer a network resource budget and automates the manual actions used here

   Lessons

   Cloudflare concludes that it must isolate customers better so that no single customer can take over shared network resources and degrade the platform for others, and that its network needs enough capacity to meet demand. It describes the outage as the result of insufficient network congestion management during an unusual high-traffic event.

   View case
3. IL-0440 Pods on Cybozu's Neco Kubernetes platform got frequent no such host and i/o timeout DNS errors from dropped packets

   Cybozu2024

   Symptoms

   A team using Neco, the Kubernetes platform run by Cybozu's Cloud Platform team, reported what looked like a performance problem in the cluster DNS servers. An application in a pod that resolved cluster Services at hundreds of requests per second frequently got `no such host` and `i/o timeout` errors.

   DNS resolution failuresIntermittent timeoutsPacket loss

   Trigger

   The number of MySQL clusters watched by the monitoring application increased, and after that the name resolution errors became frequent.

   Root cause

   Capacity exhaustion

   Component

   Linux kernelClient-side DNS resolver and cache

   Contributing factor

   Unreviewed defaults

   Detection

   A team using the platform contacted the Cloud Platform team, describing the errors as a performance problem in the cluster DNS server.

   Remediation

   • Raised the kernel parameter netdev_max_backlog on the nodes
   • Set up alerts on softnet
   • Wrote a runbook for the softnet alerts

   Action items

   • Evaluate Cilium's netkit device so pod packets bypass the backlog queue

   Lessons

   Raising netdev_max_backlog makes the same failure less likely and the new alerts catch it early, but it is not a root fix: a pod that sends more packets can fill the backlog queue again. Cybozu sees replacing the veth interface with netkit, which skips the backlog queue, as the root fix.

   View case
4. IL-0386 After a move to Google Cloud, Postgres connection timeouts and memcached i/o timeouts spiked on GKE nodes

   incident.io2023

   Symptoms

   Shortly after incident.io moved its infrastructure fully into Google Cloud, the application saw a larger-than-normal number of Postgres connection timeouts, and new database connections per second were in the hundreds, spiking up and down. At the same time, the memcached instance used for transient data and faster API responses had sporadic connection timeouts.

   Intermittent timeoutsPacket loss

   Trigger

   After the move to Google Cloud, the application opened hundreds of new Postgres connections per second, and an accidental database join made it send thousands of duplicate calls to an external third party in parallel.

   Root cause

   Capacity exhaustion

   Component

   CNI pluginDatabaseIn-memory cache

   Contributing factor

   Unreviewed defaultsOverlapping failures

   Detection

   An incident was declared when the number of Postgres connection timeouts rose above normal. The remaining cache timeouts were traced through the logs of the Kubernetes node that served an affected request, the request's trace and the node's metrics.

   Remediation

   • Doubled the maximum Postgres connection lifespan from 15m to 30m
   • Made the Postgres connection pools static so they always keep N connections open
   • Raised the memcache client's MaxIdleConns from 2 to 20
   • Moved temporarily from Google's hosted memcached to a memcached inside the Kubernetes cluster
   • Shipped the fix for the accidental database join that made thousands of duplicate external calls

   Action items

   • Set more sensible concurrency limits for outbound network calls

   Lessons

   Network timeouts are not always local to one request or pod: when they appear, the whole activity of the node, including other pods on it, needs to be checked. Staying within a provider's rate limits does not keep outbound calls from affecting a node, so outbound network calls need more sensible concurrency limits.

   View case
5. IL-0537 Sakura Cloud host servers repeatedly lost their storage connection, about five minutes per port switchover

   Sakura Internet2012

   Symptoms

   From mid-December 2011, after Sakura Cloud launched, traffic between the host servers and the storage device grew, and the network connection between the hosts that carry users' servers and the storage device was cut again and again. Each cut caused by a port switchover lasted about five minutes.

   Storage disconnected or stale mountsPacket loss

   Trigger

   Traffic between the host servers and the storage device grew from mid-December 2011, after the service launched on 15 November 2011.

   Root cause

   Capacity exhaustion

   Component

   Cloud block storageInfiniBand fabric

   Contributing factor

   Automation amplificationUnrepresentative stagingLimited debug access

   Remediation

   • Switched the network interface monitoring from ICMP to a LINK state check, so the device fails over only on a physical link down
   • Changed the InfiniBand Subnet Manager's check from normal mode to heavy sweep mode
   • Updated the storage device firmware on 19 March, which stopped the packet loss
   • Added a second storage device on 12 March and migrated servers to it to reduce and spread the load

   Action items

   • Replace the current storage with an entirely different new storage device
   • Test the new storage in an environment equal to its maximum capacity under real load, with a free beta before paid service
   • Use network interface drivers and similar parts equivalent to those already proven on the host servers
   • Develop the new storage with in-house engineers so Sakura Internet can manage and operate it itself

   Lessons

   Sakura Internet wrote that it could not test the storage device at its performance limit, because it could not prepare as many servers as the design capacity and used load generated from predictions, so it could not respond quickly and accurately to problems in real operation. Packet loss on the InfiniBand port kept the device below its expected performance and took three months to fix by firmware, and its engineers could not grasp the whole of the device's specification and behaviour. Sakura Internet concluded that its process for choosing and validating the storage device had serious problems.

   View case

By root cause1