Incident Library
Applied filters Root causeConfiguration changeComponentBGP routingFactorIneffective rollbackClear allEvery case under the filters, with no sentence; newest first.
Suggested filters Search, and the values found in your words appear here.

Graph

  • Root cause
  • Component
  • Symptom
  • Contributing factor
  • Case

Cases3 cases

1 to 3 of 3

  1. IL-0400 Public sector sites across Wales lost connectivity for over 8 hours as a PE router wrongly advertised a default route
    PSBA2026
    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.

    Network unreachableIntermittent connection failuresLink flapping
    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
    Configuration change
    Component
    BGP routing
    Contributing factor
    Ineffective rollbackMissed in reviewLimited debug accessOverlapping failures
    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.

    View case
  2. IL-0266 Eqiad routers looped traffic between each other after a BGP MED change and could not reach other sites' public IPs
    Wikimedia Foundation2021
    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.

    Network unreachable
    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
    Configuration change
    Component
    BGP routing
    Contributing factor
    Ineffective rollback
    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
    View case
  3. IL-0228 IPv4 routing across OVHcloud's global network broke after a router change put the full internet routing table into OSPF
    OVHcloud2021
    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.

    Network unreachableService outage
    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
    Configuration change
    Component
    Interior routing (IGP)BGP routingBackbone network (WAN)
    Contributing factor
    Ineffective rollbackExcessive blast radius
    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
    View case
Check your cluster for this

These 3 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.

Open kubegap

By root cause1

Configuration change3 cases

Component
BGP routing3Backbone network (WAN)1Interior routing (IGP)1
Contributing factor
Ineffective rollback3Excessive blast radius1Limited debug access1Overlapping failures1Missed in review1
Organisation
OVHcloud1PSBA1Wikimedia Foundation1
  1. IL-0400 Public sector sites across Wales lost connectivity for over 8 hours as a PE router wrongly advertised a default route
    PSBA2026
  2. IL-0266 Eqiad routers looped traffic between each other after a BGP MED change and could not reach other sites' public IPs
    Wikimedia Foundation2021
  3. IL-0228 IPv4 routing across OVHcloud's global network broke after a router change put the full internet routing table into OSPF
    OVHcloud2021