image

Storing Cloudflare veroorzaakt door aanpassing netwerkconfiguratie

dinsdag 21 juni 2022, 15:38 door Redactie, 7 reacties

Een aanpassing in de netwerkconfiguratie was verantwoordelijk voor de omvangrijke storing bij Cloudflare vandaag waardoor allerlei populaire websites en diensten meer dan een uur offline waren, zo laat het internetbedrijf zelf weten. De aanpassing was onderdeel van een project om de drukste locaties van het bedrijf, dat ddos-bescherming biedt en als content delivery network fungeert, veerkrachtiger te maken. Het ging in totaal om datacenters in negentien locaties die door de storing werden getroffen. In totaal duurde de storing ruim een uur.

Om toegankelijk op internet te zijn maken netwerken zoals Cloudflare gebruik van het BGP-protocol. Het border gateway protocol (BGP) wordt gebruikt om verkeer tussen autonomous systems (AS) te routeren en essentieel is voor de werking van het internet. Als onderdeel van dit protocol stellen operators policies op die bepalen welke prefixes, een verzameling aangrenzende ip-adressen, aan andere operators worden aangekondigd of van hen worden geaccepteerd.

Deze policies zorgen ervoor dat een prefix wordt geadverteerd aan andere operators of dat dit niet het geval is. Een aanpassing in een policy kan ervoor zorgen dat een eerder geadverteerde prefix wordt ingetrokken, waardoor die ip-adressen niet langer meer bereikbaar zijn vanaf het internet. Vandaag voerde Cloudflare een aanpassing aan verschillende policies door, waardoor een verzameling van belangrijke prefixes werd ingetrokken.

Het intrekken zorgde ervoor dat de negentien datacenters offline gingen. Doordat de prefixes werden ingetrokken was het lastig voor Cloudflare-engineers om de betreffende locaties te bereiken en de aanpassing ongedaan te maken. Daarbij werden alleen de datacenters geraakt waar Cloudflare aan een" veerkrachtigere en flexibelere architectuur" werkt. Dit zijn echter ook de datacenters die het grootste deel van het Cloudflare-verkeer verwerken.

Het internetbedrijf zegt voor deze gevallen over back-upprocedures te beschikken en kon zo alsnog de betreffende locaties benaderen. Tijdens de hersteloperatie bleek dat verschillende netwerk-engineers elkaars aanpassingen ongedaan maakten, waardoor het probleem zich weer sporadisch voordeed. Na een uur en een kwartier waren alle datacenters weer online. Verder maakt Cloudflare excuses en stelt dat de storing grote gevolgen had en er op verschillende vlakken verbeteringen mogelijk zijn om herhaling te voorkomen.

Reacties (7)
21-06-2022, 15:40 door Anoniem
Werkte deze engineers toevallig voorheen voor facebook? ;)
21-06-2022, 15:47 door Anoniem
Ja die kennen we... dat had Facebook ook een paar maanden geleden.
Die hebben daar nog een heel verhaal over gepubliceerd maar van elkaars fouten leren doet niemand.
21-06-2022, 20:05 door Anoniem
Door Anoniem: Ja die kennen we... dat had Facebook ook een paar maanden geleden.
Die hebben daar nog een heel verhaal over gepubliceerd maar van elkaars fouten leren doet niemand.

Omdat Facebook een outage had door een routing error en Cloudflare dat nu ook heeft, is je conclusie dat “niemand van elkaars fouten leert”. Come on now… accepteer dat fouten onvermijdelijk zijn in een dynamisch en competitive bedrijf. Het is knap om te zien hoe ze met deze fouten handelen en dit communiceren. Het is altijd de comment section die weet hoe je zo een fout had kunnen voorkomen, de beste stuurlui staan aan wal.
22-06-2022, 08:10 door Anoniem
Zo zie je maar weer dat je niet afhankelijk wilt zijn van een bedrijf voor je DNS traffic. Daarnaast staat Cloudflare niet bekend om de goede privacy bescherming. Ik zie geen reden om gebruik te moeten maken van diensten als Cloudflare.
22-06-2022, 10:31 door Anoniem
Door Anoniem:
Door Anoniem: Ja die kennen we... dat had Facebook ook een paar maanden geleden.
Die hebben daar nog een heel verhaal over gepubliceerd maar van elkaars fouten leren doet niemand.

Omdat Facebook een outage had door een routing error en Cloudflare dat nu ook heeft, is je conclusie dat “niemand van elkaars fouten leert”. Come on now… accepteer dat fouten onvermijdelijk zijn in een dynamisch en competitive bedrijf.

Fouten kunnen voorkomen, maar het zinnetje "Doordat de prefixes werden ingetrokken was het lastig voor Cloudflare-engineers om de betreffende locaties te bereiken en de aanpassing ongedaan te maken" geeft duidelijk aan dat er niet van andermans fouten geleerd is!
Immers daar had iemand kunnen bedenken "het is wel handig om een apart management netwerk te hebben wat niet gerelateerd is aan onze normale BGP advertisements". En dat hebben ze kennelijk (nog) niet geinstalleerd.
Dit was ook bij de Facebook case het probleem, en eerlijk gezegd verbaasde het me toen ook al dat er niet een of ander overlay netwerk was voor dit soort router beheer. Al was het maar om management interfaces van het internet af te houden.
22-06-2022, 10:53 door Anoniem
Door Anoniem: Zo zie je maar weer dat je niet afhankelijk wilt zijn van een bedrijf voor je DNS traffic. Daarnaast staat Cloudflare niet bekend om de goede privacy bescherming. Ik zie geen reden om gebruik te moeten maken van diensten als Cloudflare.

Ik denk dat heel weinig diensten - inclusief je eigen server - de uptime van Cloudflare halen .
Je kent Cloudflare blijkbaar alleen als open DNS ?

Als je een dienst runt waar DDoS een risico is Cloudflare één van de twee of drie keuzes om heel goed DDoS bestendig te worden. Dat zelf doen is voor vrijwel niemand een opptie.
23-06-2022, 18:31 door Anoniem
Door Anoniem:
Door Anoniem:
Door Anoniem: Ja die kennen we... dat had Facebook ook een paar maanden geleden.
Die hebben daar nog een heel verhaal over gepubliceerd maar van elkaars fouten leren doet niemand.

Omdat Facebook een outage had door een routing error en Cloudflare dat nu ook heeft, is je conclusie dat “niemand van elkaars fouten leert”. Come on now… accepteer dat fouten onvermijdelijk zijn in een dynamisch en competitive bedrijf.

Fouten kunnen voorkomen, maar het zinnetje "Doordat de prefixes werden ingetrokken was het lastig voor Cloudflare-engineers om de betreffende locaties te bereiken en de aanpassing ongedaan te maken" geeft duidelijk aan dat er niet van andermans fouten geleerd is!
Immers daar had iemand kunnen bedenken "het is wel handig om een apart management netwerk te hebben wat niet gerelateerd is aan onze normale BGP advertisements". En dat hebben ze kennelijk (nog) niet geinstalleerd.

Je wist zo zeker dat je gelijk had dat een alinea verder lezen niet meer nodig was, is het niet ?

Ik zal 'm maar even citeren , zodat je ziet hoe voorbarig je was :


Het internetbedrijf zegt voor deze gevallen over back-upprocedures te beschikken en kon zo alsnog de betreffende locaties benaderen. Tijdens de hersteloperatie bleek dat verschillende netwerk-engineers elkaars aanpassingen ongedaan maakten, waardoor het probleem zich weer sporadisch voordeed.

Dus ja - ze hadden wel degelijk een out-of-band optie.
Daarna zijn blijkbaar een paar separate NOCs allemaal op de "major outage" gedoken, en hebben deels elkaar in de weg gezeten.
(Je gokt dat de normale intra--bedrijfs-communicatie ook verstoord was, en iedereen even te druk was met zoeken om te coordineren).


Dit was ook bij de Facebook case het probleem, en eerlijk gezegd verbaasde het me toen ook al dat er niet een of ander overlay netwerk was voor dit soort router beheer. Al was het maar om management interfaces van het internet af te houden.

Hint : een overlay netwerk zit op een underlay drager. En als _die_ verstoord is heb je dus een fors probleem.

Gewoon - beter lezen. Ze hadden wat nodig was om de storing op te lossen.
Als je onverwacht een heel erg dikke storing voor je kiezen krijgt kan het - ook voor erg goede engineers - even duren om dooir te krijgen wat de werkelijke oorzaak is en welke problemen en alarmen (slechts) gevolg zijn.
Daarna zoeken naar hoe de out-of-band access ook al weer ging, oplossen , en deels in de weg gezeten worden door andere engineers die ook bezig zijn. (natuurlijk heb je niet slechts één noc locatie ).
Dat uur is niet zo heel vreemd.
Reageren
Ondersteunde bbcodes
Bold: [b]bold text[/b]
Italic: [i]italic text[/i]
Underline: [u]underlined text[/u]
Quote: [quote]quoted text[/quote]
URL: [url]https://www.security.nl[/url]
Config: [config]config text[/config]
Code: [code]code text[/code]

Je bent niet en reageert "Anoniem". Dit betekent dat Security.NL geen accountgegevens (e-mailadres en alias) opslaat voor deze reactie. Je reactie wordt niet direct geplaatst maar eerst gemodereerd. Als je nog geen account hebt kun je hier direct een account aanmaken. Wanneer je Anoniem reageert moet je altijd een captchacode opgeven.