Hoster OVH heeft last van storing veroorzaakt door netwerkconfiguratie na update

De Franse hoster OVHcloud is woensdagochtend getroffen door een storing waardoor het hele OVH-netwerk onbereikbaar was. De dienst wilde zijn infrastructuur upgraden om ddos-aanvallen beter tegen te kunnen gaan. Inmiddels wordt het niet-Amerikaanse deel weer online gebracht.

De hoster begon op woensdagochtend 09.00 uur met het onderhoud; kort daarna meldden gebruikers op onder meer Allestoringen dat er een storing bij de dienst is. Op Twitter geeft OVH-oprichter en -voorzitter Octave Klaba aan dat er inderdaad een storing is, veroorzaakt door een slechte configuratie bij een router.

Deze verkeerde configuratie werd door een menselijke fout veroorzaakt en heeft voor problemen gezorgd bij de hele backbone van de hoster. Klaba zegt dat zijn bedrijf het verstoorde netwerk wil isoleren en de configuratie wil herstellen. Wanneer de storing verholpen moet zijn, is niet duidelijk.

De wereldwijde storing begon volgens OVH om 09.20 uur Nederlandse tijd bij het Amerikaanse netwerk van het bedrijf. Om 10.22 uur zouden diensten geleidelijk aan weer online komen, nadat het Amerikaanse net geïsoleerd was van de rest van het OVH-netwerk.

Met de update wilde het bedrijf extra infrastructuur toevoegen aan het Amerikaanse deel van het netwerk, om zo ddos-aanvallen beter te kunnen afslaan. Deze aanvallen zouden 'in de afgelopen dagen' in intensiteit zijn toegenomen.

Reacties (73)

[Oon]

Is wel trendy ineens om je netwerkconfiguratie kapot te maken

Hoeveel van hun infrastructuur raakt dit? En alleen OVH of ook Kimsufi en SyS?

[NielsFL]

Ik ken de oorzaak van deze storing natuurlijk niet, maar de trend die ik zelf vooral zie is dat alles een Web GUI krijgt en elke noob met 2 maanden muisklikervaring vervolgens denkt dat hij dat systeem wel eventjes kan beheren.

Wijzigingen waar voorheen weken aan planning, discussie met collega's en uitrol op testsystemen aan voorafgingen worden nu even snel bij elkaar geklikt. Kan geen kwaad, want desnoods klik je het weer terug zoals het was, toch? Ja, totdat dat dus niet lukt.

[MazDaMan1970]

Beetje kort door de bocht; je kunt nog zoveel testen in een test-omgeving, maar vaak is de praktijk net iets anders, zeker in dit soort complexe omgevingen.
Helaas sluipt een menselijke fout, zoals een typo er snel in, wat voor dit soort grote omgevingen al snel catastrofaal kan zijn.

[Xander2]

Een typo is juist eenvoudig te voorkomen met een stappenplan waar je alleen hoeft te copy-pasten.

[!GN!T!ON]

Copy pasten? Dat is wel echt ouderwets zeg. Noem dan dingen als Terraform, Ansible, Chef, Puppet.

[Xander2]

Met ouderwets is niets mis; uitdenken en implementeren van complexe stukken eerst op papier werkt voor mij ook beter dan achter een computer ongeacht welke tool/compiler ik daarna gebruik.

[Ryen]

Copy/paste gaat overigens ook wel eens fout. Meerdere keren meegemaakt dat dat mis ging omdat er een extra spatie aan het eind wel/niet mee ge-paste werd.
Zoveel mogelijk automatiseren! Wel goed testen, natuurlijk.

[Anoniem: 1322]

Ik heb eens een keer een server crash veroorzaakt door een copy/paste van een powershell commando. Daar was een 0 aan het einde weggevallen (niet goed geselecteerd). Aan de andere kant ook wel eens een loadbalancer onderuit gebracht omdat de interface verkeerd vertaalt was (Chinese -> English ftw).

Na een tijd ben je er wel klaar mee en dan dan komt iedereen tot de conclusie dat automatiseren de beste oplossing is. Natuurlijk kom je ook je ook nog wel eens problemen tegen maar die los je dan direct voor altijd op.

[!GN!T!ON]

maar je aggeert op foutgevoeligheid, en config gaan copypasten op machines is maar zeer zeer marginaal minder foutgevoelig dan gewoon typen en het kost ook nog een berg meer tijd dan 1x goed je deployscript uitwerken (wat dus in jou voorbeeld eigenlijk je stappenplan is). Ik zou stellen dat in dit voorbeeld, ja ouderwets is zeker wel wat mis.

Als ik bij een hoster zit en ik kom erachter dat ze nog hun productiemachines in SSHen en daarop in tekstbestanden zitten te editen en copy-pasten en dan is dat voor mij reden om opzoek te gaan naar een professionelere hoster.

[Reactie gewijzigd door !GN!T!ON op 22 juli 2024 13:49]

[Raverty]

Ik gebruik Ansible regelmatig en bij ons ontkomen we er niet aan om dingen soms toch nog handmatig te doen omdat dan net dat stukje nog niet geautomatiseerd is. Wij zorgen we dan wel voor dat we het gaan automatiseren, maar in sommige gevallen betekent dat een hoop rework en doen we het de eerste keer toch handmatig.

[!GN!T!ON]

Dat vind ik toch al een andere situatie, aangezien als ik je goed begrijp daar de modus operandus is 'automatiseren', en mocht je bij wijze van noodzaak dan een edit moeten dan, dat dit in het process wel word opgenomen in (in dit geval dan) ansible script voor de volgende keer.

Zelf vind ik het meest prettig om op een testomgeving eerst handmatig een config te doen (nadat architectuur, opzet op papier is uitgewerkt), om deze vervolgens in terraform / ansible uit te werken. Als ik daarna via die scripts een acceptatieomgeving kan uitrollen die werkt zoals bedoeld, dan kan het naar productie. Ik probeer ook zoveel mogelijk immutable infrastructure toe te passen, dan heb je ook geen last van config drift over tijd.

[Reactie gewijzigd door !GN!T!ON op 22 juli 2024 13:49]

[tweazer]

Haha, ik kan mij nog een foutje herinneren eind jaren 90. In de ene cisco ios release moest een bepaald type poort snelheid in Mbits worden opgegeven in de te updaten versie in bits. Na die ios update ging al het verkeer (en omdat er geen gescheiden management verbindingen waren dus ook het beheer verkeer) met een factor 1E6 langzamer. De betrokken operator had toen lange tijd geprobeerd die snelheid aan te passen, een monteur werd ook op pad gestuurd. Ik heb nooit gehoord wie het gewonnen had, wel dat die partij flinks is afgefikt, altijd software testen, ook al komt het van een grote betrouwbare leverancier...

[Anoniem: 420148]

Beetje harde generalisering natuurlijk. Heb jij bij Akamai/OVH/een FAANG bedrijf gewerkt zodat je kunt zeggen dat ze daar een stel juniors via een grote rode knop GUI upgrades laten doen?

[tweazer]

juniors ... rode knop

Hoeveel van die verhalen wil je horen ? IBM als grote partij blijkt als je low level device problemen hebt net superafhankelijk te zijn van die ene developer in india. Zijn collega daar neemt het even over, net een week in dienst... Totale SNAFU
Een standaard maar wel grote HP raid storage oplossing in storing wordt door een monteur van een groot bedrijf opgepakt. Als eerste haalt deze begaafde persoon de raid config weg, "want die kun je opnieuw configureren".
Een groot datacenter wordt 's-nachts door uitzendkrachten van een grote leverancier bemand, die .. ah well
Je noemt Akamai, daar kan ik nog een zwarte streep van pakweg 1.5 meter op de muur in het datacenter voor de geest halen, 48 volt kabels waren geplaatst. Terwijl deze onder spanning stonden .....

Iedereen moet z'n dingetje leren, maar mijn ervaringen bij partijen uit India is dat ze daar een erg 'steep learning curve' hebben, vooral vanaf 0 beginnen...

[Reactie gewijzigd door tweazer op 22 juli 2024 13:49]

[Ventieldopje]

OVH, Kim en SyS, kan ik je melden

[Marve79]

Kimsufi en sys gaat over exact hetzelfde netwerk.

[ToolkiT]

In de twitter replies staan wel grappige reacties:

"OVH CEO: We need to become a global brand just like Facebook
Infra Team: Hold my switches"

[MichaelBelgium]

Staat op hun statuspage wat het raakt: http://travaux.ovh.net/?do=details&id=53798&edit=yep

Spoiler: Entire OVH Network.

[Viper1995]

Ik begin het idee te krijgen dat OVH een beetje te snel aan het groeien is, dit soort foutjes kan iedereen overkomen. Ik was zelf al vertrokken na de brand in het datacentrum richting DigitalOcean (overgestapt van VPS'en naar k8s) omdat eigenlijk het laatste druppeltje was.
Meermaals mee gemaakt dat mijn VPS offline ging, was altijd maar even kort maar toch waren de verstoringen er wel. En als je dan in het beheer paneel wilde kijken wat de status was van de VPS kreeg je vaak helaas meer foutmeldingen terug dan dat je daadwerkelijk iets nuttigs kreeg. Wat helemaal frusterend werkte was dat er soms ook opeens meldingen in het Frans uitgerold kwamen.

Vond het zelf erg jammer, want toen ik ooit begon bij OVH was het relatief goedkoop maar wel gewoon goed bereikbaar en voor wat ik er mee deed meer dan voldoende.

[Reactie gewijzigd door Viper1995 op 22 juli 2024 13:49]

[Marve79]

Ik zit puur bij OVH vanwege de DDoS bescherming. Ik krijg zoveel DDoS aanvallen op m'n game servers dat hun bescherming de enige is die werkt van een dozijn providers die ik al heb geprobeerd. Bijv bij Voxility was de bescherming zo agressief dat heel je game gewoon down ging.

Maar anders was ik ook al weg, support is niet-bestaand bij OVH. Maar de prijzen zijn wel ok en de DDoS bescherming is ook hun USP.

Of het met te snel groeien heeft te maken weet ik niet maar ze zijn natuurlijk wel goedkoop en ze gebruiken veel in-house oplossingen. Voor zover ik weet is die DDoS oplossing van hun (VAC) ook helemaal in-house opgezet.

Ik zou OVH dan ook niet aanraden voor belangrijke productiesystemen, maar bijv Hetzner ook niet. Maar als je kunt veroorloven om er af en toe uit te liggen, soms meerdere dagen dan is OVH een prima keuze. Anders ga je naar AWS/Azure oid.

[TumTum]

Ik ben het deels met je eens. De support van OVH is matig en de DDoS protectie (Game L7) is erg goed.

Je laatste punt niet. Hetzner is perfect voor productiesystemen. De support afdeling is zeer goed met kundig personeel. Paar maanden terug is mijn defecte HDD binnen 5 minuten vervangen! Totaal niet vergelijkbaar met de support afdeling van OVH. Je moet dan wel enterprise servers afnemen bij Hetzner voor zakelijk gebruik.

[Reactie gewijzigd door TumTum op 22 juli 2024 13:49]

[DarkForce]

Vond het zelf erg jammer, want toen ik ooit begon bij OVH was het relatief goedkoop maar wel gewoon goed bereikbaar en voor wat ik er mee deed meer dan voldoende.

Ja en nee... zelf klant geworden van OVH eind 2002 begin 2003. Ja ze waren spotgoedkoop, de enige concurrenten die ze toen hadden waren Rackservers in de VS en TwistSpace/Compuserve in Nederland.

Nadeel met OVH in het begin - en dat heeft in principe iedere hosting- / serverboer. De peering en transit verbindingen zijn in het begin redelijk ruk. Zo waren verbindingen naar Chello, @home om te janken met vaak allerlei willekeurige routes. Pas medio 2010/2011 toen Erwin en Paul bij OVH kwamen werken (nu inmiddels ook al weer enige tijd weg) is geïnventariseerd hoe de verbindingen in Nederland waren en heeft OVH betere verbindingen weten te realiseren.

Naarmate OVH is gaan groeien, steeds meer dochtermerken (SoYouStart, Kimsufi) is begonnen en allerlei zaken is gaan verwijderen (propositie, verwijderen van extra IP's bij Kimsufi etc.) is de kwaliteit hard achteruit gegaan. Maar goed, feit is en blijft wel, qua servers is er voor dergelijke bedragen nauwelijks een alternatief te vinden en qua VPS's geldt dit eigenlijk ook als je de uptime even niet meeneemt.

[Oon]

Ik heb een tijd een server gehad bij SoYouStart (ook OVH) en dat was eigenlijk super, heel weinig downtime en alles was lekker simpel. Ook zeer goedkoop door gebrek aan support, ware het niet dat je ivm belasting en inkoop in het buitenland uiteindelijk al je voordeel weer snel kwijt bent.

Daarna OVH zelf een VPS gehad voor een tijdje en dat vond ik helemaal niks, dus ben snel verhuisd naar TransIP. Ook niet perfect, maar wel een stuk duidelijker en gewoon in Nederland. Daarnaast ook wat DO droplets draaien, maar daarvan vind ik de uptime niet goed genoeg om op één enkele droplet (zonder failover) een productie-omgeving te draaien, dus kritieke dingen die ik niet over meerdere hosts kan spreiden draai ik bij TransIP, met DNS failover naar een andere partij.

[ISaFeeliN]

Ik denk dat je bij dit soort toko's gewoon een klein beetje geluk nodig hebt om een zorgeloze klant te zijn. Soms zit het mee, soms zit het tegen. Wat ze verder bieden voor het geld is eigenlijk bepaald niet mis, vind ik.

[walkstyle]

druppeltje? bedoel je niet Droplet

Ik zelf zit liever bij een cloud provider (DO, Vultr,etc) dan een dedicated server provider (Hetzner, Leaseweb, OVH) voor mijn gevoel gewoon stabieler en betere service/kwaliteit.

[Anoniem: 150119]

Support van Hetzner vind ik nochthans wel enorm goed én snel. OVH ... das iets anders ... ALS ze al antwoorden is het naast de kwestie of is het niet hun probleem.

[devices]

Ik heb bij DO en Hetzner gezeten, maar zie niet in wat er daadwerkelijk anders is tussen de twee cloud oplossingen. Hetzner biedt al lang niet alleen dedicated servers aan, maar ook cloud. Je krijgt naar mijns inziens praktisch hetzelfde.

[BHQ]

Alle partijen die je noemt leveren ook VM's.

[walkstyle]

Ja maar vaak op de zelfde infrastructuur als hun dedicated servers, het is ook meer een gevoel voor mij.
Maar Digital Ocean is echt vanaf het begin zo gebouwd.

[CaineTanathos]

groei pijnen hebben ze inderdaad wel, en is niet klant service gericht zoals bij amazon, azure, zelfs digital ocean inderdaad.

maar dit soort 'foutje' overkomt de besten ... of zijn we facebook al vergeten of amazon of azure ..

[jordynegen11]

OVH deed rond 09:00 wat onderhoud in the US en toen ging heel het OVH netwerk wereldwijd plat....
"No impact expected" noemen ze dat dan haha. Ja kan er nu weer om lachen maar dat is niet fijn je ochtend beginnen. https://twitter.com/ovh_s.../1448185498812485633?s=20

Heb zelf 70 dedicated servers bij OVH op 8 locaties en alles lag/ligt plat. Momenteel is het meeste weer up maar gebruikers in sommige landen kunnen hun diensten nog steeds niet bereiken.

Ook wel fijn trouwens dat hun oprichter een dergelijk probleem in het Frans vermeld op zijn twitter terwijl het merendeel van de klanten geen Frans spreekt

[Reactie gewijzigd door jordynegen11 op 22 juli 2024 13:49]

[WhatsappHack]

Het is typisch iets Frans, chauvinistisch gedoe. Zo laten ze hun controle paneel ook defaulten naar Frans. En ze zetten ook geen cookie dat dit Engels voor jou moet zijn ofzo, neuh… Elke keer dat je wil inloggen moet je handmatig eerst de taal veranderen. Strontvervelend.

[mocem]

Voor mij een reden om geen klant te worden. Op 1 of andere manier is iets wat uit Frankrijk komt het altijd net niet.

[Ryen]

De wijn, kaas en de foie gras smaken prima

[Jonathan-458]

Het is inderdaad wel iets waar je rekening mee moet houden op het moment als je voor OVH kiest en support nodig hebt.

[mocem]

Dat is trouwens bij alle unmanaged hosting providers. De mensen met verstand van IT gaan wat leukers doen. Uit eigen ervaring kan ik zeggen dat de klanten zonder verstand van IT het grootste probleem zijn. Die generen heel veel werk bij support zodat ze niet de tijd nemen/krijgen voor valide support requests.

[Jonathan-458]

Klopt helemaal

[eborn]

Herkenbaar. Ik zit regelmatig in meetings met een Frans team waar een developer erg beperkt Engels spreekt. Daar zit dan een projectleider bij die de communicatie heen en weer vertaald als het te complex wordt. Dat maakt de technische communicatie meestal niet eenvoudiger.

[ArmEagle]

Daar zijn userscriptjes toch ideaal voor? Gewoon controle over de tools, in plaats van tools controle over jezelf.

[GertMenkel]

Van alle problemen die ik met een bedrijf kan hebben, is dit wel een van de minste eigenlijk. Het zou fijn zijn als bedrijven eindelijk die taalheader die we sinds jaar en dag meesturen gebruiken in plaats van cookies, maar zo'n enorme ramp is dit nu ook weer niet.

[jannick63]

Ik kan er helemaal over mee praten, bij mij op het werk hebben wij ook een paar 'verplichte' Franse pakketten. Alles is altijd Frans, FAQ, Helpdesk portalen noem maar op.

En meestal ook niet uit het meest fijne hout gesneden

[tweazer]

Chrome default de franse taal laten vertalen is ook een oplossing ?

[Blokker_1999]

Het is niet omdat men geen downtime verwacht, dat er garanties zijn dat er geen downtime zal zijn natuurlijk. Daarnaast, als je doorklikt op de link in de tweet dan merk je dat deze change geannuleerd is. Kan dus zijn dat dat niet eens gerelateerd is aan wat er hier gebeurd is.

[jordynegen11]

In een latere update is bevestigd dat het kwam door onderhoud in de US, dat weer overeenkomt met deze tweet.

Ja tuurlijk snap ik dat er altijd een kleine kans is op problemen maar het wereldwijde netwerk plat op alle locaties door een configuratie wijziging (ddos protectie update) in de US is toch wel slordig...

[Reactie gewijzigd door jordynegen11 op 22 juli 2024 13:49]

[SebasFM]

Ik zie dat mijn slimme energiemeter welgeteld tussen 9:20 en 9:33 niet naar Grafana heeft kunnen loggen, dus de storing duurde voor mij slechts 13 minuten.

[DarkForce]

Grappig was wel dat de storing alleen IPv4 betrof en diensten/servers gewoon bereikbaar bleven via IPv6. De impact betrof dus alleen het IPv4 traffic .

[xiphoid]

Octave Klaba (@olesovhcom)
d2> .. route-map ipv
d2> 4

le copier/coller sur 2 lignes au lieu d’1 ..

Twitter•Today at 11:01 AM

https://twitter.com/olesovhcom/status/1448212224296820738

De tweet is hierna snel verdwenen.

[Neus]

Heb een zooi VPSen en een dedicated server draaien bij OVH. En een dedicated by SyS. Alles lag plat behalve de dedicated van OVH - de virtuele Sophos UTM firewall was prima beschikbaar maar de ESX server zelf en 2 publieke VM's achter de firewall niet. Raar. Maar was inderdaad wel weer ff met de billen knijpen vanmorgen; dacht meteen aan de brand van vorige keer.

[mr94]

Hopelijk een keer niet iets met DNS

[ISaFeeliN]

Nou liever iets met DNS dan met BGP..

[vtsalf]

Met een beetje pech is een foute DNS pas na 48 uur (maximale update tijd DNS record) gefixed. BGP gaat gelukkig iets sneller dan dat. Ik zou dan toch voor BGP kiezen uit de twee kwaden.

[ISaFeeliN]

Geen hond gaat DNS records op 48u zetten natuurlijk. Daarnaast kun je zonder DNS nog bij veel dingen komen, zonder BGP ben je gewoon weg van het internet.

[Puff_Uncle]

is opgelost!

[theobril]

Beetje off-topic-vraag, maar wij gebruiken een sofwarepakket wat door het betreffende bedrijf ondermeer bij OHV is gehost. Gewoonlijk sturen ze bij onderhoud vantevoren een berichtje "we zijn van dan tot dan uit de lucht". Nu geen waarschuwing vooraf, enkel een maintenance-melding vanochtend, terwijl ik hier lees dat het niet echt maintenance is, of dan mislukte maintenance. Dat heet toch jokken, of is dat in gevallen als deze gebruikelijk, zo flexibel met de werkelijkheid omgaan? edit typo

[Reactie gewijzigd door theobril op 22 juli 2024 13:49]

[demianmonteverd]

Of... men heeft van te voren ingeschat dat de wijziging geen gevolgen zou moeten hebben voor jou en helaas ging er iets mis dat men niet van te voren heeft bedacht.

Dit kan best gebeuren, AWS, Google en recent nog Facebook/Instagram, ze hebben allemaal issues gehad die ze niet hadden voorzien.

[jordynegen11]

Bij mij nog niet helemaal hoor. Australië en US east hebben nog hoge packetloss en gebruikers in Singapore (en omstreken) kunnen nog steeds geen verbinding maken. Kan nog wel ff doorgaan

[Reactie gewijzigd door jordynegen11 op 22 juli 2024 13:49]

[Puff_Uncle]

oh bij mij op het werk wel met al onze systemen

[jordynegen11]

Ja maar dat betekend dus nog niet dat het voor iedereen al is opgelost

[Puff_Uncle]

oke oke

[Vorkie]

De Facebook netwerkbeheerder had een nieuwe baan gevonden?

Totaal OT, ik weet het.

[Marve79]

Te makkelijk