Graph
Cases5 cases
1 to 5 of 5
IL-0400Public sector sites across Wales lost connectivity for over 8 hours as a PE router wrongly advertised a default routePSBA2026- Symptoms
On 25 March 2026 from about 16:40, public sector organisations on the PSBA network across Wales lost connectivity at their sites. The Service Desk saw about 400 alerts at 16:58, when a Major Incident was declared, about 1,500 at 17:05 and about 5,000 across Wales at 17:08, while councils, a fire and rescue service and Natural Resources Wales phoned in to report sites down.
- Trigger
At 16:30 a route map change was applied, outside formal change control, on a PSBA core Provider Edge (PE) router to leak MPLS VPN routes, so that legacy Capita-operated UPS devices in a /16 subnet could be managed by BT/PSBA. The change was removed at 16:40.
- Root cause
- Component
- Contributing factor
- Detection
At 16:57 Mid Wales Fire & Rescue Service phoned in a loss of connectivity at its Presteigne site, and at 16:58 a case was opened in Service Now for a group of about 400 alerts and a Major Incident was declared.
- Remediation
- Removed the route map change from the PE router at 16:40
- Changed QoS on the BGP to bring back the management links, after which alarms cleared
- Cleared routes and reset inbound BGP advertisements, which did not stop the default route being advertised
- Corrected the configuration issue affecting the internet learned route at 01:02
- Performed a controlled reload of the affected router at 01:10, which restored customer services and management connectivity
- Action items
- Reinforce change control requirements with an internal briefing on formal change submission, the risks of unplanned changes and roles during planned and emergency changes
- Create a dedicated Microsoft Teams channel as the single real-time communication point for all live P1 and Major Incidents
- Explore disaster recovery and business continuity test exercises for major or P1 incidents
- During loss of management access, have all technical teams assess customer impact from what reporting organisations provide, captured and shared in real time by the Service Desk and Incident Management
- Investigate a fixed link between Capital Quarter and the PSBA management racks in Vantage Data Centre at Newport, with dedicated management terminals and two-factor authentication for access outside the secure management platform
- Improve initial triage with stronger probing questions when incidents are reported and keep reassessing and communicating impact throughout the incident
- Review the P1 and Major Incident process so escalation criteria and timeframes are clearly defined, and train the Service Desk to recognise and escalate them early
- Review the PSBA estate for legacy configuration, set processes and timeframes for removing it and add controls so it is not introduced again
- Review email and SMS distribution lists and processes and reinforce Service Desk training on customer communications during P1 and Major Incidents
- Lessons
The report names eight lessons: a change was made outside PSBA change control; internal communication during the Major Incident was slow and fragmented; the organisation was not ready for a network-wide incident; losing management access stopped the resolver groups from seeing the network state and customer impact; the resolver groups did not understand customer impact in enough detail, which delayed finding the root cause; escalation to PSBA management was slow; legacy configuration left in the network contributed; and email and SMS communications did not reach some customers in time.
IL-0233A VPC control plane release broke IP alias routes in Nebius eu-west1, and Managed Kubernetes pods lost connectivityNebius2025- Symptoms
On 13 March 2025 practically every pod of Nebius Managed Services for Kubernetes in the eu-west1 region lost network connectivity for at least some time between 13:36 and 18:11 UTC. Packets for the affected IP alias routes were not processed by the data plane. The eu-north1 region was not affected.
- Trigger
A release of a VPC control plane component in eu-west1, deployed to canaries from 13:36 UTC and to all other nodes from 14:35 UTC, changed route distinguisher values for a new feature. The change made a long-standing bug in the handling of route announcements take effect for the update messages of Managed Kubernetes pods.
- Root cause
- Component
- Contributing factor
- Remediation
- Restarted the host VPC component on the affected nodes one node at a time
- Restarted the host VPC component on the remaining nodes in parallel once the restart was known to fix the problem
- Action items
- Fix the bug in the VPC host component itself
- Add an alert on a diverging number of routes
- Add an alert on the number of drops in the data plane
- Develop a way to reset endpoints without restarting the host VPC component
- Move the VPC's persistent e2e test virtual machines to canary hosts
- Add persistent e2e tests for Managed Services for Kubernetes
- Run e2e tests more often
- Add a deployment stage in which non-critical internal services receive updates first
- Lessons
The failure needed both an existing IP alias at release time and a particular order of node updates, and neither the testing installation nor the canaries met both, so neither caught it. Missing alerts on technical metrics that deviate from normal, here the number of routes and the number of drops, made the response much slower.
- Symptoms
On 23 November 2021 at 09:39, two minutes after a change on the eqiad core routers, alerts fired because Icinga in eqiad could not reach the public text-lb address in eqsin (Singapore). For about 12 minutes eqiad could not reach hosts in other data centers, such as the cache PoPs, through their public IP addresses.
- Trigger
At about 09:37 a change on cr1-eqiad and cr2-eqiad, made as part of task T295672 to influence BGP route selection, removed a BGP setting that sets the BGP "MED" attribute to the OSPF cost of reaching the BGP route's next hop.
- Root cause
- Component
- Contributing factor
- Detection
Icinga health checks against edge caching clusters alerted at 09:39; the first alert was Icinga in eqiad failing to reach the public text-lb address in eqsin.
- Remediation
- Reverted the configuration change on both eqiad routers
- Forced a reset of the BGP session between the two eqiad routers
- Action items
- Updated T295672 with further detail on the incident and a proposal to adjust the BGP sessions to address the "second IXP port" issue and prevent this from happening again
IL-0228IPv4 routing across OVHcloud's global network broke after a router change put the full internet routing table into OSPFOVHcloud2021- Symptoms
At 09:20 CET on 13 October 2021, during a planned change on a router, IPv4 traffic across OVHcloud's whole network stopped being routed, while all IPv6 traffic stayed reachable. The team detected a problem with the router's performance at 09:21 CET and escalated at once.
- Trigger
A planned change to a router in the Vint Hill datacentre in the United States, meant to strengthen anti-DDoS protection, included a command to regulate the redistribution of BGP into OSPF, and the router did not interpret that command correctly.
- Root cause
- Component
- Contributing factor
- Detection
At 09:21 CET the team detected a problem with the router's performance and started the escalation process.
- Remediation
- Disconnected the optical equipment to isolate the router's connectivity
- Powered off the faulty router
- Stabilised connectivity to restore the remaining services
- Action items
- Re-evaluate the change procedure for this type of equipment, which applies the command line natively
- Strengthen the related change process
IL-0222Google Cloud US regions had heavy packet loss and some went unreachable after the network control plane was descheduledGoogle 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.
- 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
- Component
- Contributing factor
- 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
These 5 cases involve BGP routing and Backbone network (WAN). 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.
By root cause2
Configuration change3 cases
- Contributing factor
- Organisation
IL-0400Public sector sites across Wales lost connectivity for over 8 hours as a PE router wrongly advertised a default routePSBA2026IL-0266Eqiad routers looped traffic between each other after a BGP MED change and could not reach other sites' public IPsIL-0228IPv4 routing across OVHcloud's global network broke after a router change put the full internet routing table into OSPFOVHcloud2021
Software defect2 cases
- Contributing factor
- Organisation