Klanten van Odido hadden het de afgelopen weken niet altijd makkelijk met hun internetverbinding. In anderhalve maand kampte de provider meerdere keren met een langdurige storing. Klanten tastten vaak uren in het duister over de oorzaak en het moment waarop hun verbinding hersteld zou worden.
Op 15 en 16 juni ondervonden gebruikers problemen door een storing in de DNS-servers. Een dag later hadden klanten in delen van Zeeland, rond Rotterdam en op plaatsen in Noord-Holland minder tot geen bereik door een kabelbreuk. Op 25 juni, rond de NAVO-top, had Odido meerdere storingen op zijn mobiele netwerk. Op 1 augustus volgde de zwaarste storing: een deel van de klanten was 15 uur offline.
Voor die laatste storing besloot Odido zijn klanten twee euro compensatie te geven. Dat ligt boven het wettelijk minimum van één euro, maar volgens veel klanten is het een schamele vergoeding voor de problemen die zij eind juni tot begin augustus ondervonden. Veel tweakers voelen zich, in reacties en op ons forum, flink afgescheept met dat bedrag en vragen zich niet meer af óf, maar wanneer de volgende storing zich aandient en of die weer een half etmaal gaat duren. Terechte vragen, waarvoor Tweakers aanklopte bij Johan van den Branden, de chief networking officer van de provider. Want hoe kan het dat een provider zo vaak last heeft van storingen?
We zitten hier omdat jullie de afgelopen maanden meerdere keren storingen hebben gehad. We beginnen bij de grootste: op 1 augustus lagen sommige delen van het netwerk er 15 uur uit. Wat gebeurde daar precies?
Van den Branden: "De afgelopen drie jaar zijn we bezig om het mobiele netwerk volledig te moderniseren. Onderdeel daarvan is ook dat we ons hele IP- en transportnetwerk grotendeels vernieuwd hebben. Als onderdeel van de laatste fase van deze vernieuwing hebben we configuratie toegevoegd aan ons IP-corenetwerk als voorbereiding op verdere migraties in het aggregatienetwerk. Met de configuratieverandering hebben we een bug getriggerd die deze desastreuze impact heeft gehad."
Je hebt het over een bug, dat is vaag. Kun je meer uitleg geven?
"De configuratieverandering zorgde ervoor dat de routingtabellen in een van de corerouters gecorrumpeerd raakten, waardoor al het IP-verkeer in een black hole terechtkwam. Daardoor moesten we uiteindelijk een soort hard reset doen om die configuratie weer terug te krijgen. De standaard procedures, zoals een simpele reboot, hielpen helaas niet. We hebben daarom een herconfiguratie van die router op locatie moeten doen."
Hoe kan het dan dat die storing zo lang duurde? Duurt het herconfigureren van de router vijftien uur?
"Het grootste deel van de storing was opgelost toen we die corerouter geherconfigureerd hadden. De bug had echter ook impact in de IP-aggregatiering die aan de corerouter verbonden was. Daardoor hebben we op alle twaalf aggregatielocaties individueel en fysiek dezelfde actie moeten uitvoeren als op die corerouter."
Waardoor werd die storing in die ring veroorzaakt?
"De node waar het probleem is ontstaan, is een landelijke corenode. Op het moment dat wij die landelijke node hersteld hadden, had hij zijn routingtabellen echter al doorgezet naar de regio, in dit geval de Rotterdam-ring en een deel van Noord-Holland. Daarom bleven klanten daar last houden van de storing en moesten we bij die specifieke nodes langsgaan om die allemaal te herstellen."
Is dat een moeilijke procedure?
"Nee, vooral tijdrovend. Je moet ernaartoe rijden, een laptop aan het apparaat hangen en de configuratie opnieuw opbouwen. Het is een standaardprocedure. Het zijn commandfiles die je moet inladen. Daarom duurt het dus lang. Het is een tijdrovende procedure die je eigenlijk nooit nodig zou moeten hebben, omdat al die andere herstelprocedures zouden moeten werken."
Van den Branden zegt dat de bug werd veroorzaakt door een probleem in de software, maar noemt niet welke leverancier dat is. "Ik kan door afspraken helaas niet publiek de naam noemen. We hebben natuurlijk contracten en afspraken waardoor we de naam van de leverancier niet direct openbaar kunnen gebruiken."
Contracten beperken informatievoorziening
Dat was niet de enige storing; tijdens de NAVO-top in Den Haag, misschien wel het slechtste moment om een storing te hebben, kregen klanten geen verbinding met het mobiele netwerk. Volgens Van den Branden werd de storing veroorzaakt door een overbelasting van het netwerk. Die ontstond doordat apparaten continu hun verbinding verloren met het netwerk en daarna opnieuw verbinding probeerden te maken. "Dat noemen we een signalling storm en daar zijn beveiligingsmechanismen tegen. Die zorgen ervoor dat er een rem zit op het aantal apparaten dat per seconde kan worden toegelaten, om te voorkomen dat achterliggende systemen omvallen."
Odido zag rond 9.00 uur de eerste problemen en dacht even later dat die opgelost waren. "We wisten toen nog steeds niet waardoor die apparaten de verbinding hadden verloren, maar we dachten: het gaat nu goed. En toen zagen we om 9.30 uur hetzelfde effect. Dat effect hebben we een aantal keer gezien, waardoor we continu in een soort overloadsituatie zaten, met meer belasting dan we ooit voor mogelijk hadden gehouden. Daardoor werd de stapel van klanten die wachten op netwerktoegang steeds groter. Dan werken die beveiligingsmechanismen uiteindelijk ook niet meer. Uiteindelijk hebben we rond 12.00 uur besloten om iedereen van het netwerk te gooien om dat patroon te doorbreken. Het is alsof je een dijk optrekt voor een heel heftige storm. Maar in dit geval was de storm heftiger dan onze allerergste nachtmerrie."
Hoe kan het dat die apparaten continu de verbinding met het netwerk verloren?
Van den Branden: "De oorzaak daarvan ligt bij een externe partij waarmee we helaas een strakke non-disclosure agreement hebben. Daarin staan ook boeteclausules als we daar iets over communiceren. We zijn wel in alle transparantie in gesprek met overheidsorganisaties die hier natuurlijk ook de details van willen weten. Maar wij mogen het verhaal niet namens deze partij vertellen. Die partij vertelt het direct aan de desbetreffende instanties."
"Dus je zegt dat jullie gebrekkige communicatie het gevolg is van een contract met een leverancier dat jullie dat verbiedt?"
"Klopt. Dat is heel frustrerend, maar wel de realiteit."
Waarom sluit je zulke contracten dan af? Voor klanten maakt het weinig uit of die storing door externe software of hardware komt. Die ziet alleen dat hij niet kan bellen.
"Klopt. Ik kan daar geen goed antwoord op geven, laat ik daar eerlijk over zijn. Het is geen softwareboer om de hoek, want anders hadden we dit contract niet gehad."
Ik geloof best dat het een grote partij is, maar is er geen andere grote partij die zoiets levert?
"Dat is natuurlijk wel iets waar we naar kijken. De externe partij in kwestie garandeert ons dat het niet meer gaat gebeuren, maar het is een nieuw scenario waarmee we wel rekening moeten houden en waarop we voorbereid moeten zijn."
Onderzoek
Uiteindelijk is door de grote hoeveelheid aanvragen de Authentication, Authorization and Accounting-server, ofwel de AAA-server, omgevallen, vertelt Van den Branden. "Een van de eerste dingen die we hebben gedaan, is de capaciteit daarvan verdubbelen. Daarbovenop hebben we nog een onderzoek lopen over hoe we die 'toegangspoort' verder kunnen beveiligen."
Waar kijkt dat onderzoek naar?
Van den Branden: "Het onderzoek richt zich op het scenario dat we hebben gezien, waarbij een aantal toestellen repeterend op je netwerk wordt toegelaten. Dat ging bij deze storing zo snel, dat er steeds meer mensen bijkwamen en de 'stapel' steeds groter werd. We onderzoeken hoe we dat effect in de toekomst kunnen mitigeren. We hebben een toegangspoort met drempels en timers ingesteld. We zijn tests aan het doen om te kijken, voor het geval dit voorvalt, of we de thresholds hoger kunnen maken. Wat betekent dat voor die keten daarachter? Zo willen we ervoor zorgen dat de achterliggende systemen niet de bottleneck worden. De eerdere instellingen waren voldoende voor de standaardscenario's, maar het werkt dus niet als er apparaten herhaaldelijk verbinding proberen te maken."
Waarvoor zijn die drempel en timers?
"Het zijn instellingen waarmee je bepaalt hoeveel verzoeken je per seconde toelaat op het netwerk. We voeren nu tests uit om te kijken wat er gebeurt als we bij een herhaling van dit scenario meer verzoeken toelaten, bijvoorbeeld tienduizend verzoeken in plaats van duizend per seconde. Wat betekent dat voor die keten daarachter? Zo willen we ervoor zorgen dat de achterliggende systemen niet de bottleneck worden."
Dus jullie houden er rekening mee dat dit opnieuw gaat gebeuren?
"Nou ja, men heeft ons natuurlijk bevestigd dat het niet meer gaat gebeuren, maar aan de andere kant moeten we er wel rekening mee houden dat dit een scenario is dat in de toekomst weer zou kunnen voorkomen. Daar moeten we ons op de beste manier tegen beveiligen. Het is natuurlijk onze taak om dit nooit meer voor te laten komen."
Hoe ga je dat doen?
"We hebben ons eigen onderzoek hierop lopen en we hebben een externe partij gecontracteerd die een tweede opinie hierop loslaat en ook eerder vergelijkbaar onderzoek heeft gedaan bij andere providers. Die kan onze instellingen vergelijken met die van andere netwerken. We hebben ook de externe partij in kwestie erbij betrokken en een audit lopen op hun verhaal. Zo zijn er drie onderzoeken die er uiteindelijk toe moeten leiden dat dit nooit meer gebeurt en dat we beschermd zijn tegen dit scenario. De eerste verbeteringen zijn met de nieuwe instellingen en capaciteitsupgrades inmiddels ook al geïmplementeerd."
Ook storingen door fysieke problemen
Dan heb je als provider alle softwarematige problemen gehad, en komen er ook nog fysieke bij. In juni knakte een kabel vlak bij Rotterdam. Maar in plaats van dat alleen daar een beperkte groep huishoudens even offline ging, trad de storing op in delen van Zeeland, rond Rotterdam en op plaatsen in Noord-Holland. Die storing duurde van 10.30 uur tot ongeveer 17.00 uur. De dagen ervoor konden gebruikers door een storing in de DNS-servers ook problemen ervaren. De twee DNS-storingen, op zondag en maandag, duurden ongeveer een uur.
Bij alle problemen, ook rond de kabelbreuk en de DNS-servers, leken de storingen grote delen van het land te treffen. Hoe kan dat? Is jullie netwerk zo gecentraliseerd?
Van den Branden: "Als het een corenetwerkelement betreft, dan … Uiteindelijk komt alles ergens samen. Ons netwerk is zeker gedecentraliseerd, daar doen we alles aan. We hebben meer dan zestig aggregatielocaties in Nederland. We hebben datacenters die dubbel redundant zijn. Maar uiteindelijk komt het verkeer ergens samen, zoals bij DNS-servers. Je moet uiteindelijk ergens centraliseren. Als juist zo'n locatie of node geraakt wordt, kan dat deze impact hebben."
Wifi-extenders zorgden voor DNS-storing
De DNS-storing werd veroorzaakt door de wifi-extenders die klanten gebruiken, vertelt Van den Branden. De apparaten verloren gelijktijdig verbinding met het centrale modemmanagementsysteem, waardoor 'honderdduizenden' apparaten verbinding probeerden te maken met de fallbackserver. Die is ingeprogrammeerd op hostnaam, waardoor de extenders eerst een aanvraag moesten doen aan de DNS-server om te weten op welk IP-adres die hostnaam uitkomt. Dat gebeurde zo massaal dat de apparaten eenzelfde soort mechanisme veroorzaakten als bij de signalling storm, waarbij het systeem verzoeken gaat weigeren om te voorkomen dat de andere delen van het netwerk omvallen.
Wat hebben jullie gedaan om te zorgen dat dit soort storingen in de toekomst niet meer voorkomen?
Van den Branden: "We hebben nu als het ware twee DNS-servers: één voor het klantverkeer en de andere voor de devices zoals wifi-extenders en modems. Als die apparaten opnieuw de verbinding met het netwerk gelijktijdig verliezen en een DNS-verzoek doen, komt dat uit op een aparte DNS-server. Dan wordt die poort misschien overbelast, maar dan heeft de klant daar op zijn internetverkeer geen last van. Wij hebben er alleen zelf last van, omdat het beheer van het apparaat niet bereikbaar is."
Hoe is dat mogelijk? Als je modem geen verbinding kan maken met de DNS-server, dan heb je als klant toch geen internetverbinding?
"Klopt, maar het is dus een andere server, die alleen bedoeld is voor managementtoegang voor de repeaters en het modem zelf. Daarmee kunnen we bijvoorbeeld op afstand software-updates uitvoeren. Bij de DNS-storing deden de apparaten een DNS-query in plaats van het IP-adres direct te resolven. Dat veroorzaakte de belasting op onze DNS-server die het internetverkeer afhandelt. We hebben nu dus een splitsing gemaakt en hebben een aparte DNS-server voor dat managementverkeer. Mocht het nog een keer gebeuren, dan kan alleen die DNS-server overbelast raken."
Kun je daarmee garanderen dat DNS-storingen daardoor minder voorkomen?
"Ja. Ik kan niet garanderen dat het nooit meer gebeurt. Ik denk wel dat we 100 procent zeker weten dat we het incident dat we nu hebben gehad isoleren door gescheiden DNS-omgevingen te gebruiken, waardoor in ieder geval de DNS-query's van de apparaten zelf niet het publieke internetverkeer kunnen verhinderen."
Verkeer omleiden bij DNS-storing
Voor veel tweakers is het inmiddels bijna standaardprocedure om de DNS-server van de provider in te ruilen voor de DNS-servers van een andere partij. Populaire alternatieven zijn Cloudflare, Google, Quad9, OpenDNS en DNS4EU. Deze ingreep zou Odido ook zelf kunnen doen aan de providerkant. Daar hoeven klanten echter niet op te rekenen, zegt Van den Branden.
"Daar staan de providers niet direct open voor", reageert hij. "Wat er natuurlijk gebeurt, is dat wij mogelijk een miljoen klanten zouden omleiden, afhankelijk van de impact van de storing. Dat lijkt voor hen ook een soort DDoS-aanval. De tweakers doen het en dat is ook prima. We hebben natuurlijk ook gesprekken gehad met andere partijen, maar het is nu nog niet mogelijk om dit structureel te implementeren. We hebben inmiddels wel een opening met een van de genoemde alternatieven en gaan daarover verder in gesprek met deze partij."
Snelle tweakers of langzame communicatie?
Naast de storingen verliep ook de communicatie bij Odido bepaald niet altijd vlekkeloos. Sterker nog, op Tweakers regende het klachten van gebruikers. Updates kwamen vaak laat (Tweakers-gebruikers meldden vaak eerder dat een storing opgelost was dan Odido zelf) en de verklaringen voor de storingen waren vaak summier. Een bloemlezing:
- "Tijdens nachtelijke onderhoudswerkzaamheden aan een van onze datacenters zijn er problemen ontstaan op ons netwerk";
- "Deze problemen op ons netwerk zijn ontstaan door een technisch probleem in onze netwerksystemen die mobiel verkeer mogelijk maken";
- "Op dit moment speelt er opnieuw een probleem in de systemen die mobiel internet mogelijk maken";
- "Inmiddels hebben we oplossingen voor deze problemen in het mobiele netwerk geïmplementeerd."
De storing van 1 augustus begon middernacht en om 7.00 uur kwam het eerste bericht naar buiten. Vervolgens communiceerden jullie die ochtend tussen 7.00 uur en 10.30 uur minimaal. Waarom duurde het zeven uur voordat klanten iets hoorden?
Van den Branden: "Het is ons doel altijd zo snel mogelijk te communiceren en daar duidelijkheid over te geven. Dus het is niet zo dat daar een rem op staat. Uiteindelijk kunnen we bij zo'n storing als het onderzoek nog loopt alleen zeggen dat we ermee bezig zijn en ons best doen om het probleem zo snel mogelijk op te lossen. We hadden gehoopt dat die storing al om 7.00 uur opgelost was als de standaard herstelprocedures hadden gewerkt. Toen we erachter kwamen dat al die procedures niet werkten, zijn we natuurlijk direct gaan communiceren, omdat we dan inzien dat het natuurlijk langer duurt dan dat je hoopt dat het zou duren. Daar moeten we altijd de balans in vinden. En misschien moeten we daar ook leren van wat tweakers ons aanraden te doen."
Forumgebruikers meldden eerder dat zij weer op het netwerk kwamen dan Odido op zijn eigen pagina. Hoe komt dat?
"Je wilt pas communiceren als je zeker bent dat de oplossing stabiel is en voor iedereen werkt. Wij gebruiken dat forum bij storingen ook om te kijken wat mensen zeggen. Geloof mij dat tijdens zo'n storing mijn team ook meeleest op het forum en op allestoringen.nl. Het geeft ons bevestiging dat dingen werken of niet werken. Het is een waardevolle bron naast onze eigen systemen, maar we willen niet direct communiceren dat een probleem is opgelost als wij de lampjes weer op groen zien springen. Als we zeggen dat het opgelost is, willen we zeker zijn dat het ook stabiel is en vaak duurt het een kwartier tot een halfuur om te kunnen zeggen dat een node stabiel is en niet onderuit gaat."
Waarom doen jullie niet aan technische post mortems? Het enige wat klanten nu weten, is dat er problemen waren. Dat is ook een van de redenen dat we hier nu zitten.
"We hebben een specifiek team dat klanten informeert. De balans vinden tussen een verhaal dat je landelijk kan houden en een tweakercommunity die daar misschien meer naar op zoek is … Misschien is dat ook iets voor ons om over na te denken. De reden dat ik hier vandaag zit, is omdat ik natuurlijk begrijp dat er een publiek is dat wel behoefte heeft om het te snappen. Als ik naar de gemiddelde klant kijk, die wil alleen maar weten of het werkt. Waar het door ontstaan is, is niet zo relevant voor ze. Maar misschien is het iets voor ons om over na te denken. We hebben natuurlijk de laatste tijd wel nieuwsposts geplaatst over die storingen. Daarin geven we bijvoorbeeld ook aan dat het een DNS-storing was. Is jouw suggestie om nog verder de diepte in te gaan?"
Klanten zijn nu veel vertrouwen kwijt, niet alleen omdat het netwerk soms instabiel was, maar ook omdat ze geen idee hebben of het allemaal verbeterd is. Die onzekerheid heeft zeker impact.
"De belofte dat we het gaan oplossen en in de toekomst voorkomen, wordt wel altijd gemaakt. De technische details niet of in mindere mate in ieder geval. Dat is wel iets om te overwegen."
Die technische details geven juist per definitie concretisering. Iedereen kan zeggen: 'We gaan in de toekomst stappen zetten om het probleem te voorkomen.'
"Ja, fair point."
Verband tussen storingen?
Doordat de storingen zo kort op elkaar plaatsvonden, is een logische gedachte dat de twee storingen verband met elkaar houden. Die notie wijst Van den Branden echter fel van de hand: "Het waren totaal andere oorzaken. Te kort op elkaar? Dat moge duidelijk zijn. Maar ze hadden niets met elkaar te maken. De storing van 1 augustus hebben we zelf veroorzaakt door een wijziging die een bug veroorzaakte. De andere twee grote storingen kwamen door een externe partij."
Hebben jullie een concreet plan hoe jullie het vertrouwen van klanten willen terugwinnen?
Van den Branden: "Stabiliteit. Dat is een van de belangrijkste zaken waar mensen voor betalen. We hebben nu drie incidenten gehad, maar als je naar de benchmarks kijkt, denk ik dat er niets mis is als het werkt. Incidenten gebeuren bij elke provider. De intervaltijd tussen de storingen is natuurlijk te veel geweest, het was een opstapeling. Veel andere diensten gaan ook een keer per jaar offline door een storing. Zo simpel is het. Iedereen doet upgrades en veranderingen en het blijft mensenwerk. We testen natuurlijk wel vooraf, maar het is nooit honderd procent foolproof. Je blijft werken met partijen waar je afhankelijk van bent."
Storingen voorkomen is inderdaad het allerbeste, maar je wilt ze ook snel oplossen. Welke maatregelen neem je om dat laatste te doen?
"Sowieso door de leverancier direct bij de grote wijziging te betrekken. Dat helpt natuurlijk in de doorlooptijd. Als we enig risico verwachten, hebben we mensen op locatie. We nemen extra reserveonderdelen mee. Dat betekent nog steeds dat je een probleem kan veroorzaken, maar dan ben je sneller met een eventuele oplossing."
Ik mag aannemen dat jullie eerder ook al reserveonderdelen meenamen.
"Zeker! Alleen voorheen zou je misschien één engineer hebben in de regio waar we een upgrade doen. Nu hebben we misschien op elke locatie iemand staan."
Meer mensen dus?
"Dat is een van de opties, ja. Elke wijziging vraagt een andere aanpak en we doen duizenden wijzigingen per jaar. Als we de apparatuur op een relatief kleine infrastructuurlocatie vervangen, zijn er andere maatregelen nodig dan als we een corenetwerkelement vervangen. Elke wijziging heeft zijn set aan maatregelen om te zorgen dat het goed gaat. Al die maatregelen werken 99 procent van de tijd. Alleen als je dus uitzonderlijke scenario's tegenkomt waar je niet voor gepland hebt, is het natuurlijk zaak om het snel op te lossen. Het nadeel dat we hebben gehad, is dat we bij die storing van 1 augustus een bug triggerden die we niet konden oplossen met de standaard middelen en hierdoor niet binnen een halfuur konden oplossen. Anders hadden we een halfuur klachten gehad en was iedereen overgegaan tot de orde van de dag."
Klopt. Maar dat was niet het geval. Het netwerk kan nog zo snel zijn, maar als het drie keer down is in een maand, verliezen klanten gewoon vertrouwen."
"Dat is duidelijk. Het begrip voor de storingen is ook afhankelijk van het publiek. Is er wel of niet begrip voor de complexiteit, de hoeveelheid wijzigingen die wij uitvoeren en hoeveel werk het is om dit netwerk up-to-date te houden? Ik denk dat het Tweakers-publiek dat beter begrijpt dan dat van meerdere andere media. Ik begrijp het ook wel. En helaas veroorzaken we het probleem zelf twee keer niet, maar dan nog: voor de klant maakt dat niet uit. Die wil alleen maar stabiliteit."
Bij klanten blijft nu alleen plakken: bij Odido is drie keer storing geweest in korte tijd.
"Ja, en dat we niet meer investeren en dat deze storingen hier het gevolg van zijn. 'T-Mobile was goed en Odido niet!' Ik kan je vertellen dat we nog nooit zo binnen onze Deutsche Telekom-tijd hebben kunnen investeren in het netwerk als de afgelopen drie jaar en dat we ook vanuit aandeelhouders nooit zoveel middelen hebben gehad om het netwerk beter te maken."
Uit het bij de Kamer van Koophandel gepubliceerde jaarverslag van Odido blijkt onder meer dat de investeringen van het bedrijf in 2024 551 miljoen euro bedroegen, een stijging van 24,6 procent ten opzichte van het jaar ervoor. Dat kwam vooral door de aankoop van het 3,5GHz-spectrum en de modernisering van het mobiele netwerk, schrijft onder andere Telecompaper. Van den Branden: "Het is juist het tegenovergestelde van de perceptie. Ik begrijp de zorg, maar als je ziet hoeveel 3,5GHz we landelijk hebben uitgerold … Het plan is dat we voor het eind van dit jaar een fundering hebben die we niet meer hoeven aan te passen tot 6G komt. Dat is een enorme verandering. Als die klaar is, dan is het meer het onderhouden van het netwerk en het managen van de capaciteit. Dan hoeven we ook niet meer zoveel wijzigingen in ons netwerk te doen."
Redactie: Imre Himmelbauer • Eindredactie: Monique van den Boomen