Eén minuut uitval bij Nikhef ontregelde Odido's mobiele netwerk urenlang

Tekst

Toen het mobiele netwerk van Odido op maandagochtend een paar uur niet stabiel werkte, leek dat een storing zoals die recent vaker zijn voorgekomen. De oorzaak lijkt te liggen bij een extern datacenter, maar het is wel een bijzondere. In een datacenter van een natuurkundig onderzoeksinstituut vond een stroomstoring plaats die precies 51 seconden duurde, maar grote impact had op niet alleen Odido maar ook Eurofiber, en vervolgens weer andere diensten.

Wat is Nikhef?

Om te begrijpen waar deze storing vandaan kwam, duiken we de subatomaire fysica in. Geen zorg, dit wordt geen college van Robbert Dijkgraaf, we gaan het hebben over een datacenter. Specifieker: we gaan het hebben over Nikhef, van oorsprong een instituut dat onderzoek doet naar subatomaire fysica. Dat onderzoek doet het nog steeds, maar inmiddels beheert Nikhef ook een groot datacenter dat vooral dienst doet als internetknooppunt. De organisatie heeft naar eigen zeggen 'een bijdrage geleverd aan de ontwikkeling van het internet, satellietnavigatie, geavanceerde sensortechnologie en medische beeldvormingstechnieken'. Computable schreef in 2017, toen Nikhef zich aansloot bij de Dutch Datacenter Association, dat het instituut 'vanaf het begin' betrokken is bij de ontwikkeling van het internet, vooral door experimenten met de Europese raad voor kernonderzoek, het Cern.

We spraken met meerdere tweakers die op een of andere manier werken met het datacenter van Nikhef. Een van hen zegt dat je je als klant tot een paar jaar geleden nog moest melden aan de balie van 'een soort universiteitsgebouw' om toegang te krijgen. Sindsdien is het datacenter gegroeid en professioneler geworden. Desondanks is het naar verluidt nog relatief kleinschalig en vooral heel techneutvriendelijk. Een andere tweaker vertelt dat beheerders kabels tussen de kasten in het datacenter zelf mogen trekken, mits ze deze netjes labelen en documenteren. Nikhef heeft daar ook richtlijnen voor opgesteld.

Desondanks is Nikhef, mede omdat het zo'n belangrijke plek is geweest voor het ontstaan van het internet, een van de belangrijkste datacenters voor de connectiviteit in Nederland en delen van Europa. Onder meer Proximus, Eurofiber, Ziggo, Odido, KPN, Tele2 Zweden, het Deense TDC en het Finse Elisa hebben hardware staan in Nikhef. Dat komt ook doordat Nikhef een datacenter is dat vooral voor connectiviteit bedoeld is. Volgens een van de tweakers die wij spraken staat Nikhef zelfs alleen routers toe, een andere houdt het erop dat Nikhef 'liever niet' heeft dat klanten er servers plaatsen.

Nikhef in het Science Park in Amsterdam. Bron: Wikimedia Commons/Hobbema

Een storing van één minuut

Een tweaker meldt dat alle voedingen bij 'serieuzere datacenters' zoals Nikhef dubbel zijn uitgevoerd. Het datacenter verwacht van klanten dat zij een van die powerfeeds continu belasten en de andere alleen als back-up gebruiken of met apparaten die een dubbele voeding hebben. Een van de feeds viel om 8:44:45 uur precies 51 seconden uit, zo meldt een tweaker op basis van de logging van zijn router. Dat had lang niet voor alle klanten impact, omdat de andere voeding wel bleef werken. Bij twee providers, EuroFiber en Odido, leek dat anders te zijn, maar waarom daar problemen ontstonden, is moeilijk te zeggen. Eurofiber zelf zegt niet expliciet dat de stroomuitval bij Nikhef de oorzaak was van de storing bij de zakelijke provider. "Deze verstoring had een landelijke, externe oorzaak en lag buiten onze eigen infrastructuur", reageert een woordvoerder op vragen van Tweakers. "Wij blijven de situatie actief monitoren en houden alles nauwlettend in de gaten. Voorlopig hebben wij nog geen definitieve verklaring ontvangen van de betrokken partijen over de oorzaak van de onbeschikbaarheid."

Ook Odido wil alleen verklaren dat een stroomstoring in 'een datacenter' de oorzaak was van de storing waardoor het mobiele internet maandagochtend instabiel werkte. Op Allestoringen kwamen ook duizenden meldingen binnen over KPN en Ziggo, die beide ook klant zijn bij Nikhef. Woordvoerders van die bedrijven verklaren echter dat er bij hun netwerken geen storingen waren. Zij zeggen dat de pieken werden veroorzaakt door de problemen die hun klanten ondervonden met het contact met Odido-klanten.

Ook bij meerdere banken werden vanochtend problemen gemeld op Allestoringen. Dat gold met name voor de RegioBank, ASN Bank en SNS. Het is zeer waarschijnlijk dat dit verband houdt met de storing bij Nikhef. ASN Bank, moederbedrijf van de drie eerdergenoemde banken, is daar zelf geen klant. Het maakt echter wel gebruik van diensten van internetknooppunt NL-ix, dat op zijn beurt weer klant is van Nikhef. Het is ook mogelijk dat ASN diensten afneemt van Eurofiber, maar dat is niet bekend; de zakelijke provider heeft geen openbare lijst van klanten.

De storing roept daarmee ook vragen op over de kwetsbaarheid van internetverbindingen in Nederland. Want als een stroomstoring van minder dan een minuut al serieuze problemen kan veroorzaken bij twee grote providers in Nederland, wat zijn dan de gevolgen van een serieuzere, langdurige storing? En waarom ondervonden twee grote bedrijven problemen terwijl slechts een van de twee feeds uitviel? Het is een vraag die vast en zeker nog besproken zal worden, vooral bij die bedrijven zelf.

Nikhef wilde nog geen inhoudelijke reactie geven op vragen van Tweakers. Het bedrijf meldt wel dat het nog onderzoek doet naar de oorzaak van de storing en zijn klanten later informeert over de resultaten. Wanneer dat precies gebeurt, is niet bekend.

_{Redactie: Imre Himmelbauer • Eindredactie: Marger Verschuur}

Reacties (89)

[Snow_King]

Wij hebben ook apparatuur in Nikhef, alles op de A en B powerfeed aangesloten. Wij hebben ook de uitval gezien, maar geen problemen gehad omdat 1 van de twee feeds wel bleef werken.

Wel hebben we veel BGP neighbors offline zien gaan, wat daar precies achter zit blijft gissen.

[jDuke]

Hier hetzelfde, zit zelf in Nikhef inderdaad, vanochtend hoop neighbours down gegaan, ik vraag me zelfs af alsof er niet switches van een IX down zijn gegaan. Eigen netwerk incl. eigen WDM waves bleef draaien, dus was even achter de oren krabben wat er precies aan de hand was.

Gezien de hoeveelheid wat ik zag dat down is gegaan is het niet een foutje qua power feeds. Of stroom verbruik van een rack was te hoog om op te vangen met een enkele feed of spullen aangesloten op een enkele feed.

Dat Odido zo lang last had van de storing, en het idee van de vorige storingen, lijkt wel een configuratie ding op hun routers wat niet lekker gaat. Kan me niet voorstellen dat je op zo'n netwerk maar met enkele lijntjes werkt.

[Reactie gewijzigd door jDuke op 17 november 2025 23:25]

[Nox]

Wat wij zien bij een stroomuitval van een rack is op de edge locaties: 2 groepen voor een rack, een groep via een UPS, de ander direct de apparatuur in. Faalt de UPS, blijft het doordraaien. Faalt de feed, dan gaat alles via de UPS.

Echter is de runtime in onze monitoring bijvoorbeeld 50 minuten. Maar zodra de stroom wegvalt zakt dat naar 20. Dit omdat de load op de feed met UPS dan opeens verdubbelt. Het zal me niks verbazen als er ergens een zekering niet berekend was op (meer dan) een verdubbeling van de belasting.

[jDuke]

Inderdaad break vs non-break feeds. Maar het beeld wat ik zag met de netwerken om me heen is het niet te vergelijken met Odido. Wat weg viel en terug gekomen is was het wel binnen 15 min stabiel.

Ik vermoed dat het wel een trigger is geweest maar dat het zo lang onstabiel is zit toch een andere reden. Ze hebben daar wel vaker dan eens problemen met routering. Dat de routers moeite hebben met het opnieuw opbouwen van routes, wellicht dat control plane tekort aan resources heeft. Het is en blijft speculeren. Odido weet de oorzaak maar niet deelt zullen we het nooit weten.

[Nox]

Ik gok dat Eurofiber de oorzaak weet en dat Odido als afnemer van de diensten van Eurofiber er last van had.

[Saffie01]

Lijkt mij toch iets wat enkelvoudig was aangesloten, en als je eenmaal een BGP update krijgt ben je een paar uur verder voor alles weer een beetje rustig is.

[fuzzyIon]

Niet de eerste keer:

nieuws: Storing bij Nikhef zorgt voor netwerkproblemen internetproviders

[sniek]

2008... Die gun ik ze wel. Jij toch ook hoop ik ;)

[n9iels]

Maar betekent dit dan eigenlijk dat Odido en Eurofiber hun routers niet correct redundant hebben aangesloten?

[RiDo78]

Of ze hebben het verkeerd aangesloten. Zo zijn wij bij een vorige werkgever eens door het oog van de naald gekropen

Daar hadden we meerdere Cisco UCS blade-chassis. Onze chassis hadden 4 enkelfasige 230VAC voedingen en het bleek dat die door de collega’s of monteurs om-en-om op de feeds waren verdeeld.

Vervolgens hadden ze die als N+1 ingesteld. Dus onder de 25% load zijn er 2 PSU’s actief (een extra), bij 25% load schakelt er een derde bij en bij 50% of meer zijn ze alle vier actief. Die instelling is bedoeld voor één enkele of vier onafhankelijke feeds. Bij 2 feeds kan het gebeuren dat twee actieve PSU’s tegelijk uitvallen omdat ze op dezelfde feed zitten. Omdat het inschakelen van de twee overige PSU’s tijd kost, zijn alle blades enkele seconden spanningsloos, met alle gevolgen van dien.

Heb je 2 feeds dan moet je dat in de firmware aangeven, moeten de chassis A-A-B-B aangesloten zijn en moet je opgeven welke servers er down mogen als er tijdens een feedstoring meer vermogen verbruikt wordt dan de twee overgebleven PSU’s kunnen leveren. Dat afsluiten gebeurt netjes (de PSU’s kunnen een korte tijd extra vermogen leveren) maar je moet het wel instellen, anders gaan er quasi-random servers doen.

Gelukkig kwam ik daar achter toen het datacenter liet weten onderhoud op een van de feeds te moeten doen. Ik ben toen gaan controleren of alles juist was aangesloten. (Niet alle monteurs leveren kwaliteit, of ze zien het verschil tussen een blauwe en een rode kabel niet)

Vandaar dat ik het liefst voor een geplande feed black-out van een feed het liefst even een site-visit doe om alles even na te lopen. En het zal ook niet voor het eerst zijn dat ik machines tegen kom die ‘voor het gemak’ met beide PSU’s in dezelfde PDU zitten.

[Saffie01]

zie mijn reactie hierboven, ik begrijp hieruit dat tegenwoordig de voedingen dus helemaal niet meer echt redundant zijn maar een beetje kunnen opschalen en aan server throttling doen.

klinkt als "if you pay peanuts you get monkeys"

[Nox]

Nee. Je kan aangeven hoe je je PSU's wilt gebruiken. Als je een enkele feed hebt en het 'alles of niets' is, dan is voedingen bij- en afschakelen prima. Heb je 2 of 4 feeds dan dien je dat dus te configureren. Dus de vraag is of je redundancy wilt of dat je gewoon heel veel stroom wilt voor bijv. PoE devices. Op enkele locaties hebben we onze switches moeten voorzien van kleinere voedingen. Dan kan je kiezen: Of je levert voor 24 poorten continu PoE, of voor 48 maar als er een voeding uitvalt dan gaat de helft offline. Het is gewoon wat je wilt.

Hoewel wij geen enorme bult servers hebben, zijn de servers die we kopen nog steeds redundant aangesloten met dubbele PSU. Alleen als je naar high density omgevingen gaat zoals blade servers deel je 1 grote PSU over meerdere kleine servers.

En cisco-pricing is niet 'peanuts' btw...

[Saffie01]

Wat jij blade servers noemt noemde wij pizzadozen Was meestal compaq of hp.
Die dingen kwamen rond 2003 met 3 halve voedingen ipv 2 hele, allle cisco apparatuur was nog standaard uitgerust met 2 volledige voedingen.
Die prijzen ken ik toen ik de backbone voor het nieuwe hoofdkantoor op de zuidas achterin had liggen ben ik eens gaan tellen en later toch eens nagevraagd of we een transport verzekering hadden van minimaal 2,5 mil.
PoE bestond wel maar hadden we toen nog net niet. Userswitches was meestal 5500 serie en backbone 6X00 vol met glas en routermodules en dan redundant uitgevoerd (dus dubbele tree structuur met 2 roots)

Maar desalniettemin lees ik toch ook uit jou verhaal dat die neuwe apparatuur niet vollledig kan draaien op de helft van de psu's (uitval PoE) of moet/kan je nog steeds wel 2 volledige psu's installeren maar is dat een keuze met bijbehorend kostenplaatje ?

[jadjong]

Het is een keuze op basis van kosten. De mogelijkheid dat alle voedingen blijven werken als er een feed uitvalt is ook mogelijk. Je steekt dan twee stekkers in een apparaat (feed A&B) maar intern zijn alle voedingen verbonden met zowel feed A als B. Trek je er een stekker uit dan draait het apparaat op volle capaciteit door, pas als er intern twee voedingen defect gaan krijg je een situatie dat er functies uitgeschakeld worden.

Dit is duurder en minder efficiënt omdat je in twee stappen werkt. Je hebt namelijk per feed een converter nodig die van 230VAC naar bijvoorbeeld 325VDC omzet, die knoop je intern aan de DC kant aan elkaar. Je kan namelijk wel verschillende DC bronnen aan elkaar knopen zonder vuurwerk te maken, dat lukt met AC niet zo makkelijk.
Als je dan intern een spanningsbus van 325VDC hebt koppel je die aan de vier voedingen die het weer omzetten naar 3V,5V,12V en wat er nog meer nodig is om een printplaat in leven te houden.

[Saffie01]

die converter zit toch standaard in iedere voeding of zie ik dat verkeerd. Of je zo'n voeding nou op een 230v bus zet of aan het net koppeld met een stekker, hij zal altijd een conversie naar DC moeten doen om het apparaat te voeden.

Lees je verhaal net nog eens maar als er maar een converter in zit die alle 4 voedingen voorziet van DC heb je weer een Spof.

[Reactie gewijzigd door Saffie01 op 18 november 2025 14:19]

[Nox]

Onze Cisco switches, 48p poe, kan je vullen met 300, 750 of 1100 watt voedingen (eerste niet geprobeerd, maar ze passen wel) en op basis van de configuratie krijg je een PoE budget in je switch beschikbaar. Sowieso blijft de switch zelf draaien, dat is priority en dan gooit hij gewoon een zwik poorten zonder PoE als het budget niet toereikend is. Overigens doen veel switchproviders power toewijzen aan poorten. Werkelijk gebruik 6W, maar Class0, reserveert hij 15,4W bijvoorbeeld. Wil je 48x15,4W gebruiken heb je 740W nodig (een enkele 1100W PSU trekt dat). Werkelijke belasting van de switch is dan 130W + 48x6 = 418W.

[RiDo78]

Een pizzadoos is bij mij een 1U server. Cisco blades zijn iets dikker als 1U en kunnen de volledige breedte of de halve breedte (standaard) hebben. Daarvan passen er respectievelijk 4 of 8 in een chassis en elk chassis is verantwoordelijk voor de stroomvoorziening en DCE-connectiviteit (Ethernet en/of FC) van alle blades. Je hebt dus 4 voedingen die verantwoordelijk zijn voor het voeden van maximaal 8 blades en de twee backplanes (A & van het chassis.

Maar inderdaad, if you pay peanuts... Gelukkig weet ik niet wie die dingen daar initieel heeft opgehangen, wel dat het niet Cisco zelf was.

[rob12424]

Zou kunnen: ik sprak pas kennis van mijn vader die is met pensioen en geeft af en toe nog les. In zulke zaken.

Hij zei letterlijk mensen sluiten tegenwoordig bedingen aan maar controleren niet. Hij heeft wel eens een (in overleg) een groot serverpark lam gelegd om te kijken of alles werkte. Wat bleek 2 noodaggregaten die gevoed werden met koelwater uit dezelfde put. Al zet je op papier nog zoveel: TESTEN of het klopt durven ze vaak niet. En als het dan mis gaat is het ook goed mis.

Overigens: ik werk op een lab. Ik kan je 1 ding zeggen: je kunt beter 15 min. Stroomuitval hebben dan een spannjngsdip of een minuut stroomuitval. Veel aperatuur kan een lange stroomuitval makkelijk hebben, maar een spannjngsdip of piek of juist zeer korte stroomuitvallen zijn vaak juist funest. Ook als je een aggregaat hebt draaien en je schakelt de normale spanningsbron weer bij moet je zelfs nog uitkijken dat zulke dingen goed gaan.

Overigens wel grappig dat gisteren de campagne van de overheid: " wat te doen bij stroomuitval" begon.

En het is bij het NIKHEF dus die kunnen ook mooi onderzoeken wat er gebeurde.

[Triblade_8472]

En waarom ondervonden twee grote bedrijven problemen terwijl slechts een van de twee feeds uitviel? Het is een vraag die vast en zeker nog besproken zal worden, vooral bij die bedrijven zelf.

Dat is dus de vraag in het artikel.

[nasdude]

Ik kan wel een paar redenen bedenken

- per ongeluk apparatuur aangesloten op dezelfde PDU
- niet redundante apparatuur gebruikt voor een key element
- De A & B feed voor meer dan 50% belast zodat een enkele feed het niet kan uithouden
- apparatuur die zichzelf gecontroleerd uitzet bij slechts 1 voeding
- apparatuur die toch niet lekker blijkt te werken
- failover werkt, maar onder hoge load kan de resterende node overbelast raken
- te hoge inrush current bij de overschakeling naar een enkele voeding voor het gehele rack

[4tro]

Vooral die laatste is een vrij bekende in de grotere datacenters, voeding die normaal niet actief is krijgt ineens op zijn donder en begeeft het gewoon domweg.

[Saffie01]

Ik weet dat vroeger apparatuur met 2 volledige voedingen was uitgerust. Deze sloot je aan op "rode" en de "blauwe" groep. Die hadden hun eigen invoer (10kv trafo) en nobreak. Viel een groep uit draaide alles vrolijke verder op de andere groep en een volledige voeding.
Daarna kregen we "pizzadozen" met 3 50% voedingen, idee was leuk bij uitval van een van de voedingen hield je 100% over alleen paste dit niet in de gebruikelijke 2 groepen structuur, want je moest 3 voedingen verdelen over 2 groepen en bij uitval van de verkeerde groep ging je server alsnog plat.
Ik weet niet of dit 3 halve voedingsysteem ooit is over genomen door gerenomeerde router en switch fabrikanten maar het geld wat je bespaard op je voeding kan je weer dubbel en dwars uitgeven aan een derde groep met bijbehorende invoer en nobreak. Bij ons werden de "pizzadozen dan ook om en om met 2 voedingen op rood en de volgende met 2 voedingen op blauw aan gesloten. Dus bij uitval van een groep ook uitval van de helft van de servers.
Mogelijk heeft dit iets met de oorzaak te maken, maar ben al te lang de ict uit om dit met zekerheid te kunnen zeggen.

[mjl]

Ik zie nog steeds gewoon 2 of 4 voedingen in apparatuur, je moet gewoon slim de boel aansluiten, inderdaad 2 aanvoeren vanaf verschillende transformatoren, goed zorgen dat elk stuk hardware dus op beide transformatoren uit komt en de UPS-en ook over beide aanvoeren verdelen. Elk device 1x directe voeding en 1x UPS. En in de BIOS de voedingen als redundant instellen en zorgen dat beide voedingen voldoende capaciteit leveren voor het hele systeem.

[Saffie01]

Uit het verhaal van Rido78 haal ik wat anders vwb. 4 voedingen.

[mcDavid]

Allemaal denkbaar idd. Daarnaast heeft geen enkel stukje hardware het eeuwige leven. Zo'n optater wanneer een voeding ineens 2x zoveel vermogen moet gaan leveren, kan net het duwtje zijn om hem naar zijn einde te helpen, terwijl die in "normaal bedrijf" nog perfect functioneerde. Kwestie van dikke pech dan.

Je kunt natuurlijk wel stellen dat je dergelijk kritische apparatuur misschien geheel redundant zou moeten uitvoeren (ipv enkel de voeding). Of een recovery strategie met minimale downtime zou moeten hebben. Laten we wel wezen die 51 seconden waren het probleem niet, de slepende problemen die volgden wel.

[Reactie gewijzigd door mcDavid op 17 november 2025 21:46]

[Nox]

Wij hebben een uur downtime gehad. Vervelend? Ja. Crisis? Nee. Als je geen uur zonder Internet kan dien je maatregelen te nemen om dit te voorkomen. Een extra verbinding was dan een prima oplossing.

[dasiro]

"if you didn't test it, it's not a backup"

Dit principe gaat jammer genoeg op voor héél veel oplossingen, niet enkel voor backups, maar ook voor disaster-recovery oplossingen. IT-managers durven er wel gigantische budgetten besteden (wat goed is), maar als je om praktijktesten vraagt, dan gaan ze plots op de rem staan en op de theorie vertrouwen.

Je wil niet weten hoeveel SLA's er in zulke situaties gebreached worden of ongeldig verklaard simpelweg omdat iemand ergens iets over het hoofd heeft gezien.

Andere vragen die hen doet schuifelen op hun stoel zijn: "wat is het ergste dat er mag failen" en "hoeveel backups zijn genoeg".

Uiteindelijk zal er altijd wel ergens een SPOF zijn dat te complex, duur of onwaarschijnlijk is om een alternatief voor te voorzien. Als je héél je omgeving volledig in kaart hebt (inclusief underpinning contracts), zou je daar een antwoord op moeten kunnen geven en dan gewoon maar hopen dat het worst-case scenario geen realiteit wordt. Hoe groter de omgeving, hoe onwaarschijnlijker het zou moeten zijn dat er niet genoeg redundancy is, maar net zoals de BGP-perikelen van een paar jaar geleden kan je soms héél ver in de supply-chain pas de oorzaak vinden die een waterval-effect kan hebben waar je als voorbeeldige beheerder/manager in de verste verte niet aan zou kunnen gedacht hebben en gaat heel je omgeving down en laten we eerlijk zijn: er waren vandaag meerdere van zulke mensen die met hun handen in de lucht moesten zeggen: de leverancier heeft een probleem.

[demianmonteverd]

- De A & B feed voor meer dan 50% belast zodat een enkele feed het niet kan uithouden

Herkenbaar, heb deze vaker gezien, staat absoluut in mijn top 3.
Vaak heeft een limiet van wat je kunt trekken en past het gewoon niet meer en dan prikt men 'bij' en rapporteert, rapportage word tijdelijk genegeerd en weken later kijkt men opnieuw bij testen. Als je dan niet goed checked, dan blijft de fout lang staan en krijg je problemen.

Deze is ook briljant:
- apparatuur die zichzelf gecontroleerd uitzet bij slechts 1 voeding

Dit is een uit de oude doos (gelukkig tijd niet meer gezien), soms staat er ergens een setting in de firmware en gaat deze verloren bij het updaten van de firmware.

[Adm.Spock]

Daarom wordt elke feed dus bij een goed ontworpen installatie ook voor maximaal 30% belast, dan heb je nog "headroom" om de piek op te vangen.

Een 50-50 verdeling uit kostenbesparing is gewoon fout beleid. Helaas zie ik dat wel vaker dat installaties op land ernstig ondergedimensioneerd zijn voor de belasting die er op aangesloten is, met als resultaat dat als er een feed uitvalt, wat gewoon kan gebeuren als een voeding defect raakt en sluiting maakt, de tweede feed met 50% al te zwaar belast is en dus dipt met als gevolg dat de voedingen die voor 50% belast zijn door de knieën zakken....

Laat ik zeggen dat de installaties die ik voor offshore heb ontworpen elke feed, en elke voeding, voor maximaal 30% belast mogen zijn onder normaal bedrijf, en dat dat ook ingeregeld en getest wordt. Voordeel is wel dat je bij offshore installaties natuurlijk met maar 1 klant per object/locatie te maken hebt, en ze ook snappen dat je met enige regelmaat gewoon de schakelaar van een feed uitzet om te testen dat het ook daadwerkelijk werkt zoals bedoeld. En ja, als ik op locatie ga met een team, dan hebben we ook een container met reserve onderdelen, want er gaat wel eens een voeding (bijna) kapot bij zulke testen. En ja we meten en loggen op heel veel posities de spanning én stroom.

Evengoed, blijft natuurlijk lullig als een of andere Muppet beide redundante voedingen op dezelfde feed aansluit.....

[Dorank]

Dat is een geldige conclusie. Onze meuk in nikhef is gewoon netjes aangesloten op beide power feeds en hadden dan ook geen last van de onderbreking.De poorten die op de router down gingen toonden wel aan dat we interconnects hebben met andere partijen in Nikhef die dezelfde fout als Odido en Eurofiber wellicht gemaakt hebben.

[Nox]

Ik ken Nikhef niet, maar veel datacenters hebben meerdere hallen, meerdere power distribution systemen etc.

Dat in hal1 feed A wegvalt, en als gevolg feed B het niet trok betekent niet dat in hal2 of hal3 exact hetzelfde gebeurde. Dus dat jij geen last had van dat probleem stelt niet dat EF/Odido exact hetzelfde probleem hadden.

Vaak worden racks zelf ook nog voorzien van een eigen zekeringautomaat, het kan best dat die niet goed werkte bijvoorbeeld. Zolang er geen conclusie is van wat er gebeurd is, is het opnoemen van logische oorzaken en gissen naar welke daadwerkelijk van toepassing was.

Overigens gebruikt Odido de diensten van Eurofiber, dus het een kan ook het gevolg van het ander zijn.

[Blockchain]

Maar betekent dit dan eigenlijk dat Odido en Eurofiber hun routers niet correct redundant hebben aangesloten?

Of switches, servers, multi-plexers of iets anders. En er hoeft maar één SPOF uit te vallen om de hele keten mee te trekken natuurlijk. Maar verder is dat inderdaad een terechte vraag die je stelt. Hopelijk trekken ze hier hun lessen uit.

[CPV]

Bij ons moest een aantal jaren geleden 1 rail van het dubbelrailsysteem in onderhoud. Voor de zekerheid heeft men toch maar eens de vloeren opengemaakt om de aansluitingen van de apparatuur op de rails te controleren. Een fix aantal stekkers was maar ergens ingestoken, terwijl ze voor een dubbel rail systeem bedoeld waren.
Hetzelfde toen ik eens de internetverbindingen van een virtual tape server met volledig redundante verbindingen naar 2 gescheiden netwerken controleerde. Men had een aantal stekkers maar ergens ingestoken.
Ja, dat gebeurt blijkbaar dus gewoon.

[Groningerkoek]

Wij werkten met een kleursysteem voor de voedingen.

Waarbij het primaire en secundaire systemen elk een eigen kleur hadden voor contactdozen, stekkers, lasdozen e.d.

In mijn ervaring kun je systemen nog zo redundant maken als je wilt, maar zonder zeer duidelijk fysiek onderscheid is het een kwestie van tijd voor je redundantie om zeep gaat. nog beter om het zelfs fysiek onmogelijk te maken dat de primaire en secundaire stekkers op elkaars voedingen passen, maar dan heb je weer het probleem dat mensen geen goede kabel kunnen vinden dan maar 2 primaire snoeren aan de server hangen als "tijdelijke" oplossing.

[moonlander]

Je vergeet: testen! Je kunt het soms nog zo mooi uitdenken, maar als je het niet test dan weet je ook niet of het werkt.

[Blokker_1999]

En dat is 1 van de punten waarvan ik zie dat het misgaat, zeker op hardware niveau. Een failover testen gebeurd regelmatig, maar als je dan vraagt of je eens een hardware failure kunt doen, waarbij je dus een switch of een heel stekkerblok uitzet, dan krijg je een negatief antwoord.

Bij mijn vorige werkgever gingen we op een gegeven moment 1 van onze DCs neerhalen omdat we core routers moesten vervangen. Dan zeg ik dus: ideaal moment om de failover eens te testen. Maar neen hoor, soft failover op voorhand en alles netjes neergebracht.

Zucht ...

[jongetje]

Dat is ook niet het juiste moment om te doen. Je wilt niet een migratie en een failover tegelijkertijd testen. En wat is de toegevoegde waarde als je een paar dagen erna je corerouters gaat vervangen?

Verder weleens betrokken geweest bij disasterrecovery/uitwijk testen. De engineers waren 3 dagen aan klungelen, helft van de servers werkte in de uitwijk. Conclusie, test niet helemaal geslaagd. Volgend jaar nieuwe ronde nieuwe kansen... Oftewel, management heeft het op papier allemaal geregeld en als er echt iets gebeurd "doen we ons best maar laten we hopen dat we het niet nodig hebben". En dit was niet bij 1 bedrijf of een MKB-er. Zijn serieuze multinationals die zo werken, enorme berg aan consultants, uren vergaderen en documenteren. En de handjes worden allemaal uitbesteedt want daar moet een paar euro op bespaard worden.

[SPee]

Zelfs gehoord dat bij een failover test het netwerk gedeelte niet werd meegenomen. "teveel gedoe" of andere bs excuus, dus daar is nooit een noodsituatie getest. En toen er een keer een echte storing was, duurde het een tijd voordat eindelijk de netwerkrouter als schuldige werd aangewezen. Na veel gedoe gaf iemand die "toch maar" een schop en daarna werkte alles weer.

Als je bepaalde onderdelen delicaat moet behandelen, dan moet je kijken of dat wel goed geregeld is en of dat niet ooit voor problemen gaat zorgen. Want als het een keer echt fout gaat op dat onderdeel, heb je vaak grotere problemen, omdat je het niet op orde hebt.

[MrFax]

Dit moet je dus ook goed doen en documenteren voordat het live gaat. Daarna nog gaan testen wordt lastig...

[TomPlant0]

Als je live bent moet je het juist ook testen. Doe het dan in de nacht of op een moment dat de service niet druk is. Wij testen elke jaar meerdere keren. Zowel in de nacht als op de dag (deze is toch altijd spannender).

[MrFax]

Bij sommige dingen wordt dat toch een klein beetje lastig, al kan het wel. Bij bijv. DWDM apparatuur voor een glasvezelnetwerk kan je nadat het live gaat niet meer zomaar de A/B redundancy gaan testen. Het kan wel, maar is zo risicovol dat je dat normaliter niet meer doet.

[metalmania_666]

Ik heb bij een grote bank gewerkt, en daar moest een uitwijk plaatsvinden, zoals wel vaker gebeurde.

Echter nu ging zowel productie als test plat. Oorzaak bleek uiteindelijk te liggen in het feit dat er 1 connectie niet dubbel was uitgevoed. Alle voorgaande keren dat er geswitched was, was er niks aan de hand.

Blijft mensenwerk

[demianmonteverd]

Maar goed dat het getest werd.

[Hidrolix]

Interessant, eenzelfde ervaring hier. Tijdens wisselen van stekker blokken waar de server op aansluiten.

Waren de volgende problemen naar voren gekomen:

- A en B door elkaar gehaald en soms dus ook 2keer hetzelfde pad.

- Stekker zat er in, voedingen allemaal groen, echter zodra belasting op ging, zat de stekker toch niet helemaal 100%.

- Diverse voedingen overleden tijdens omschakelen van paden.

- Server voeding instellingen stonden verkeerd. Had dus 2 power supplies en kon op 1 draaien, maar servers deden gracefully shutdown als 1 server uitging.

[Naafkap]

Het is toch wel weer vervelend voor (de klanten van) Odido dat juist zij er weer zoveel last van hadden. Het lijkt dus toeval, maar in de tijd van T-Mobile waren er vrijwel geen storingen van deze aard.

[Dennism]

Toch vraag ik me wel af hoeveel mensen er nu echt last van hebben. Ik zit privé bijvoorbeeld bij Odido en heb van de storingen de laatste tijd maar 1x echt merkbaar last gehad. Toevallig zit mijn werkgever ook zakelijk bij Odido, en vandaag ook geen enkele melding gehad van gebruikers met problemen .

[Naafkap]

Ik zit privé bij Odido en heb van alle recente storingen last gehad.

[Dennism]

Misschien toch iets regio gebonden dan ofzo? Zowel ik als mijn werkgever zitten in de regio oost-Nederland. Geen idee natuurlijk waar jij zit, maar als dat ook oost-Nederland is, kan die theorie ook het raam uit.

[ArjanBril]

Ik had ook last de storing vandaag en woon in Twente. Ook mijn werkgever had er wat last van het klapperende mobiele netwerk. Van de afgelopen storing was het prive voor mij alleen nog een keer de vaste verbinding die er een paar uur uit heeft gelegen, maar goed was in de avond meer en naja, dan ff geen tv kijken

[SMSfreakie]

Bellen ging prima.. Echter een stabiele 4/5G datalink was moeilijk...

Na 2 a 3 min disconnecte de handel en pakte wel meteen weer op.. Net of er nog ergens capaciteit miste en door data intensere gebruikers af te kappen. Er ruimte te behouden..

In de middag werkte 't allemaal weer feilloos

[kami124]

De meeste problemen lagen bij de DNS server, als je een andere DNS server dan die van Odido gebruikt, heb je tot nu toe heel weinig last gehad van de problemen. Vanochtend had ik ook maar 1 minuutje last, omdat ik een andere DNS server gebruik.

[Odie]

Privé met mijn ftth nergens last van. Op werk waar veel Odido Sims circuleren was de impact wel merkbaar.

[3raser]

Mijn Odido ftth had wel ergens last van, en dat duurde ongeveer 1 minuut. Dus van alles wat na de stroomstoring kwam had ik blijkbaar weer geen last.

[Zezura]

Bij mij ging vandaag mijn WAN 2 (als back-up) ook down.

Dat is een Odido prepaid 4G+ verbinding.

[PizzaMan79]

Ik heb zo vaak storing bij Odido de laatste tijd, dat het voor mij meer dan pech of toeval lijkt. Met mijn andere sim in dezelfde telefoon op 50+ (Vodafone) nooit problemen.

[ucsdcom]

Het is toch wel weer vervelend voor (de klanten van) Odido dat juist zij er weer zoveel last van hadden. Het lijkt dus toeval, maar in de tijd van T-Mobile waren er vrijwel geen storingen van deze aard.

Providers moeten aandeelhouders pleasen in een tijd dat de inkomsten niet meer makkelijk even verhoogd kunnen worden door nieuwe klanten te trekken. De markt is wel verdeeld en het aantal overstappers is laag. Het lijkt wel of alle providers nu bezuinigen op personeel en andere kosten. Lopen ze kans op hoge en veel boetes bij zakelijke klanten als het mis gaat? Of valt het aantal klanten met zo’n uptime garantie zo mee dat je er eigenlijk niet mee hoedt te rekenen? Service is ook bij de hoofdproviders al even niet meer hoe het geweest is en downtime is een te nemen risico geworden.

het zal niet veranderen. Dus dan maar genieten van het werk wat in een analyse op Tweakers wordt gestoken. Ja hier wel gelukkig..

[Andros]

De naam Belgacom in het artikel triggert mij, de naamsverandering naar Proximus dateert al van meer dan tien jaar geleden. Onder het linkje over "hebben hardware staan" komen we terecht op de site van Nikhef waarbij de link naar Belgacom uit komt bij een of ander Indonesisch gokhol. Bij Odido staat er nog steeds een link naar T-Mobile, als ze zelfs dat lijstje al niet wat up to date houden, welke indruk geeft dat voor de rest van dat bedrijf?

[donald_dick]

Dat ze er niet zoveel om geven.Is ook niet hun core business.

[Andros]

Dat kan maar hoe dan ook blijft het slordig. Is het nu zoveel werk om voor mijn part eenmaal per jaar iemand een dagje zo'n site even na te laten lopen?

[Henk Poley]

Mogelijk omdat Belgacom International Carrier Services (BICS) ergens nog steeds zo heet.

Website is nu wel: www.bics.com

[Reactie gewijzigd door Henk Poley op 17 november 2025 21:09]

[t-town]

Misschien gaat het niet over Proximus, maar BICS? Dit zou allezins het voortdurend gebruik van Belgacom verklaren.

[Microsoftman]

Kortom,50 seconden en dat bedrijf heeft niks in de gaten dat het een stroomstoring was.

Ik verwacht toch anno 2025/26 dat grootte datacenter een preciezere melding krijgt als er een storing optreedt.

[HijDieAllesWeet]

50 seconden is toch veel te kort om het weer op te lossen, en binnen een minuut liep de stroomvoorziening kennelijk weer goed. En zoals ik het artikel lees moet de klant dus zelf zorgen dat ze een korte tijd met 1 van de 2 stroomvoorzieningen moeten afkunnen. Dan heeft het bedrijf toch in principe niets fout gedaan?

[C0rnelis]

Soms is het lastig monitoren. Bijvoorbeeld meegemaakt dat op bepaalde supermicro hardware de cpu op de laagste kloksnelheid werd gezet na een hele korte stroomonderbreking die snel voorbij was - had redundante aansluiting. BIOS detecteerde niet goed dat de stroom weer helemaal terug was en bleef in die modus steken. Had de onderbreking 1-2 minuten langer geduurd, dan was er niets aan de hand geweest en was de server daarna weer op normale kloksnelheid teruggekomen

[jDuke]

Een stroomstoring van 50 sec op een enkele feed (van de 3) is niets, en kan wellicht wel een human error of werkzaamheden zijn. Het vervelende is dat Nikhef wel het connectiviteit datacenter is van NL en daar buiten, wat ik weet zit het in de top 5 wereldwijd. Dus als daar wat mis gaat is de impact groot en haalt het nieuws, het is niet zo dat het niet bij andere partijen voorkomt.

Wij als online Nederland hebben heel veel aan Nikhef te danken, het is daar groot geworden en door zeer schappelijke voorwaarden is het nog steeds een hele populaire lokatie om netwerken met elkaar te verbinden. Ik denk dat hier Odido zelf grootste blaam betreft doordat de impact zo groot en lang is geweest door een kleine stroomstoring.

[GeeBee]

Lang verhaal kort: de titel is niet juist, want de specifieke oorzaak is (nog) niet bekend en Nikhef doet er nog onderzoek naar.

[WhiteSnake76]

Hoe zo is de titel niet juist? "Hoe een storing van een minuut het netwerk van Odido urenlang liet wankelen"

Stroom storing duurde 51 seconde, en Odido had daarna uren lang problemen.

Er staat niks over de oorzaak in de titel.

[GeeBee]

Eurofiber: “We weten de oorzaak niet.”
Odido: “Het probleem is ‘een’ datacenter.”

Het halve artikel gaat over de interne organisatie van Nikhef terwijl het (nog) niet duidelijk is of de storing daar vandaan komt.

Je hebt gelijk als je zegt dat er niet staat “Hoe een stroomstoring *bij Nikhef* zorgde voor…”.
Dus ja: Nikhef had een stroomstoring, het ís een datacenter (hoewel mij de hoeveelheid opgeslagen data ter plekke klein lijkt, het is meer een knooppunt) en Odido, Eurofiber en ook Ziggo en KNP hadden ergens last van. Alleen het onderlinge verband is niet duidelijk.

[fuzzyIon]

Onderzoeken quantum fysica dat heeft niet perseen iets te maken met cyber sec toch?

[jurroen]

Ja en nee. CERN heeft een hele verdieping in een datacenter waar wij ook zitten en meerdere 400G uplinks naar Zwitserland (kan zijn dat de 800G upgrade er al door is).

Grootschalig onderzoek produceert ontzettend veel data. Security komt daar ook zeker om de hoek kijken - met statelijke actoren die maar al te graag toegang hebben tot die data. Als het niet is om mee te lezen, dan is het wel om het aan te passen en te ontwrichten.

[GeeBee]

Mijn opmerking gaat niet over het reguliere onderzoek van Nikhef, maar over het achterhalen van de oorzaak van de storing.

[_-= Erikje =-_]

Wat? Niets over Joke en haar kippen? pff, ik heb er destijds nog kilo's CAT onder de vloer geprobeerd te trekken, wat toen al niet makkelijk was met de tapijt tegels en de ontzagwekkende spaghetti onder de vloer.

[Odie]

Joke!! En niets over de sleutel-aan-houten-klosje die op de balie lag en die je kon grijpen nadat je tegen de balie-dame die allllltijd aan de telefoon zat (en veelal privé) iets van “ik kom voor amsix” had gepreveld? Niets over de vloer met tegels en tapijt? Niets over nachtelijk maintenance in een verlaten nikhef pandje (melden bij Sara!) dat helemaal verlaten toch een beetje spooky voelde?

[itlee]

Goed dat tweakers hier een artikel over geschreven heeft! adequaat gehandeld. Top!