Cases3 cases

1 to 3 of 3

1. IL-0350 Hosts in an IONOS TXL cluster lost connectivity when an InfiniBand fabric resweep failed on a full multicast table

   IONOS Cloud2026

   Symptoms

   On 3 March 2026, during a scheduled maintenance to replace a faulty switch in a cluster in IONOS Cloud's TXL data center, monitoring alerts fired and the hosts in that cluster lost network connectivity. Customers saw intermittent network degradation or outages, and the Data Center Designer (DCD) web frontend and the AI Model Hub became unreachable.

   Network unreachableLink flappingService outage

   Trigger

   During a scheduled maintenance to replace a faulty switch, Topology 2 of 2 in the affected cluster was disabled as planned, and a link flap on a switch in Topology 1 then flooded the InfiniBand control plane with alerts and started a fabric resweep.

   Root cause

   Capacity exhaustion

   Component

   InfiniBand fabricNetwork control plane (SDN)BGP routingNIC, cable and switch port linkModel hubDatabase

   Contributing factor

   Automation amplificationExcessive blast radius

   Detection

   IONOS began investigating monitoring alerts in TXL; the first status update was posted at 11:36 UTC.

   Remediation

   • Switched from the affected control plane to its standby
   • Rebooted the locked-up gateways
   • Recovered Topology 1 from the scheduled maintenance
   • Paused provisioning in the cluster that had a backlog of queued jobs
   • Re-enabled provisioning once network connectivity improved and watched job execution
   • Re-established connectivity for the systems that support the DCD

   Action items

   • Adjusted the control-plane configuration to use less aggressive failover timers and reduced heavy sweep activity, lowering the load on the forwarding table
   • Reduced the number of multicast group memberships to relieve the forwarding table
   • Set up continuous monitoring of forwarding table use and control-plane memory with alerts before capacity limits are reached
   • Move the control plane to dedicated high-performance servers, separate from data-plane traffic
   • Audit IPv6 configurations and IPoIB driver settings
   • Modernise the interconnect fabric, including switches, gateways and drivers
   • Hardened IAM maintenance protocols so that critical identity services keep working when the primary Cloud APIs are temporarily unavailable
   • Move IAM to a dedicated platform without a dependency on the standard managed Kubernetes clusters
   • Introduce a dedicated provisioning provider for DBaaS and Managed Kubernetes
   • Add automated circuit breakers to the provisioning engine against overload and queue buildup from self-healing services
   • Improve visibility and control over job execution and prioritisation in the provisioning queue
   • Change the provisioning queue architecture to decouple services and reduce spillover

   Lessons

   IONOS identified the linking of services through the shared provisioning queue as a key reason the degradation lasted as long as it did. Alongside making each service more robust, it is decoupling the provisioning queue and addressing dependencies between services to reduce the blast radius of future incidents.

   View case
2. 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
3. IL-0337 EBS volumes in one US East Availability Zone got stuck after a network change cut EBS nodes off from their replicas

   Amazon Web Services2011

   Symptoms

   From 12:47 AM PDT on 21 April 2011, a subset of Amazon EBS volumes in one Availability Zone of the US East Region could no longer serve reads or writes, and EC2 instances that tried to use them got stuck as well. AWS called these "stuck" volumes. EBS API calls across the whole US East Region also returned high error rates and latencies during two periods on the first day.

   Storage disconnected or stale mountsNetwork unreachableControl plane lagHigh error rateFailover failureData loss

   Trigger

   During a routine network change to upgrade the capacity of the primary EBS network in one Availability Zone, traffic was to be shifted off one of the redundant routers. The shift was executed incorrectly and sent the traffic onto the lower-capacity replication network instead of the other primary router, which could not carry it.

   Root cause

   Operator error

   Component

   Cloud block storageDatabase

   Contributing factor

   Automation amplificationRetry stormNo headroomExcessive blast radiusSignal buried in noise

   Remediation

   • Rolled back the incorrect traffic shift, which restored network connectivity
   • Disabled all new Create Volume requests in the affected Availability Zone at 2:40 AM PDT
   • Disabled all communication between the degraded EBS cluster and the EBS control plane from 8:20 AM PDT
   • Stopped EBS servers in the degraded cluster from futilely contacting other servers for free space
   • Changed the EBS control plane so new EBS-backed instance launches stopped failing
   • Moved spare server capacity physically from across the US East Region into the degraded cluster
   • Adjusted the negotiation throttles so the new servers could join without flooding the old ones
   • Built a separate EBS control plane partitioned to the affected zone and finer-grained throttles, then processed the backlog
   • Restored the remaining volumes from S3 snapshots taken early in the event
   • Restored volumes on failed machines that had no snapshot after forensic work
   • Intervened by hand on the RDS multi-AZ instances that did not fail over automatically

   Action items

   • Audit the change process and add automation to prevent the traffic shift mistake
   • Change capacity planning and alarming to keep the extra safety capacity needed for large recovery events
   • Change the retry logic in EBS nodes to back off harder and reconnect to previous replicas instead of searching for new nodes
   • Test and deploy the fix for the race condition that crashed EBS nodes
   • Fix the RDS bug that kept multi-AZ instances from failing over automatically
   • Improve the EBS control plane timeout logic to prevent thread exhaustion when one zone's cluster is slow
   • Make the EBS control plane aware of Availability Zones so it sheds load when over capacity
   • Move more EBS control plane functions into per-cluster services that run in the same zone as the cluster
   • Offer multiple Availability Zones to Amazon VPC customers
   • Provide better tools for building multi-AZ applications that survive the loss of a zone
   • Host free webinars and publish whitepapers on fault-tolerant architecture
   • Build the fine-grained control and throttling used in recovery into the EBS nodes and automate the recovery models
   • Look at changes that keep volumes working while a cluster is degraded, including the ability to take a snapshot of a stuck volume
   • Send more frequent and detailed customer updates and staff developer support more widely during events
   • Develop tools that show through the APIs whether instances are impaired

   Lessons

   AWS writes that with more spare capacity the cluster would have absorbed the re-mirroring requests without a storm, and that it now understands how much capacity large recovery events need. The event also showed that the EBS control plane let a failure in one Availability Zone affect the others, so more work is needed to make zones behave as if completely independent. AWS adds that some customers had critical components in a single zone, and that multi-AZ deployments need to become easier to design and run.

   View case

By root cause3