Een deel van het netwerk dat plots uitvalt en klanten zonder verbinding zet, het is de nachtmerrie van elke serviceprovider. Het overkwam het onderzoeks- en onderwijsnetwerk Belnet in de nacht van 13 op 14 januari van dit jaar. Wat is er gebeurd en welke stappen leidden tot de uitval? Computable reconstrueerde samen met technisch directeur Dirk Haex van Belnet de neergang.
Een dag om nooit te vergeten, maar omwille van alle verkeerde redenen. Dat is ongeveer de manier waarop Dirk Haex van Belnet de 14de januari van dit jaar omschrijft. ‘De kiemen van dit incident liggen bij een ander incident, van augustus 2016’, steekt hij van wal. ‘Dat incident was groter van schaal, maar veel kleiner van impact. Ons complete netwerk was uit de lucht destijds, maar omdat het zomervakantie was en omdat de uitval duurde van ongeveer tien uur ’s avonds tot twee uur ’s nachts was de impact veel kleiner.’
Broadcast Storm
Dat eerste incident uit 2016 was een ‘broadcast storm’ (een zodanig grote hoeveelheid dataverkeer dat het netwerk platgaat), door een bug in het optisch netwerk. Als antwoord op dat incident startte Belnet in samenspraak met de leverancier een ‘service improvement programma’ op om heel zijn infrastructuur onder de loep te nemen en te hertekenen. Het programma bestond uit vier omvangrijke projecten. Het grootste was een volledig herontwerp van het Belnet-netwerk: dit omvatte de uitwerking van een business-case, de uitwerking en analyse van verscheidene design-scenario’s, de selectie van een nieuw design, een intensieve test- en validatieproces en finaal een geleidelijk implementatie van de nieuwe design.
‘Een van de kwesties die daarbij aan het licht kwamen, was een incompatibiliteitsprobleem tussen ons optisch- en ons ip-platform’, vertelt Haex. ‘Daardoor ontstonden er problemen met de ‘hashing’, het mooi verspreiden van de datapakketjes over de verschillende ethernetverbindingen. Als een van de allerlaatste stappen in dat ‘serviceverbeterprogramma’ hadden we in de nacht van 13 op 14 januari een onderhoud voorzien. En daar is het mis gegaan. Het eerste incident van 2016 is dus eigenlijk onrechtstreeks de trigger geweest van het tweede. Wat het eigenlijk des te pijnlijker maakt. Je moet ook weten: dit zijn ongeveer de enige twee incidenten van die omvang geweest die we ooit al op het Belnet-netwerk hebben meegemaakt.’
De bedoeling was dat er in die vermaledijde januari-nacht nieuwe software zou geïnstalleerd worden om het hashing-probleem definitief van de baan te helpen. ‘Het heeft even geduurd eer alles rond was, maar eind 2019 kregen wij bericht van onze leverancier dat die software klaar was. We zijn daarop met drie van onze netwerkarchitecten naar Londen gegaan en hebben daar gedurende drie dagen alle features tot in de details getest. En het resultaat was dat alles naar behoren werkte en dat we de nieuwe software in ons netwerk zouden opnemen.’
ITIL
Wanneer Belnet zo’n ingrijpende update wil doorvoeren, worden daarvoor de nodige change management-procedures gevolgd, zegt Haex, volgens de ITIL-methodiek. Er wordt een ‘change owner’ aangeduid die de volledige impact analyseert en een stappenplan uitschrijft. Dat stappenplan komt voor een change-advisory board die alles tegen het licht houdt, de veranderingen communiceert en inplant.
‘We besloten dat we de nieuwe software niet eensklaps naar alle 27 pop’s (points of presence of lokale knooppunten) zouden verspreiden, maar dat we met vier pop’s zouden starten: Brussel-Diegem, Kortrijk, Hasselt en Brugge’, legt Haex uit. ‘Het doorvoeren van de software-upgrade zelf zou gebeuren door een ingenieur van onze netwerkfabrikant, die zich daarvoor ook aan een nauwgezet stappenplan moest houden. In dat stappenplan stond eveneens aangegeven dat de pop’s een voor een zouden aangepast worden. Dus eerst moest een installatie gevalideerd worden voor er aan een volgende pop werd begonnen. In dat scenario was ook een roll-back-procedure voorzien. Dus als er ergens iets fout zou lopen, wist de ingenieur tot waar hij kon gaan om op zijn stappen terug te komen.’
De eerste pop die onder handen wordt genomen, is die van Diegem. Aanvankelijk lijkt dat vlot te gaan, maar op een gegeven moment loopt het mis. Haex: ‘Plots blijkt de upgrade te falen en moet de ingenieur een roll-back doen. Toen is er een eerste fout gebeurd: die roll-back heeft hij niet gecommuniceerd aan de Belnet-specialist, die de operatie mee coördineerde. Had hij dat wel gedaan, dan hadden wij natuurlijk alles stopgezet en waren de andere drie pop’s nooit aan de beurt geweest. Maar het wordt nog erger. Voor een of andere reden beslist de ingenieur daarop om de andere pop’s tegelijkertijd te upgraden, compleet in tegenspraak met het stappenplan. En ook daar gaat het fout. Wat hem bezield heeft, we hebben er het raden naar, maar hij drijft het zelfs zo ver dat een roll-back niet meer mogelijk was. En toen zat het spel op de wagen natuurlijk.’
De ingenieur van de netwerkfabrikant neemt, in paniek, in het holst van de nacht contact op met Belnet, maar al snel wordt duidelijk dat de situatie uit de hand gelopen is. De roll-back lukt niet meer, de databanken waarin de software zit zijn gecorrumpeerd en de pop’s liggen plat. Iets na zeven uur ’s ochtends wordt ook Haex uit zijn bed gebeld.
‘Aanvankelijk leek het erop dat de impact nogal mee zou vallen. De grote meerderheid van onze klanten zijn redundant aangesloten op verschillende pop’s, uiteindelijk kwamen we uit op een zeventiental klanten die geïmpacteerd waren. Daar waren enkele gemeenten bij die nog rechtstreeks klant zijn bij ons, Fluvius was er ook bij, net als een aantal sites van universiteiten en hogescholen. Aanvankelijk behandelden we het nog als een ‘major incident’, maar het werd al snel duidelijk dat het een echte crisis aan het worden was, zeker toen er op Twitter een stortvloed aan berichten begon te verschijnen over mensen die niet meer konden werken. Het ging wel over ‘slechts’ zeventien klanten, maar het aantal eindgebruikers achter die klanten was toch wel significant.’
Ondertussen, achter de schermen
Op dat moment wordt ook Davina Luyten, de woordvoerder, bij het incident betrokken. ‘We hadden natuurlijk scenario’s klaarliggen met richtlijnen over hoe we op bepaalde situaties moeten reageren’, vertelt ze. ‘Daarin wordt ook beschreven wie welke rol krijgt in de aanpak en hoe we communiceren. In dit geval waren dat Dirk als crisismanager die werd geholpen door een aantal technische mensen, ik als externe communicatiemanager en dan ook nog iemand voor interne communicatie. Dat we in crisis-mode gingen, had dus niet zo zeer te maken met het feit dat er maar zeventien klanten betrokken waren, maar wel met de impact van het incident en de weerklank in de media. Een paar hoger onderwijsinstellingen zaten bijvoorbeeld net op dat moment met online-examens. Dan is het niet verwonderlijk natuurlijk dat zoiets snel naar de oppervlakte komt.’
Vanuit Belnet wordt de communicatie meteen opgestart, zowel met de pers als met de klanten. Terwijl er regelmatig updates over de situatie worden uitgestuurd, proberen achter de schermen uiteraard ook de technici om de problemen zo snel mogelijk op te lossen. ‘Ik moet zeggen dat ik daarbij toch regelmatig het gevoel had dat de hulp die onze leverancier aanreikte niet bepaald, euh, adequaat was’, zegt Haex. ‘Ik had vaak de indruk dat ze niet goed wisten hoe ze dit konden oplossen. De eerste work around voor het probleem is zelfs quasi volledig door onze eigen mensen ontwikkeld. Die heeft er ook voor gezorgd dat de pop’s in Hasselt en Brugge in de loop van de namiddag opnieuw operationeel werden.’
Kortrijk was een complexer verhaal. Dit knooppunt was immers eerder op de dag – na advies van de leverancier – geselecteerd voor een alternatieve tijdelijke oplossing, namelijk via het herstel van de configuratiedatabase. ‘De oplevering van die nieuwe database door de leverancier bleef echter uit’, zegt Haex. ‘Op een bepaald moment hebben de Belnet-netwerkarchitecten dan zelf een alternatieve noodoplossing uitgewerkt. We zijn daar redelijk snel mee voor de dag gekomen, maar het heeft ook lang geduurd om ze te implementeren. De specialisten van onze leverancier hadden het immers lastig om die aanpak te valideren, dat heeft meerdere uren geduurd. En ik wou het risico niet nemen om dit zonder hun goedkeuring uit te rollen. Vandaar dat Kortrijk pas om drie uur ’s nachts opnieuw in de lucht is gegaan. Maar dan nog hebben veel Belnet-mensen gans de nacht doorgewerkt om zeker te zijn dat alles opnieuw werkte.’
Root cause
Op dat moment is het Belnet-netwerk opnieuw functioneel, zij het dus met een soort work around. ‘We hebben dan meteen beslist om voorlopig geen verdere aanpassingen door te voeren, zodat onze klanten konden werken, maar voor ons was het natuurlijk belangrijk om te weten wat er nu eigenlijk precies fout was gegaan’, zegt de technisch directeur. ‘Die ‘root cause’ is uiteindelijk door de fabrikant aan het licht gebracht nadat ze in hun labs al onze logs en configuratiedata hebben doorploegd. Wat wij in Londen hadden getest was puur functionaliteit en dat werkte. Maar wat bleek: in de procedure om van de oude naar de nieuwe situatie over te schakelen, bleek er nog een bug te zitten, met name in een aantal instellingen van de quality of serviceparameters.’
Bij Belnet wordt dan beslist om aan de pop in Kortrijk een nieuw, gepland onderhoud te doen. ‘Ik heb dan aan de fabrikant gevraagd om van A tot Z op papier te zetten hoe we dit probleem definitief uit de wereld kunnen helpen, met de absolute garantie dat alles zou werken. Ze hebben dat ook gedaan en dan een tijdje later, na de examens, hebben we’s nachts een nieuwe softwareversie doorgevoerd. En die is toen – gelukkig – van de eerste keer gelukt. Nu moeten ook nog alle andere pop’s naar die nieuwe software geüpgraded worden.’
Vergeten en vergeven?
Met de problemen die achter de rug zijn, is het incident voor Belnet natuurlijk niet ‘vergeten en vergeven’. Haex: ‘Wij hebben van één van onze klanten een ingebrekestelling gehad en wij hebben onze netwerkfabrikant zelf ook in gebreke gesteld. Hier hebben wij dus nog een hartig woordje over gesproken. We zullen bekijken welke financiële compensaties wij gaan vragen, maar we willen ook dat hier vooral lessen uit getrokken worden. Hoe is dit kunnen gebeuren? Zijn de procedures en processen die gehanteerd werden, wel de juiste? Wie heeft nu eigenlijk welke fouten gemaakt? Dat zijn zaken die wij uitgeklaard willen zien. Zelfs met die foute QOS-parameters had dit nooit kunnen gebeuren als het stappenplan was gevolgd was.’
Ook bij Belnet zelf zullen de procedures na deze ervaring aangescherpt worden, maakt Haex zich sterk. ‘We gaan dit in het vervolg nog formeler aanpakken, veel meer controles inbouwen en nog meer inzetten op risicomanagement, zozeer dat je eigenlijk geen assumpties meer moet maken. Ook die upgrade in een examenperiode had niet mogen gebeuren. Daar moeten we in de toekomst oog voor hebben.’
Ondertussen hebben er trouwens al overlegmomenten plaatsgevonden met de netwerkfabrikant. ‘Centraal daarin staat de erkenning van hun verantwoordelijkheid, met een bijhorende schadevergoeding en plan van aanpak’, besluit Haex.
Computable heeft de leverancier van Belnets netwerkapparatuur gecontacteerd voor een reactie. Deze wenste daar niet op in te gaan.
Wie is Belnet?
De roots van Belnet gaan terug tot 1993, als netwerkprovider van de universiteiten. Momenteel verzorgt de organisatie netwerk-, security- en applicatiediensten aan een keur van hogescholen, culturele centra, universiteiten, defensie, federale overheidsdiensten, het KMI en de VRT. Ook faciliteert Belnet de toegang van zijn aangesloten organisaties tot de publieke cloud. Er werken in totaal zowat tachtig medewerkers die 800.000 eindgebruikers bedienen. Het netwerk bestaat uit 27 pop’s en datacenters. Die laatsten kunnen zowel commerciële datacenters zijn waar carrier-neutraal met verschillende operatoren gewerkt wordt, alsook in datacenters van de overheid. Sinds 2008 beschikt Belnet over een hybride netwerk. Dat bestaat uit ruim tweeduizend km glasvezel, met daarbovenop een eigen IP/MPLS-netwerk.
