Cases6 cases

1 to 5 of 6

1. IL-0394 A Cloudflare router in Miami leaked IPv6 BGP routes to peers and providers for 25 minutes, congesting the backbone

   Cloudflare2026

   Symptoms

   On 22 January 2026 from 20:25 UTC, a Cloudflare edge router in Miami sent unintended BGP advertisements of IPv6 prefixes to its transit providers and peers. External networks' traffic was funnelled into the Miami data center, the backbone between Miami and Atlanta became congested, and some Cloudflare customer traffic saw elevated loss and higher latency.

   Packet lossHigh latency

   Trigger

   At 20:25 UTC Cloudflare's policy automation pushed a change, merged at 19:52 UTC, that removed the BGP announcements from Miami for a data center in Bogotá, Colombia, by deleting the prefix-list 6-BOG04-SITE-LOCAL from several export policy terms.

   Root cause

   Configuration change

   Component

   BGP routingBackbone network (WAN)

   Contributing factor

   No configuration tests

   Detection

   The network team began investigating unintended route advertisements from Miami at 20:40 UTC, and an incident was raised at 20:44 UTC.

   Remediation

   • A network operator reverted the bad configuration change on the Miami router by hand
   • Paused the automation for the router so it could not run again
   • Reverted the triggering change in the network automation code repository
   • Unpaused the automation on the Miami router after confirming it ran without the routing policy bug

   Action items

   • Patch the failure in the routing policy automation that caused the leak
   • Add BGP community-based safeguards that reject routes received from providers and peers on external export policies
   • Add automatic routing policy evaluation to the CI/CD pipelines that looks for empty or erroneous policy terms
   • Detect problems in network configurations and the effects of automated changes earlier
   • Validate routing equipment vendors' implementations of RFC9234 before rolling out BGP roles and the Only-to-Customer Attribute
   • Encourage long-term adoption of RPKI Autonomous System Provider Authorization (ASPA)

   Lessons

   Removing only the prefix lists from export policy terms left terms that were too permissive, because a match on route-type internal accepts IBGP routes as well. Cloudflare states that route leaks are easy to cause by accident and that RFC9234 is the only way, independent of routing policy, to prevent route leaks caused at the local AS.

   View case
2. 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
3. IL-0348 Scaleway's FR-PAR region lost public internet connectivity when one 100 Gbps backbone link was saturated

   Scaleway2025

   Symptoms

   On 10 March 2025 at 16:22 UTC, public internet connectivity in Scaleway's FR-PAR region broke for all products. Most internet traffic between the FR-PAR-2 availability zone and the rest of the PAR region was blackholed for about five minutes, while VPC traffic and Dedibox RPN kept working.

   Packet lossService outageHigh latency

   Trigger

   While Scaleway's network team connected a new data center to the FR-PAR backbone, a human mistake in a router configuration rerouted more than 1 Tbps of traffic between OpCore DC3 and DC5 through a single 100 Gbps link.

   Root cause

   Operator error

   Component

   Backbone network (WAN)Object storageAuthoritative DNS servers and records

   Contributing factor

   Automation amplification

   Detection

   The router configuration error was detected quickly and rolled back within four minutes.

   Remediation

   • Rolled back the router configuration, restoring the correct configuration at 16:27 UTC

   Action items

   • Harden the peer review and production communication process for changes
   • Add failsafes and tests before network configuration is applied at backbone level
   • Deploy the fix for the Object Storage synchronisation software issue

   View case
4. IL-0225 An IGP purge command made every Microsoft WAN router recompute routes, causing global latency, timeouts and packet loss

   Microsoft Azure2023

   Symptoms

   From 07:08 UTC on 25 January 2023, customers saw long network latency and timeouts when connecting to resources in Azure regions and to other Microsoft services such as Microsoft 365 and Power Platform. Microsoft's monitoring detected DNS and WAN issues from 07:11 UTC.

   High latencyIntermittent timeoutsIntermittent connection failuresPacket lossNetwork unreachable

   Trigger

   A network engineer adding capacity to the global WAN in Madrid ran a step of a recently changed standard operating procedure that purged the IGP database; on the router manufacturer involved, that command runs on all IGP-joined routers instead of only the local one.

   Root cause

   Configuration change

   Component

   Backbone network (WAN)Interior routing (IGP)BGP routing

   Contributing factor

   No configuration testsUnverified assumptionExcessive blast radiusHarmful manual action

   Detection

   Monitoring detected DNS and WAN issues from 07:11 UTC and alerted the on-call engineers within 5 minutes of the command being run. The team reviewed all recent changes and identified the command by 08:20 UTC. The engineer making the change was not informed of the alerts because of the unqualified changes to the SOP.

   Remediation

   • Restarted by hand the paused WAN health and traffic engineering systems, which ended the remaining packet loss

   Action items

   • Audit and block similar widespread-impact commands across all three vendors for all WAN router roles
   • Give on-call engineers real-time visibility of approved and unqualified activity on network devices
   • Run regular mandatory operational training and attestation of following all SOPs
   • Have the Change Advisory Board review all SOPs still pending qualification within 30 days

   View case
5. 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

By root cause5