Cloudflare-storing kwam door fout, trof 19 datacenters en 50 procent van verkeer

De grote storing bij Cloudflare dinsdagochtend werd veroorzaakt door een fout van de dienstverlener zelf. Het bedrijf geeft daarover een uitgebreide technische uitleg. Er werden 19 datacenters door getroffen, wat invloed had op de helft van al het verkeer van Cloudflare.

Volgens Cloudflare werd de storing veroorzaakt door een aanpassing die onderdeel was van een project om juist de veerkracht op de drukste locaties te verhogen. De 19 locaties waar de storing plaatsvond, vormen slechts 4 procent van het Cloudflare-netwerk, maar doordat het grote en drukke locaties zijn, had de storing invloed op 50 procent van het totale aantal verzoeken.

In de afgelopen 18 maanden heeft Cloudflare 19 van zijn datacenters overgezet naar een nieuwe architectuur, die het bedrijf Multi-Colo PoP noemt, ofwel MCP. Ook het Cloudflare-datacenter in Amsterdam is daar onderdeel van. Deze architectuur is opgezet als een Clos-netwerk en volgens Cloudflare heeft dat flinke verbeteringen opgeleverd wat betrouwbaarheid betreft. Ook zou het makkelijker zijn om onderhoud te plegen zonder het verkeer te verstoren. Dinsdagochtend ging dat echter mis.

Om 5.56 uur Nederlandse tijd begon Cloudflare met het uitrollen van een geplande aanpassing aan de netwerkconfiguratie. Dat verliep zonder problemen, omdat dit eerst gebeurde bij de locaties gebaseerd op de oudere architectuur. Om 8.27 uur begon de uitrol bij de 19 locaties waar MCP is toegepast. Daar ging het mis en de locaties gingen direct offline, wat grote problemen opleverde voor de bereikbaarheid van veel websites en diensten. Gebruikers kregen een 500 Internal Server Error te zien.

Verloop van Cloudflare-storing dinsdag 21 juni 2022

Om de hoofdoorzaak te verifiëren, voerde Cloudflare om 8.51 uur de eerste routerwijziging door. Acht minuten later was de oorzaak 'gevonden en begrepen'. Vervolgens begon het werk om de verandering terug te draaien. Tussen 8.58 en 9.42 uur zijn de herstelwerkzaamheden uitgevoerd. De laatste aanpassing werd wat vertraagd, doordat netwerkbeheerders elkaars aanpassingen ongedaan maakten, waardoor het probleem sporadisch weer opdook. Om 11.00 uur heeft Cloudflare het incident definitief afgesloten.

Volgens Cloudflare was de aanpassing vooraf getest en doken daarbij geen problemen op. In de toekomst wil het bedrijf aanpassingen beter testen door ook specifiek te kijken wat er gebeurt bij de locaties met de nieuwe MCP-architectuur. Het bedrijf spreekt over een 'zeer pijnlijk incident' en belooft aanpassingen door te voeren die ervoor zouden moeten zorgen dat dit niet meer kan gebeuren.

Reacties (39)

Weer een BGP issue dus. In oktober was er nog zo'n outage Kleine foutjes, grote gevolgen.

Ja BGP moet je echt met handschoenen aanpakken, want je speelt met vuur.

Lijkt niet echt een BGP fout, eerder een fout in een policy.

”BGP is a Swiss Army knife. It doesn’t even have a handle, it’s all knives.” -Dr. Tony Przygienda

Overigens is BGP van alle routing protocollen waar ik mee gewerkt heb by far het meest robuust. Het enige is, het doet precies wat je configureert. Rücksichtslos. Hartstikke top zo lang je geen fouten maakt, maar we zijn allemaal menselijk..

In dit geval ging het inderdaad om een policy fout. Had evengoed toegepast kunnen worden op een IGP zoals OSPF of IS-IS.

Ach ik vind het gewoon slecht om te zien. Ik kan goed omgaan met JUNOS en hun policy fout was gewoon duidelijk zichtbaar geweest als ze een "show" hadden gedaan voor ze in bulk hun wijziging in het hele netwerk uitdraaiden. Hun werk zelf controleren was vrij makkelijk geweest. Het is niet alsof het een protocol interactie was tussen 100+ devices waar het mis ging omdat er een flaggetje mistte in een header. Gewoon slordig zo, had beter verwacht..

Na incidenten is Clouflare altijd erg transparant; 5 uur na het oplossen van het probleem zo'n uitgebreide RCA posten is heel erg netjes.

https://blog.cloudflare.c...e-outage-on-june-21-2022/

Sowieso zijn hun blogposts erg interessant, bijvoorbeeld:
https://blog.cloudflare.c...nturylink-level-3-outage/

Het blijft eng en niet best dat 1 partij zo veel macht in handen heeft, maar tot zover lijken ze in ieder geval minder kwaadaardig dan de andere grote jongens...

Ze hebben een tijdelijke macht, wat ze leveren kan ook bij andere partijen gehaald worden.

Noem eens een paar alternatieven? Ik ken er misschien maar drie. En als Cloudflare er uitligt en bedrijven willen massaal overstappen naar de concurrent kun je er donder op zeggen dat die concurrent het helemaal niet aankan om tienduizenden klanten even snel te onboarden.

Ik denk dat Zebby best wel een punt heeft. We hebben vandaag gemerkt dat een flink deel van de internetdiensten allemaal van één bedrijf afhankelijk zijn. Je zult maar een bedrijf hebben waar een groot deel van het bedrijf remote werkt en ineens ligt alles plat, CRM, ERP, misschien wel VOIP. De schade voor de wereldeconomie loopt al snel in de tientallen miljoenen.

En dit is nog een configuratiefoutje bij een deel van hun machines. Wat als er staatshackers binnengedrongen zijn die rustig hun tijd afwachten tot er een grote oorlog uitbreekt en even de halve wereld platleggen?

[Reactie gewijzigd door Maurits van Baerle op 21 juni 2022 17:07]

Dan is dat toch een keuze die je als bedrijf hebt genomen. Je kan ook akamai nemen of een andere provider.

Dan heb je toch hetzelfde probleem? Zitten al je eieren in de Akamai-mand. Als je het echt goed wil doen zou je dan de load over drie volstrekt onafhankelijke clubs moeten verdelen. Maar goed, da's niet goedkoop.

Tegelijkertijd willen diezelfde bedrijven meestal ook nul komma nul betalen of investeren in een Plan B.

CloudFlare biedt nu in feite bizar veel gratis aan. Inderdaad is het niet handig als te veel sites afhankelijk zijn van één club, maar veel van die sites zouden anders helemáál geen verdediging hebben / nemen / willen betalen tegen ddos en dergelijke.

Vroeg of laat is Cloudflare zo onmisbaar dat ze stoppen met gratis abonnementen en er gewoon een paar euro per maand voor gaan vragen. Wat dan nog?

Dan wordt het meteen ook een verdienmodel voor anderen en komt er vanzelf meer concurrentie.

Tegelijkertijd willen diezelfde bedrijven meestal ook nul komma nul betalen of investeren in een Plan B.

Bedrijven maken een risicoanalyse. Als de kosten van het risico (als het risico optreedt) hoger is dan de mitigatiekosten wordt er geinvesteerd. Als de mitigatie duurder is dan het risico dan investeert men niet. In veel gevallen is het niet ditect een ramp als een website een keer niet bereikbaar is. Dan ga je daar geen geld aan uitgeven. Uiteindelijk is dat niet heel anders dan wat iedereen zelf doet. Vrijwel niemand heeft een tweede auto voor het geval de primaire auto het een keer niet doet. Zelfs zaken die veel minder kosten doe je niet. Ik ken niet veel mensen die een dubbele internetaansluiting hebben voor de enkele keer dat er een storing is. Net zoiets.

Klopt, maar als men je dwars wil zitten, kiest men vaak voor een cruciaal moment. Bij webwinkels is dat vaak sinterklaas/kerst. Er dan een week uit liggen kan een webwinkel maken of breken. De site-eigenaar onderschat de impact nogal eens, omdat ze er vaak nog nooit mee te maken hebben gehad.

Je ziet het ook bij andere ondernemers. Ze hebben al tien, vijftien jaar geen hagel meer op het land gehad dus stoppen met die weersverzekering. En dan hagelt een keer het hele perceel kapot.

Ik begrijp wel dat het vaak euro-voor-euro nog steeds goedkoper is om 15 jaar géén verzekering te hebben, maar dan moet je wel de klap op kunnen vangen van een jaar geen inkomsten (en wel kosten) van dat perceel. Daar wordt vaak niet mee gerekend.

Een backup internet aansluiting is vrij makkelijk te regelen via een wifi hotspot met 4G op je telefoon. Eventueel scoor je een USB dongle voor een PC of zet op een laptop Internet Connection Sharing aan.

Bijna elke medium tot grote trusted party heeft dit probleem: een bgp fout kan zo weer leiden tot het halve internet dat eruit ligt.

En het grote voordeel is dat het bedrijf er alles aan gaat doen om dat zo snel mogelijk weer online te krijgen.

Dat dus!

Straks heb je Musk die het compleet fysieke 2e internet in handen heeft.

Deze afhankelijkheid van maar 1 partij is best zorgelijk. En geen fallback hebben zoals RDW is niet best.

Zelf heel blij met Pi-hole + Unbound als Recursive DNS server. Zowel voor de privacy als de beschikbaarheid.

Dit concept in een zakelijke variant zou niet verkeerd zijn. Of denk ik nu te simpel?

Je kunt voor een CDN niet echt een fallback hebben zoals Cloudflare (of vergelijkbare diensten) zijn geimplementeerd. Feitelijk zijn die diensten een extra redundancy/fallback laag als je eigen hostingomgeving het even moeilijk heeft. Zij zitten ervoor (aan de 'edge' van het netwerk), de redundancy zit ingebouwd in het CDN zelf, maar je kunt 1 website niet door 2 CDN's laten hosten.

Nouja los van hele websites is het voor assets (javascript, css, afbeeldingen) theoretisch wel mogelijk met een hoop javascript die als middleware fungeert en de rest laadt met als fallback een andere CDN.

Jammer genoeg wordt er door browser makers liever meer tijd gespendeerd aan obscure APIs dan aan het oplossen van dit fundamentele probleem. Geef bijvoorbeeld in een HTML meta header mee welke alternatieve basis URLs gebruikt kunnen worden voor assets en laat browsers die afweging maken.

[Reactie gewijzigd door Ventieldopje op 22 juni 2022 11:01]

Mja, maar het stuk wat de html serveert blijft dan een SPOF. In het algemeen zijn dergelijke CDNs extreem betrouwbaar en is de beschikbaarheid heel hoog, ik denk dat de complexiteit om op 2 CDNs te deployen niet opweegt tegen het kleine risico op zo'n grote storing.

Je zal altijd een SPOF houden omdat er altijd wel ergens een load balancer staat

Het internet is echt point to point opgebouwd en er niet voor geschikt om vanuit de client al direct uit meerdere bronnen data te ontvangen. In zo'n geval heb je dan niet perse een load balancer nodig.

We zullen dus tegen dit soort dingen aan blijven lopen totdat de architectuur drastisch veranderd.

Waarom zou je een website niet door 2 cdn's kunnen laten hosten? Via dns is dat toch prima te regelen?

Meeste CDNs nemen ook je DNS over (zodat zij zelf snel kunnen switchen tussen IP's).

Simpele oplossingen voor complexe problemen zijn meestal geen oplossingen.

Gelukkig had deze persoon een hele leuke eerste dag bij Cloudflare

[Reactie gewijzigd door Sjeefr op 21 juni 2022 16:03]

Het reddit topic lijkt wel op een bofh episode...

"Volgens Cloudflare werd de storing veroorzaakt door een aanpassing die onderdeel was van een project om juist de veerkracht op de drukste locaties te verhogen."

Het is natuurlijk heel pedantic van mij, maar technisch gezien was de change geen onderdeel van het MCP project, maar een aanpassing van de prefix advertisement policy om de BGP advertisements te verrijken. En enkel in het geval van de MCP locaties had dit echter een negatieve bijkomstige impact, waardoor de interne prefixes gedropt werden.

Zou de RDW ook gebruik maken van Cloudflare? die was ook al een langere tijd niet bereikbaar.

In ieder geval de website van NS wel, ik geloof dat rdw ook wel minstens een deel van cloudflare's services gebruikt

RDW gebruikt ook Cloudflare inderdaad. Een deel van onze klanten had vandaag inderdaad problemen met het doen van bevragingen bij de RDW. In de loop van de ochtend werkte alles weer.

Ook Topdesk (de SaaS-hosted versie althans) had bij onze klanten last van deze storing. Toonde alleen een Error 500.

Vorig jaar een paar maanden veel problemen gehad met Cloudflare. Uiteindelijk ging het probleem ‘spontaan’ over. Het lag wel degelijk aan CloudFlare want zodra we dat uitzetten, was het probleem meteen verholpen.

Je krijgt uiteraard geen hulp bij een gratis account maar ook als je dan een betaald abonnement neemt, wordt je dagenlang genegeerd.

Toch vind ik dat niet heel raar want voor die bedragen kun je niet veel verwachten en ze hebben wel wat anders aan hun hoofd dan een webwinkeltje.

Toch vind ik dat niet heel raar want voor die bedragen kun je niet veel verwachten en ze hebben wel wat anders aan hun hoofd dan een webwinkeltje.

Zo moet je niet denken. Als jij dat probleem hebt, zul je vast de enige niet zijn.

Het blijft mij toch nog altijd verbazen dat zo'n fout meteen zo'n groot effect heeft en 19 datacenters plat legt en uiteindelijk 50% van alle dataverkeer. Je zou toch zeggen dat elk datacenter goed afgeschermd is van het andere datacenter in geval het fout gaat. Kan mij nog iets erbij voorstellen als het om een of ander groot koppelstation zou gaan.

Volgens mij ging het mis doordat die 19 op een andere manier waren 'ingesteld' dan de rest. Daardoor ging het mis met het doorvoeren van de wijziging.

Het wijzigen ging goed op de servers die nog op de oorspronkelijke manier ingesteld waren. En toen de nieuwe instelling bijgewerkt werd, ging het mis.

Ik verwoord het even erg simpel en niet met de juiste termen. Om duidelijker te maken dat het niet kwam doordat ze aan elkaar verbonden waren ofzo. Maar doordat de 19 los van elkaar anders ingesteld waren.

Maar dan nog, dit was ook van invloed op 50% van het totale dataverkeer van Cloudflare. Dus dat houd in dat die 19 datacenters gekoppeld waren aan andere servers lijkt mij.

Ze rollen de change uit in alle 19 datacenters tegelijk. Dus die gaan allemaal tegelijk de fout in.