Cases2 cases

1 to 2 of 2

1. IL-0509 SourceHut was down for 170 hours after a DDoS led its upstream network to null-route the PHL datacenter's subnet

   SourceHut2024

   Symptoms

   At about 06:00 UTC on 10 January 2024, SourceHut's monitoring raised the alarm as a layer 3 DDoS attack hit its infrastructure in the PHL datacenter, and at about 09:00 UTC SourceHut lost all access to its PHL network. PHL was the primary datacenter, and the network became unreachable for SourceHut staff and the general public alike.

   Network unreachableService outage

   Trigger

   A layer 3 DDoS attack against SourceHut's PHL infrastructure that began at about 06:00 UTC on 10 January 2024 and broadened to more of the PHL subnet on 11 January.

   Root cause

   Dependency failure

   Component

   ISP and transit networksBGP routing

   Contributing factor

   Single point of failureLimited debug accessUntested backup

   Detection

   SourceHut's monitoring systems noticed that something was wrong and raised the alarm from about 06:00 UTC on 10 January.

   Remediation

   • Got Cogent, through the colocation provider, to narrow the null route from the /24 to the targeted /32, which mostly restored service on 10 January
   • Moved DNS to an external DNS provider
   • Brought up a new primary database in AMS
   • Restored backups from FRE to AMS
   • Applied the difference between production data and the last backups by hand
   • Provisioned a new mail system and configured the mail services for it
   • Set up an OVH box that NATs traffic through OVH's DDoS-resistant network to the production subnet in AMS
   • Used a temporary subnet from the PHL network provider for out-of-band access to the PHL servers
   • Served pages.sr.ht through an out-of-band link to PHL while its object storage was migrated
   • Emailed pages.sr.ht users whose apex records pointed at the PHL subnet with instructions
   • Ran build workers on dedicated bare-metal OVH servers

   Action items

   • Provision a new standby database
   • Configure backups from AMS to FRE
   • Install a new monitoring system
   • Retire the PHL datacenter installation and ship its servers to AMS
   • Move build service back onto SourceHut-operated servers once the build servers are shipped from PHL to AMS
   • Research and implement a way to run SourceHut in an on-premise Kubernetes cluster
   • Plan a second production-ready datacenter to load balance against, able to take over full service in a datacenter outage

   Lessons

   The operational plans SourceHut kept for failures up to the loss of a whole datacenter proved important in this incident. The incident exposed a known shortcoming in redundancy and resilience that the team was working on but had not finished, and the response of the upstream network to the attack did more damage than anything else.

   View case
2. IL-0267 Wikimedia's eqsin cache site went unreachable when both of its transport links to the core data centers were down

   Wikimedia Foundation2023

   Symptoms

   On 10 January 2023 at 16:37 UTC Icinga reported "BGP status on cr3-eqsin is CRITICAL: BGP CRITICAL - AS1299/IPv6: Active - Telia, AS1299/IPv4: Active - Telia", and from 16:45 the hosts in Wikimedia's eqsin site went DOWN with "PING CRITICAL - Packet loss = 100%". Users normally directed to eqsin, mostly in the APAC region, could only read Wikipedia pages already cached in eqsin.

   Network unreachable

   Trigger

   Planned maintenance by the transport provider took down eqsin's second transport link while the first was still down from a long fiber cut.

   Root cause

   Dependency failure

   Component

   Backbone network (WAN)BGP routingCDN and edge network

   Contributing factor

   Single point of failureIgnored early signal

   Detection

   Automated monitoring: Icinga BGP status alerts for cr3-eqsin at 16:37 and cr2-eqsin at 16:44, followed by a flood of host-down alerts and three pages at the same time.

   Remediation

   • Depooled eqsin from DNS
   • Repooled eqsin

   Action items

   • Create a backup GRE tunnel for eqsin (T327265)
   • Ensure the long-down transport link comes back up properly once it is fixed (T322529)
   • Automatically parse maintenance notifications and alert on conflicting maintenance (T230835)

   Lessons

   The site was depooled quickly, and "depool first, investigate later" was the right attitude. A flood of host-down alerts usually means a network problem. eqsin stayed too long on a single working transport link, SREs did not catch that the downtime of the two transport links overlapped, and the provider's planned maintenance was not recorded in a task or reminder.

   View case

By root cause1