Cases4 cases

1 to 4 of 4

1. IL-0526 OpenStreetMap.org went offline, then read-only, for 56 hours after HE.net routing equipment cut both fibre uplinks

   OpenStreetMap Foundation2024

   Symptoms

   At 04:01 UTC on 15 December 2024, StatusCake monitoring sent SMS alerts that OpenStreetMap.org was unreachable. The website and the mapping API had gone completely offline at 03:53 UTC.

   Network unreachableService outage

   Trigger

   HE.net's routing equipment in Amsterdam failed at 03:53 UTC on 15 December 2024.

   Root cause

   Dependency failure

   Component

   ISP and transit networksDatabase replication

   Contributing factor

   Single point of failureNo runbook

   Detection

   StatusCake monitoring detected the outage at 04:01 UTC and sent SMS alerts, and the incident was reported to the operations team at once.

   Remediation

   • Activated a read-only backup instance of OpenStreetMap.org in Dublin
   • Brought a new Equinix Internet link into service in Amsterdam, bypassing HE.net and restoring full functionality
   • HE.net replaced its routing hardware and restored its service, and routing through HE.net resumed

   Action items

   • Move to a multi-ISP architecture so another provider can take over when one fails
   • Research backup ISPs for the Amsterdam servers, including BGP and keeping HE.net as a fallback
   • Add deeper route and latency monitoring and an automated escalation protocol
   • Hold failover drills for switching between ISPs and keep replication up to date
   • Agree SLAs with HE.net and Equinix Internet with defined escalation procedures and response times
   • Prepare the 4G out-of-band system as a manual fallback uplink that can sync Postgres replication data, and upgrade its hardware
   • Document outage communication procedures and delegate communication during outages
   • Investigate decoupling the OAuth service so authentication keeps working while the database is read-only

   Lessons

   Relying on HE.net alone left the Amsterdam servers with a single point of failure, so OpenStreetMap will keep multiple upstream providers. The 4G out-of-band link proved invaluable and should be able to carry data synchronisation. Resumed replication would have restored editing faster than the read-only backup. Frequent contact with the ISP gave no useful estimates, so the SLA needs to be better understood. Alerting on upstream connectivity needs refining, and a read-only OpenStreetMap.org also blocked logins to services that were not affected, because it could not save new tokens.

   View case
2. IL-0452 Azar users on one carrier's 3G IP pool in one country increasingly hit read timed out errors on a STOMP connection

   Hyperconnect2024

   Symptoms

   In January 2024 a few customer-support reports came in through Hyperconnect's internal CS channel: some Azar users in one country, called XY in the write-up, reported a problem, and the errors pointed to an internal component called A. Component A had not changed around that time, service metrics did not visibly worsen and the reports were very few, so the teams found no lead and went back to other work.

   Intermittent timeouts

   Trigger

   The team cautiously estimates that carrier Z was gradually rolling out a setting that adjusts the QoS pool depending on whether a TLS connection includes SNI, so the hourly error count kept growing.

   Root cause

   DNS or network fault

   Component

   ISP and transit networks

   Contributing factor

   Unreviewed defaultsMonitoring blind spot

   Detection

   Customer-support reports from users in country XY reached the internal CS channel in January 2024; the problem was taken up only after a report showed those reports rising steadily into March.

   Remediation

   • Shipped Android and iOS hotfixes that include SNI in the TLS connection to component A
   • Fixed the iOS bug in reporting timeout errors in the same hotfix

   Action items

   • Use mobile proxy services such as Oxylabs to test connectivity to core components from global networks automatically and collect metrics

   Lessons

   In the retrospective the SRE team named as a problem that it started looking at the issue only as CS reports piled up, at least three months after it first appeared. A global service can lose connectivity for some users because a local network changes unexpectedly, and such problems can badly hurt the experience in a major country.

   View case
3. 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
4. IL-0259 Outbound packets from Fastmail did not reach part of the internet for about 19 hours, cutting off 3-5% of customers

   Fastmail2023

   Symptoms

   From about 03:00 UTC on 30 June 2023, Fastmail and a fraction of the internet could not communicate with each other, and Fastmail first heard of it from customers through support tickets and social media. The problem lasted about 19 hours and affected an estimated 3-5% of customers as well as some email servers.

   Network unreachable

   Root cause

   Dependency failure

   Component

   ISP and transit networks

   Contributing factor

   Single point of failureMonitoring blind spot

   Detection

   Customers told Fastmail through support tickets and social media. Fastmail's own monitors in multiple locations and its staff were not on affected networks and saw nothing.

   Action items

   • Select a provider for a second transit connection directly into Fastmail's servers, via Megaport or a provider present in 365's New Jersey datacenter, so that Fastmail controls the outbound path and can route around a network with problems

   Lessons

   With a single path for outbound traffic, Fastmail could not route around a provider's network problem and could not fix it itself. Being able to choose between several outbound paths would let Fastmail get everyone back online faster.

   View case

By root cause2