Microsoft: grote storing van deze week kwam door patch voor Wide Area Network

De grote, wereldwijde Microsoft-storing van eerder deze week werd veroorzaakt door een patch voor het Wide Area Network. Daardoor konden routers geen packets meer forwarden. Daardoor werkte ook de tooling niet meer om het WAN te monitoren, schrijft Microsoft in een statusupdate.

Microsoft schrijft in een preliminary post incident-review in het Azure-statusdashboard meer informatie over een grote storing die eerder deze week plaatsvond. Tijdens die storing lag wereldwijd een groot deel van Microsoft-diensten, waaronder Office 365, Outlook en Teams plat en waren diensten die op Azure waren gehost slecht bereikbaar. De storing duurde volgens Microsoft in totaal 5 uur en 40 minuten, al waren veel diensten na twee uur al deels bereikbaar.

In een eerdere statusupdate zei Microsoft al dat er een probleem was ontstaan nadat een foutieve Wide Area Network-patch was doorgevoerd, maar details ontbraken nog. Nu geeft het bedrijf die details wel. Microsoft probeerde een IP-adres van een WAN-router aan te passen, maar gaf daarbij per ongeluk een commando aan de router waardoor er berichten naar alle routers in dat netwerk werden gestuurd. Daardoor pasten die routers hun forwarding tables aan. In de tijd dat dat gebeurde, werden normale packets niet of nauwelijks meer geforward. Dat leidde ertoe dat de routers in golven van een half uur slechte verbindingen hadden en weinig verkeer doorlieten.

Volgens Microsoft was de betreffende opdracht niet goed getest op de specifieke router waar die werd uitgevoerd. Het bedrijf erkent dat de opdracht verschillend kan reageren op specifieke hardware en dat het betreffende kwaliteitscontroleproces niet goed was doorlopen. Een extra probleem is dat door de storing ook de systemen niet meer werkten waarmee de andere systemen konden worden gemonitord.

Microsoft zegt dat het in de toekomst geen 'opdrachten met een hoge impact' meer direct op apparaten kan uitvoeren. Dat proces is inmiddels ingeregeld. Daarnaast wil het bedrijf vanaf februari zorgen dat alle opdrachtcommando's aan veiligheidsrichtlijnen voldoen.

Reacties (122)

Het valt me wel op dat veel mensen hier het behoorlijk beter weten hoe je dit "simpel" kan voorkomen met wat backups hier en wat controles daar. Wat mensen hier vergeten is dat er werkelijk niemand is die dit zelf nog nooit heeft meegemaakt in hun eigen infra, die ze zelf hebben neergezet. Natuurlijk probeer je alles zo goed mogelijk neer te zetten, maar bij dergelijke complexe systemen en netwerk topologien kan er altijd iets mis gaan. Je leert van de fout en je zorgt ervoor dat het nooit meer gebeurd.

Daarnaast heb je natuurlijk een sla. Voor zover ik weet hebben ze de sla (nog) niet geschonden, maar dat maakt het niet minder vervelend.

Helemaal eens. Daarnaast kan het merendeel niet goed lezen en begrijpt niet wat er daadwerkelijk mis ging en wat precies de impact was.

Het is echt niet zo dat heel Azure en M365 een paar uur helemaal plat lagen.

De netwerkproblemen waren na 2,5 uur helemaal opgelost, het grootste gedeelte al binnen 2 uur. De propagatie van routes en DNS changes wereldwijd duurt nou eenmaal even. Voor de slechte lezers: dat betekent dus niet dat alles 2 uur plat lag.

Verder hebben alleen klanten die pech hadden nog wat langer problemen ondervonden dan die 2,5 uur omdat een klein aantal monitoring systemen handmatig herstart moesten worden.

Zijn er geen failsafe servers of iets dergelijks? als er zo'n grote storing optreed dat het verkeer dan automatisch richting een andere server wordt geleid. Het is toch absurd dat het 5 uur en 40 minuten heeft geduurd..

Er zit reeds enorm veel redundantie in heel het Microsoft platform. Haal je 1 van hun datacentra offline ga je er zelfs niet al te veel van merken maar je kan nooit alles zo uitvoeren dat het onverwoestbaar is.

In dit geval is er een foutief commando gegeven op de kern van het netwerk. En dat zou op zich niet eens zo erg zijn, ware het niet dat deze output op zich ook weer een fout triggerd op andere delen in dat kern netwerk waardoor er uiteindelijk een cascade aan updates begint te ontstaan die niet voorzien zijn, die niet gepland zijn en waar je je niet zomaar tegen kunt wapenen. Deze updates leggen een groot deel van je kern netwerk stil. En dan is het gewoon gedaan. Dan moet je uitzoeken hoe je deze cascade kan stoppen en alles terug onder controle kunt krijgtn.

Je kunt nu eenmaal niet alles 2x uit voeren. Wat stel je voor… de hele MSFT cloud twee keer bouwen? Enig idee van de kosten?
Bovendien zou deze fout dan ook naar die backup gepropageerd zijn. Genoeg voorbeelden gezien dat zo’n online continuity faciliteit dan ook onderuit gaat.

Enig idee van de kosten?

Is dan toch het probleem van Microsoft? Zij proberen iedereen naar M365/Azure te krijgen (al dan niet helemaal op morele wijze) en sommige dingen draaien 100% in """de cloud""", mogen ze imo best zorgen dat er een betrouwbare failsafe is, in ieder geval toch zeker voor dingen waar je als klant/gebruiker geen controle over hebt. Kan redelijk simpel zijn, bijvoorbeeld het backupsysteem dat alleen na een expliciete handmatige actie de nieuwe config overneemt. Beetje wat je op Cisco-apparatuur hebt, pas als je zegt "save running config to startup" zijn de aanpassingen permanent. Pas je op systeem A de nieuwe config toe, maar gaat shit stuk dan laat je alles via B lopen terwijl je A terugzet. Je kan het op staging nog zo goed testen, productie kan toch net iets anders reageren.

Het ging in dit geval ook om wat problemen met/tussen routers, het is niet alsof je daarvoor meteen "de hele MSFT cloud twee keer [moet] bouwen".

Hoe zou jij het netwerk hebben gebouwd?

Ach ja, hier lag ook een deel van office plat waardoor mensen niet goed konden werken. Klein bedrijf dus ergens logisch om een deel van je IT zo uit handen te geven maar tegelijk ook slecht van Microsoft dat er geen backup is. Het is ook niet de 1e keer dat Office365 eruit ligt...

Ik vind het wel handig. Nu zeg je gewoon het ligt aan de cloud en gebruikers lijken dat te accepteren. Bij een onprem storing doen ze dat minder of niet.

Bij een onprem storing doen ze dat minder of niet.

Nooit zo'n last van. Ligt er hier sowieso niet zo vaak uit maar meestal is wat ik of een collega roept wel gospel.
Afgelopen 15 jaar één keer iemand gehad die wel echt buitensporig veel bleef drammen.

Die gaf ik deze:
"Moet ik met jou praten of moet ik het probleem oplossen?"

Ik snap sowieso niet waar sommige medewerkers zo verhit van raken. Je krijgt gewoon betaald, ga koffie halen ofzo.

[Reactie gewijzigd door Polderviking op 27 januari 2023 18:33]

De kans dat je zonder internet zit is zo klein..en dna kun je altijd nog een hotspot maken en daarmee verbinden

Mwah. Die kans is toch best wel groot.

De afgelopen twee/drie jaar heb ik dat meer dan eens gehad. Ik draai thuis veel 24/7 diensten (best effort basis) dus een daadwerkelijke netwerk storing haal ik er heel snel tussenuit. Wordt ook gewoon gelogd wanneer up en wanneer weer down.

Bij elkaar toch al gauw een uur of 30-40. Veelal wel ‘s nachts dus minder heftig mbt werk, maar wel vervelend voor mijn “klanten” in de VS die dan wel gewoon bezig zijn.

Je hebt het dan inderdaad over een huis en tuin internet verbinding zonder sla etc. Je mag daar conclusies uit trekken maar daar heb je dan niks aan.

Ik snap sowieso niet waar sommige medewerkers zo verhit van raken. Je krijgt gewoon betaald, ga koffie halen ofzo.

Er zijn altijd lastige gebruikers. Verder kan iemand natuurlijk een deadline missen, moet daardoor vanavond doorwerken. Of mist een belangrijke afspraak met een klant enz enz.

Ik zou dat soort applicaties sowieso nooit in de cloud willen draaien.
Zit je een keer ergens zonder internet met je laptop, dan ben je aangewezen op notepad en de rekenmachine, of zitten die tegenwoordig ook al in de cloud?

Nee maar de vraag is of je weet waar die staan. Kan best zijn dat microsoft de shortcut heeft verwijderd uit het startmenu of dat deze in het geheel niet meer werkt.

Nee, de applicatie wordt toegevoegd aan je O365 abonnement, waarbij 0.50 euro/maand/persoon bijkomt voor rekenmachine, 2 euro voor notepad, of je kunt ze combineren voor 5 euro met solitaire en mahjong.

Natuurlijk moet de licentie met de cloud verbinden en moet je eerst inloggen op Xbox Online (omdat het een game pakket is) met 2-factor authenticatie, opgepast dat je niet inlogt op je Azure login met hetzelfde e-mail adres, want dat is een ander account waar je persoonlijk Microsoft account aan verbonden is en als je inlogt via Outlook ga je eerst via GitHub moeten.

[Reactie gewijzigd door Guru Evi op 28 januari 2023 01:27]

Nu is het overmacht, veroorzaakt door Microsoft. Als dat vaker gebeurt dan zullen ze dat ook minder gaan accepteren. De reden dat er zaken als service levels bestaan.

Ja dat is het hele eieren eten natuurlijk.
Enerzijds is het goedkoper, beter en schaalbaarder als we met z'n allen dezelfde cloudboer gebruiken.. maar de keerzijde is wel weer dat je een stukje controle uit handen geeft.

Ik heb hier zelf altijd dubbele gevoelens over wanneer ik hoor dat de NS weer eens staakt of plat ligt vanwege blaadjes op het spoor of zo terwijl ik in de auto naar het werk onderweg ben.. dan moet ik altijd een beetje lachen om al dat gepredik dat we allemaal met het OV moeten en onze eigen auto weg moeten doen.

Lastige kwestie.. vooralsnog ben ik erg blij met mijn auto. Heeft me in meer dan een decennia nog nooit gefaald en staakt ook niet.

Lastige kwestie.. vooralsnog ben ik erg blij met mijn auto. Heeft me in meer dan een decennia nog nooit gefaald en staakt ook niet.

Dan woon je vast ergens in een hoekje van Nederland, want ik wil je wel in de spits zien rijden van Eindhoven naar Amsterdam en dan eerder aankomen dan iemand die met de trein gaat

Met de huidige tendens van stakingen in het OV is dat gemiddeld gezien niet zo moeilijk. Tis namelijk best een eind lopen.

Gemiddeld gezien is het aantal dagen dat de NS niet rijdt vele malen kleiner dan het aantal dagen dat er geen files staan

Ik woon niet ergens in een hoekje van Nederland.
Ik woon in een bescheiden stad, midden in het hart van Brabant, 10km van mijn werk, en mijn werktijden zijn buiten spitstijden dus ik sta nooit in de file.

Nee, iemand met het openbaar vervoer zou never nooit sneller van mijn huis naar mijn werk kunnen reizen.. en dit is op de meeste plekken in Nederland zo... buiten die ongezond grote en bebouwde steden.

En nu net zoals de rest. Probeer die 10 KM even in de spits. Want op de meeste plekken in Nederland reizen de meeste mensen per auto in de spits. Zo'n beetje de definitie van het woord.

buiten die ongezond grote en bebouwde steden.

Dat zijn de meeste plekken in Nederland

En nu net zoals de rest.

Nee bedankt. Dat jullie er voor kiezen elke dag in de sloot te springen moet je zelf weten. Ik heb betere dingen te doen dan elke dag uren van mijn kostbare tijd verspillen in een file.

Rij jij ook in een Apple?

Gelukkig draaien de NS kritieke systemen niet op Azure.
Een storing van 3 uur zorgde vorig jaar voor een dag zonder treinen. Deze storing bij Azure duurde 5 uur.

Vraag me serieus af hoe die keus tot stand komt.

Bestaan mensen die een veilige eigen server op kunnen zetten gewoon echt niet meer? Of is dat illusie?

Ik denk niet dat het "opzetten" van een server alleen een probleem is, maar alle componenten in totaal, nu is het ook een WAN/Router configuratie bij Microsoft de oorzaak.

Dus ook eigen servers hebben netwerk componenten nodig, kan je een "veilige server opzetten", maar ook die netwerk componenten moeten in orde zijn.

Daarnaast kan je software in orde zijn, maar een hardware probleem kan altijd voorkomen, dus ook rekening houden met dubbel uitvoeren voor als 1 component uitvalt.

En eenmaal alles opgezet, moet het ook onderhouden worden en monitoren dat alles goed blijft draaien.

Dus ja, bestaan echt wel mensen die een "veilige server" kunnen opzetten, maar komt veel meer bij kijken dan alleen dat.

Azure AD is zowel een PaaS (Platform as a Service) als een SaaS (Software as a Service). Als daar een verstoring is waardoor de gehele dienstverlening niet meer beschikbaar is zoals een paar dagen terug dan is er waarschijnlijk meer aan de hand dan het niet meer "veilig kunnen opzetten van een servertje".

Een decennium is tien jaar.

Backup in de vorm van? De infrastructuur zelf is redundant, maar als je een configuratie fout maakt, gaat het vaak heel snel met de backup mogelijkheden.

Als je vroeger een SBS server had draaien, kon die server ook crashen waardoor je niet meer kon werken. Hoe zag je dan een eventuele backup als oplossing?

Menig kmb hadden we een 1:1 bak erlangs staan, kabeltjes pluggen en gaan.
Grotere bedrijven een redundante oplossing al dan niet via co-locatie.

Netwerk routers? Complete servers? Vervangende netwerk switches?
Ik heb dit maar heel weinig bij kleine klanten gezien.

Ik heb heel wat hardware contracten gedaan, maar heel weinig MKB bedrijven hadden zo iets draaien.

Daarnaast is het vaak geen stekkertjes omwisselen. je zal ook de configuratie moeten overzetten, eventueel firmware upgrades uitvoeren.

Inderdaad, de dienst die op die SMB server draait voor 99,9% redundant maken is vrijwel onmogelijk voor een MKB dit kost meer dan dat het op levert.

Ik heb meegemaakt dat er in een bedrijf met duizenden medewerkers er een exchange omgeving offline ging omdat er een vinkje (dns) door iemand werd uitgezet. Dan kan je nog zoveel redundante servers en infrastructuur hebben. Als een admin dit direct in een productie omgeving doet, dan ga je. En ook al is er een redelijke acceptatie omgeving, die heeft b.v. vaak niet de zelfde aantal clients waardoor de load anders is en realistisch testen niet altijd mogelijk is.

[Reactie gewijzigd door dezwarteziel op 29 januari 2023 09:44]

Redundantie maakt de infrastructuur ook meestal complexer, waarbij incidenten lastiger zijn en configuratie fouten ook sneller gemaakt zijn.

Het hangt er inderdaad vanaf wat je met redundantie wilt oplossen/voorkomen.

Daarnaast is het vaak geen stekkertjes omwisselen. je zal ook de configuratie moeten overzetten, eventueel firmware upgrades uitvoeren.

Active passive setup?

Switch 2 upgrade/config change doen, dan switchen van switch 1 naar twee, werkt dat niet dan kun je weer terug naar 1 en werkt het wel dan is switch 1 de volgende keer je upgrade target, waarbij switch 2 je fallback is.

Of denk ik nu te simpel?

Green blue deployments moet in hardwareland ook werken toch?

Active passive setup?

Bij een klein bedrijf?

Switch 2 upgrade/config change doen, dan switchen van switch 1 naar twee, werkt dat niet dan kun je weer terug naar 1 en werkt het wel dan is switch 1 de volgende keer je upgrade target, waarbij switch 2 je fallback is.

Kan Switch 2 nog steeds een fout genereren die eventuel je netwerk plat legt, tenzij je een complete aparte management infrastructuur hebt, wat een MKB eigenlijk nooit heeft.

Configuratie fout kan ook optreden tussen beide switches, wat ook weer incidenten kan geven.

En switch redundantie kan je uitvoeren bij servers of belangrijke netwerkapparatuur, maar bij werkstations is dit eigenlijk nooit het geval.

Of denk ik nu te simpel?

Hangt er vanaf wat je wilt opvangen aan fouten.

Green blue deployments moet in hardwareland ook werken toch?

Is mogelijk, maar dan vervang je ook fysiek de hardware, waarbij je kabels moet omwisselen, wat ook weer fouten kan geven.

Je moet per business case kijken wat je eigenlijk wilt bereiken.

[Reactie gewijzigd door Rolfie op 29 januari 2023 10:52]

En dan propageert een fout in je netwerkconfiguratie niet? Dus wel.
Leuke case is die van Danske Bank. Lang geleden maar een eye-opener voor iedereen die denkt dat redundantie een oplossing is voor continuïteit. Beschikbaarheid en continuïteit zijn verschillende begrippen.

https://danskebank.com/ne...-releases/2003/pr03042003

Ultiem voorbeeld van alles, letterlijk alles, dubbel uitvoeren en door een fout toch volledig plat gaan.

Bij mijn werk als Business Continuity consultant altijd leuk leesvoer voor de IT’ers die altijd roepen dat redundantie, clustering e.d. de oplossing is.

Mensen maken fouten ja maar dat wil niet zeggen dat je die redundantie niet alsnog nodig hebt. Dat is wel degelijk de oplossing. Want zonder die redundantie gaan er zeker dingen fout.

[Reactie gewijzigd door Terrestrial op 27 januari 2023 23:18]

Redundantie is een deel van de oplossing maar business continuity vereist veel meer. Want wat doe je - zie de case van Danske Bank en de Microsoft case van deze week - als er een fout is die propageert? De fout zich dus ook verplaatst naar de systemen voor redundantie?

Ik heb meegemaakt dat een kleine fout van een beheerder in een productie omgeving zich tijdens een uitwijktest ook verplaatste naar het uitwijksysteem. Jammer, geen reparatie meer mogelijk.

Geloof me, 5 jaar gewerkt bij een uitwijkcentrum (CUC in Lelystad); redundantie is niet voor veel problemen de oplossing. En zeker niet voor menselijke fouten.

Ik heb meegemaakt dat een kleine fout van een beheerder in een productie omgeving zich tijdens een uitwijktest ook verplaatste naar het uitwijksysteem. Jammer, geen reparatie meer mogelijk.

Daarom gaat les 1 ICT MBO ook over redundantie en backups.

De backup was dat uitwijksysteem. Dus aparte productie omgeving en een aparte uitwijk omgeving. Niet aan elkaar gekoppeld anders dan dat er een back up van productie naar uitwijk gemaakt werd elke dag.

En tijdens een uitwijktest werd een script gestart dat de uitwijk locatie onderuit haalde. Dus bij een daadwerkelijke calamiteit - productie kapot - zou dan ook uitwijk kapot gegaan zijn. Lees: grote ellende.

Dit dus als voorbeeld van het feit dat redundantie niet altijd zekerheid geeft.

En les 1 ICT MBO zou moeten gaan over restore, juist niet over back up. Teveel denken ICT’ers dat back up het probleem is. Dat is het niet. Je informatiehuishouding te allen tijde kunnen restoren, dat is je uitdaging. En denk je daarover na dan zijn geteste backups, maar ook policies, draaiboeken, kennis, de backup software, etc, ook delen van de oplossing.

Bij het uitwijkcentrum waar ik werkte kwamen ICT’ers vaak een test doen met backups die niet te restoren waren, zonder kennis hoe dat moest, etc. Erg leerzaam om te zien hoe onvolwassen dat denken soms is.

We moeten ophouden altijd te praten over backup. Dat is het probleem niet.

En backups testen. Als auditor zie ik dat dit gewoon geen aandacht krijgt. Een keer per jaar een VM terug zetten, dat is het vaak wel. Maar hoe restore je je hele omgeving?

[Reactie gewijzigd door ernstoud op 29 januari 2023 12:09]

Goede procedures opstellen en verzinnen wat er allemaal kan fout gaan als er mensenlijk falen optreed. Microsoft heeft niet voor niks z'n procedures aangepast, daar leer je van.. En soms is het juist weer met extra redundantie op te lossen, bijv. een offline omgeving of apparaat die je aanzet wanneer de online omgeving is verklooid. De betere vraag is, is het financieel lonend om overal rekening mee te houden en dan worden er vaak andere keuzes gemaakt.

[Reactie gewijzigd door Terrestrial op 28 januari 2023 10:15]

Inderdaad, zo werkt het in de basis van BCM. En vooral transparantie naar je klanten.

Ach ja hier op Tweakers lopen de beste stuurlui op wal. Nooit fouten, alles perfect redundant en nooit downtime. Ofzo.

Eerlijk gezegd heb ik genoeg cases gezien waar die zichzelf overschattende ICT’ers de grootste problemen veroorzaakten. Bij deze case dus ook weer.

De case was in 2003. In die tijd draaide alles bij banken en verzekeraars op DB2.
En IBM slecht noemen? Tja. Ik begrijp dat soort uitspraken nooit zo. Komen bij mij als dominee versus priester over. Er is geen goed/slecht. Was de wereld maar zo lekker zwart/wit.

Op grote business critical applicaties zijn de Z/OS machines onverslaanbaar. Op de cliënt is Windows praktisch, op embedded en general purpose servers Linux of een ander Unix derivaat. Soms is een schroevendraaier de beste oplossing, soms een beitel.

IBM is slecht? Je trollt of je kent die wereld niet. Of beiden.

hij zal he waarschijnlijk over z'n 500€ lenovo laptop van de aldi hebben

Nee joh, IBM heeft geen geld om kundig IT personeel in te huren. Da's per definitie slecht

Leg eens uit? Voorbeelden? Zoiets roeptoeteren is zinloos. Slaat discussie doet, voegt niets toe.

Mijn excuses, er ontbreekt hier wat non verbale communicatie. Jij hebt helemaal gelijk.

Na 35 jaar werken op een AS/400 van IBM (of nieuwere versies) heb ik slechts één keer meegemaakt dat het systeem plat ging door IBM.

Mooie systemen, AS/400, RS/6000.

bedoel je mkb (Nederlands) of kmo (vlaams)?

Hoe stel je je zo’n backup voor? Het is gemakkelijk gezegd maar het kan niet.

Een veel gemaakte denkfout is natuur ook dat je 99.9% SLA hebt dus 43 minuten per maand of 8.6 uur per jaar mag de stekker er gewoon uit zonder issues.

En vergeet niet dat dat vaak vele malen hoger is dan dat menig bedrijf ook daadwerkelijk leverd inc maintenance onderhoud.

wanneer was volgens jou de vorige keer dat Office Microsoft 365 zo'n storing had?

slecht van Microsoft dat er geen backup is.

Dan is de vraag, wat omvat dit WAN? Microsoft heeft vele datacenters waartussen data redundant is opgeslagen. Wellicht had deze change gefaseerd uitgevoerd moeten worden.

[Reactie gewijzigd door dezwarteziel op 29 januari 2023 09:21]

Single point of failure, anyone?

Yep, de beheerder met admin rechten, er is geen redundantie opgewassen tegen een "oeps" momentje natuurlijk.

Eigenlijk komen ze hier toch veel te makkelijk mee weg ...

Ik herrinner me nog alsof het gisteren was dat een directeur in mijn oor stond te roepen dat iedere minuut downtime hem 100.000BEF kostte.... en toch vind/vond ik dan veel leuker dat volledig afhankelijk te zijn van een derde partij ...

De vraag is altijd: kun je het zelf beter? Goedkoper? Bijblijven in de techniek, heb je daar de mensen voor? Of accepteer je 99,99% beschikbaarheid?

Ze halen geen 99,99 , dat is nl maar 1uur per jaar.

Daily 9 seconds
Weekly 1 minute
Monthly 4 minutes 19 seconds
Yearly 52 minutes 34 seconds

[Reactie gewijzigd door klakkie.57th op 27 januari 2023 19:10]

Dus kunnen bedrijven nu beroep doen op hun 25% 'Service Credit' volgens de SLA. (Althans Exchange Online)
((43200– 340)/43200) * 100 = 99.21% Uptime. (Exclusief eventuele andere storingen dze maand)

Het niet halen van 99,99% is ook niet persee 'slecht', dat is wat zij garanderen zonder 'aansprakelijk' te zijn.

Eigenlijk komen ze hier toch veel te makkelijk mee weg ...

Dus ze komen er niet 'makkelijk' mee weg, je kan nu gewoon beroep doen op de Service credit die zij beloven en waar bedrijven mee akkoord zijn gegaan.

Sla is ook 99.9% (three nines) dus ze kunnen nog een paar uur down

Weet niet helemaal wat je punt is, aangezien de uptime met deze storing al 99.2% is.

Edit: ik zie al in je andere reacties hoe je hier op komt. Maar Microsoft SLA is per maand, niet per jaar.
Als 1 storing dus langer duurt dan 43 minuten, heb je recht op compensatie.
((43200– 43)/43200) * 100 = 99.9%

[Reactie gewijzigd door Christoxz op 27 januari 2023 22:57]

Je hebt gelijk, per maand, niet goed gelezen. Ik ben benieuwd hoe dat dan met de korting verwerkt wordt, gaat dat automatisch of moet je er achter aan?

Ok. 99,96 % dan. Wijsneus .

Heeft niks met wijsneus te maken, ze hebben gewoon hun vooropgestelde SLA’s van 99,99 niet gehaald

En als je een SLA hebt afgesloten, dan zal je daar ook voor gecompenseerd worden.

Office 365 sla is dacht ik 99.9%, of kijk ik nou verkeerd?

Alleen is de SLA niet 99.99 maar 99.9 op M365,

Alleen bepaalde Azure componenten hebben hogere SLA

https://www.microsoft.com...s-SLA-for-Online-Services

Voor de komende jaren meteen maar dan
Maar even een reality check: wie dat gelooft en er op rekent dat dat zou kloppen heeft boter op z’n hoofd, want dat is vrijwel onmiddellijk.

Makkelijk? Hoe vaak komt dit voor dan? En welke 'straf' had je in gedachte, met name eentje dit herhaling kan voorkomen?

Ik ben al zeer tevreden over het feit dat ze zulke openbaarheid geven over de toedracht. Dat zag je 10 jaar geleden niet hoor.

1 keer is gewoon 1 keer teveel.
Wat is hun high-availability/multi-region verhaaltje nog waard na dit soort incident.
Juist, helemaal niets, want dan hadden nooit alle regio’s geïmpacteerd kunnen zijn.
Waarom zou je nog betalen voor azure HA oplossingen als die het toch niet doen 🤷🏻‍♂️

En wat de openbaarheid betreft, moet je hun ook maar geloven op hun communiezieltje.

[Reactie gewijzigd door klakkie.57th op 27 januari 2023 19:01]

1 keer is gewoon 1 keer teveel

Ah, dus je wens is eigenlijk 100% uptime. Dat is best knap, aangezien werkelijk niemand in de hele wereld dat kan leveren.

Ze claimen zelf 99,99 voor verschillende diensten, als ze het dan niet waarmaken mag je hier toch echt wel een punt van maken. Daarenboven 99,999 is niet ongebruikelijk.
Het gaat hem niet over “hoe vaak” , maar om “hoe lang”

[Reactie gewijzigd door klakkie.57th op 27 januari 2023 19:25]

Volgens mij heeft Office 365 een sla van 99.9% (iets meer dan 8 uur downtime, deze downtime was 5 uur en 40 minuten), haal je dat niet, krijg je 25% compensatie voor de maand waarop het gebeurt, 50% bij 99% of minder uptime, 100% bij 95% of minder uptime.

Daarenboven 99,999 is niet ongebruikelijk

er zijn hier en daar wat losse services die dat aanbieden, maar dit getal van uptime kom ik nauwelijks tegen in contracten.

Er zijn wel andere dingen offline gegaan dan enkel o365.

Zeker, die hebben ook een sla en daar zal je als bedrijf ook naar moeten kijken, daar zijn nou slas voor.

Microsoft claimed dat je diensten met een uptime van 99,99% aan mekaar knoopt over verschillende regio’s om ze een hogere uptime te bekomen, maar blijkbaar ondersteunt hun backbone deze situatie niet. Dan mag je wel gecompenseerd worden per individueel onderdeel, maar je nam deze HA setup net af om een betere overal SLA te bekomen.

Ik ken alleen de office 365 sla van 99 9%. Ik kan nergens vinden dat je dat hoger kan krijgen

De outage heeft zich toch niet beperkt tot enkel O365.

Between 07:05 UTC and 12:43 UTC on 25 January 2023, customers experienced issues with networking connectivity, manifesting as long network latency and/or timeouts when attempting to connect to resources hosted in Azure regions, as well as other Microsoft services including Microsoft 365 and Power Platform. While most regions and services had recovered by 09:00 UTC, intermittent packet loss issues were fully mitigated by 12:43 UTC. This incident also impacted Azure Government cloud services that were dependent on Azure public cloud.

Je mag er ook een punt van maken , Staat Nl gewoon in je SLA die je getekend hebt die overigens voor de meeste componenten 99.9 is en dus nog steeds gehaald is , maar als die overschreven word krijg je vanzelf compensatie zoals in SLA beschreven hoe je niet eens een klacht voor in te dienen.

https://www.microsoft.com...s-SLA-for-Online-Services

Bij overschrijding staat er gewoon een retour tarief waarmee je akkoord bent gegaan.

Daarenboven 99,999 is niet ongebruikelijk.

Dat is wel ongebruikelijk. Elke 9 extra brengt enorme kosten met zich mee. Extra redundantie komt niet zomaar eventjes aanwaaien.

waar kan ik 99,999% uptime krijgen? Vertel me dat alsjeblieft.

Bij grote providers kan dit vaak wel.
Dat staat niet gewoon op hun website, maar hier gaan onderhandelingen aan vooraf waar dan ook een design wordt gemaakt.

In dit geval ging de storing over het backbone “Netwerk”, dan verwacht ik bij een bedrijf als microsoft dat, dit inderdaad een SLA heeft van 99,999, waar ik dan als klant van Microsoft van profiteer.

[Reactie gewijzigd door klakkie.57th op 29 januari 2023 13:48]

Jij maakt dus nooit fouten ?

Ik heb jaren geleden gekozen om alles te draaien op Google Cloud, was goedkoper en is nog altijd goedkoper voor de meeste dingen. Ik heb dus letterlijk sinds 2015-2016 nog nooit geweten dat mijn applicaties niet beschikbaar waren. Zelfs niet bij database upgrades etc. Ben blij da ik toen tijd heb genomen om Azure/AWS/Google Cloud te vergelijken en dat ik toen denk ik toch wel de juiste keuze heb gemaakt.

Maar zoiets kan gebeuren, ik leg dat ook uit aan klanten. Er zijn problemen die ik kan verhelpen, maar als Google cloud eruit ligt, dan moet ik ook wachten. Zo simpel is dat. Enja ik heb ook een 2de server draaien en kan eigenlijk gewoon de routing aanpassen naar die 2de server, met een replica db etc. Maar effe routen naar server 2 kan ook effe duren. Zo werkt nu alles eenmaal.
En de meesten roepen moord en brand. Maar zoveel kritische applicaties zijn er nu ook niet weer. Iedereen zegt wel dat is kritisch, maar voor mij is kristisch "luchtverkeersleiding, hulpdiensten, politie, stroom/gas etc" de rest beschouw ik niet als kritisch. Is het leuk nee, maar er gaat niemand van sterven hoor.
En als je het zelf draait is het dan beter ? Je kan een server voorzien en een backup server en toevallig faalt er iets op de 1ne, dus effe naar server2 en daar faalt ook iets op. De baas zal eens lachen als jij zegt ik wil nog een 3de. Veel mensen moeten ook klaarblijkelijk niet zelf de factuur betalen van al het moois waar ze dagelijks mogen mee spelen.

Het argument is steeds dat iemand als “ik” fouten maakt en daarom gaan we naar AZURE/AWS/whatever. In dit geval zou de “ik” in dat verhaal ontslagen worden … nu gaat men normaliseren omdat het Microsoft is

• In 2018 is AWS meer dan 24 uur down geweest.
• In 2019 is Google Cloud bijna 5 uur down geweest.
• En nu Microsoft (Azure) met 5 uur en 40 minuten.

Deze dingen kon ik snel vinden. Er zullen vast meer voorbeelden zijn.

Ik denk dat jij nooit meer iets op internet kan of wil. Alles kan potentieel down gaan dus.

Dingen gaan nouweenmaal een keer down. Shit happens. Daarom kan niemand 100% garanderen.

Ik ben al zeer tevreden over het feit dat ze zulke openbaarheid geven over de toedracht. Dat zag je 10 jaar geleden niet hoor.

Toevallig met Azure juist wel, want bijna 11 jaar geleden ging Windows Azure, zoals het toen nog heette, plat door een schrikkeljaar bug. Daarover gaven ze veel duidelijkheid:
https://azure.microsoft.c...ruption-on-feb-29th-2012/
Sowieso een leuke post om terug te lezen, omdat ze behoorlijk in detail vertellen wat er toen mis ging.

Was voor mij een eye opener om te lezen dat dit soort foutjes dus ook in dergelijke grote organisaties gemaakt worden.

Tsja. Ik zou zeggen: lees de SLA van de dienst waarmee je akkoord gegaan bent. Als je kunt aantonen dat Microsoft zich niet aan de SLA gehouden heeft dan kan je hen aansprakelijk stellen. Anders zal je óf moeten accepteren dat de dienst er wel eens uit ligt, óf een andere oplossing moeten zoeken die wel aan je eisen voldoet.

Volgens Microsoft was de betreffende opdracht niet goed getest op de specifieke router waar die werd uitgevoerd. Het bedrijf erkent dat de opdracht verschillend kan reageren op specifieke hardware en dat het betreffende kwaliteitscontroleproces niet goed was doorlopen.

Zullen wel Cisco routers zijn waarbij de CLI commando's bij verschillende IOS software versies weer nét even anders geïnterpreteerd worden. Blij dat ik niet meer met dat spul hoef te werken.

Volgensmij als je de sessies van Mark russinovisch kijkt geven ze aan dat het linux machines zijn met een speciale eigen distro, Normale router hardware was nl te traag met update / downtime tijdens updates.

Een Arista is ook gewoon Linux. Hyperscalers kopen vaak gewonr router/switch hardware (whitebox) of maken ze zelf met hun eigen software.

Bijzonder. Een WAN van deze omvang beheren zonder scheiding van management- en user traffic? Geen out-of-band management?

Dat staat er niet. Een fout IP adres naar alle routers waardoor de forwarding verkeerd liep, dat heeft niets te maken met out of band management.

En toch verbaast het mij dat het (voor zover ik kan zien) wereldwijd was.

Ik snap dat dit het WAN betrof, maar is er niet iets waardoor je dit soort kan segmenteren?

Ik zou mij in kunnen denken dat bijvoorbeeld aparte routers/Internet verbindingen bestaan voor het publieke cloud deel en Expressroute verkeer. Dat hoeft elkaar dan niet te raken met een verkeerde WAN update en dus een stuk minder impact hebben.

Of zie ik dit verkeerd? Ik snap IT best aardig, maar dit is een niveautje hoger dan ik in werk.

Routers praten met elkaar, ze wisselen routes uit en nemen in geval van nood elkaars werk over.

Dit gaat meestal redelijk automatisch op basis van de config.

Als je je dan bedenkt dat je bijvoorbeeld een config update doet op 1 van de core routers en die gooit dat vrolijk door naar alle anderen, dan heb je dus een redelijk probleem.

Vaak zit er nog wat vertraging op de verwerking en heb je het probleem dus pas door als het al breed door de infra gegaan is. Dan kun je natuurlijk het commando terugdraaien, maar dat zal dezelfde weg moeten afleggen en dus ook even op zich laten wachten voordat het overal actief is.

Al met al verwacht ik dat hier iemand zijn baan is kwijtgeraakt of op zijn minst een heel naar gesprek heeft moeten voeren, en dat komt dan vooral door het niet volgen van de juiste test procedures etc.

Als je al je engineers ontslaat die wat fout doen, durft niemand meer een complexe hoog impact change uit te voeren. Het is juist door het delen van deze ervaringen dat je als team/branche ervan kan leren.

Dat van die routes snap ik wel, maar als ik mijn thuis router aanpas, heeft dat geen invloed op het hele internet toch? Dat komt omdat er een scheiding is.

Ik vraag mij dus af waarom zij niet meerdere scheidingen hebben om dit soort problemen in te kunnen dammen. Beter dezelfde wijziging 10x invoeren in 10 losse netwerken dan 1 groot netwerk en dus fout zou ik zeggen.

Omdat Microsoft een eigen backbone heeft, voor al hun netwerken om het verkeer tussen de verschillende regio's te kunnen transporteren. Daarvoor moet alles en iedereen aan elkaar verbonden zijn. Want twee backbones ga je ook niet bouwen.

Stel je voor dat je een bedrijf hebt, met 100 vestigingen, wil je dan op iedere vestiging handmatig de routes naar de andere vestigingen aanleggen?

Stel er komt er eentje bij, dan moet je dus 100 routers aanpassen en totdat je klaar bent werkt het niet. Als je 1 core router hebt, voeg je daar de route toe en verspreid die zich naar de andere 99.

Dit is een heel gebruikelijk iets eigenlijk. Voorkomt onnodig werk en verkleint de kans op fouten, want 1 keer goed doen is makkelijker als 100* goed doen.

Mocht je meer willen weten, kijk eens naar bijvoorbeeld BGP of om het wat simpeler te houden DMVPN van Cisco bijvoorbeeld.

scsirob bedoelt er mee te zeggen dat als je out-of-band management had ingeregeld dat de monitoring wel gewoon door had kunnen gaan mits je de monitoring natuurlijk via die interface doet (wat vaak niet gebeurt uit security overwegingen).

Moeten je monitoringtools op zich nog wel bereikbaar zijn, wat bij een netwerkstoring wel eens een probleem kan zijn.

Exact

Zoals ze altijd zeggen, “it’s always dns”

BGP in dit geval

Ze noemen het niet specifiek en hebben het over forwarding van buiten naar binnen hun eigen netwerk; iets dat niet op BGP duidt, maar eerder op NAT problemen.

https://www.thousandeyes....t-outage-analysis-2023-01
Lees de samenvatting van het webinar, en trek je conclusies.

Deze site heeft het wel over bgp prefixes die ingetrokken en weer actief worden waar de uitleg van Microsoft daar niks over schrijft. Het is een eigen waarneming. Microsoft schrijft zelf

We determined that a change made to the Microsoft Wide Area Network (WAN) impacted connectivity between clients on the internet to Azure, connectivity across regions, as well as cross-premises connectivity via ExpressRoute.

en lijkt volgens mij te vertellen dat het een intern probleem was waarin communicatie tussen routers grotendeels stokte. Je kwam dus wel bij hun netwerk maar er niet verder in.

De bron zegt letterlijk:

a command given to the router caused it to send messages to all other routers in the WAN, which resulted in all of them recomputing their adjacency and forwarding tables.

Dat is dus letterlijk wat een routing protocol doet, en BGP is het meest gebruikte routing protocol wat er is, zeker op netwerken op de schaal van Microsoft's clouddiensten.

Daarnaast: letterlijk alles wat routers, switches en firewalls doen, is forwarden. Forwarden is niet hetzelfde als NAT. (En NAT wordt ook niet in het artikel genoemd.)

NAT was misschien niet de handigste term om te gebruiken. Mijn netwerk kennis een beetje afgestoft en inderdaad zou Microsoft best iBGP kunnen gebruiken, waarschijnlijk zelfs, maar mijn punt was vooral dat ze het zelf niet benoemden. Ondertussen zijn er genoeg voorvallen van misbruik van BGP geweest dat het grotere publiek deze term kent dus waarom hem niet gebruiken wanneer het daar aan ligt?

Was zeker een automatische update uit hun eigen stal
We weten allemaal inmiddels hoe goed die werken. Beter gezegd niet werken

Hier kan ok pc niet activeren na hardware veranderingen