Gepubliceerd: Woensdag 28 mei 2008
De recente, kolossale netwerkstoring op de ATM-backbone van KPN werd veroorzaakt door een softwarebug in switches van Alcatel-Lucent, zodat die 'overcapaciteit' toelieten.
Toon volledig artikel
Lijkt de regering wel, die draaien ook overal om heen als ze verantwoording moeten afleggen.
Of werken er soms veel ex-kamerleden en ministers bij KPN en/of alcatel?
Hoezo? Ze vertellen wat de oorzaak is van het probleem zonder de beschuldigende vinger te wijzen naar een bepaalde partij. Dat zie ik niet als "er omheen draaien".
En je vergelijking met kamerleden kan ik ook niet plaatsen...
Als je de vergelijking met de kamerleden niet begrijpt dan zou ik zeggen verdiep je eens in de actuele politiek en actuele zaken die er spelen.
Ze vertellen de oorzaak, maar is dat ook de oorzaak ? Wij krijgen alleen te horen wat kpn ons verteld.
Dat ze geen leverancier noemen, tja alcatel heeft geholpen en ik neem aan dat alcatel helpt als het om hun apparatuur gaat en niet om die van cisco lijkt me.
Ze vertellen de oorzaak, maar is dat ook de oorzaak ? Wij krijgen alleen te horen wat kpn ons verteld.
Precies! Ik heb ook kort na mijn geboorte een DNA test gevraagd om te controleren of mijn ouders wel mijn ouders waren. Want was dat wel zo? Ik kreeg alleen te horen wat mijn ouders mij vertelden. :P
Conspiracy thinkers... Got to love em. ;-)
Ik vind KPN hier toch behoorlijk openheid van zaken geven, tevens is dit een plausibele verklaring voor wat er gebeurd is.
Tuurlijk blijven er bij mij de volgende openstaande vragen :
1) Waarom vond de netwerk storing in de nacht plaats? Werd deze storing ge-trigger-ed door de hoogste data piek tot op dat moment?
2) Erg benieuwd naar de provisioning methode van het ATM netwerk. Het lijkt er op dat bij de uitval van 1 atm node, de backup node meer dan 2 x 50% load te verduren kreeg. Dit zou betekeken dat bit bitstream al aardig aan het vol lopen is en in geval van calamiteiten dit niet goed kan opvangen.
Zelfs als 1 datapiek 1 ATM er uit gooit moeten de overige dat kunnen oppakken lijkt me, zeker aangezien s'nachts er minder data over het netwerk gaat.
Waarom betrof het maar een gedeelte van het netwerk en niet het hele netwerk.
Of zou het verhaal van de mislukte updates er toch iets mee te maken hebben ? en is het verhaal wat kpn verteld nu een verhaal om gewoon iets te vertellen. Daarnaast lijkt me als de oorzaak die was die kpn nu moent dat men dat al veel eerder naar buiten had kunnen brengen, tenzij men deze oorzaak nu bedacht heeft ?
Niet dat ik zo super pro KPN ben, maareh,...
waar draaien ze nou precies omheen dan?
welk geheim wordt er hier onder de mat geschoven?
welke sinistere waarheid verschuild zich voor het daglicht?
Er was een storing. Vind de verbazing en verwarring nogal "gevaarlijk". Dit betekent dat niemand zich echt bezig houdt met calamiteiten en ons huidige dagelijkse manier van leven. Gezien de digitalisering, milieu problematiek en grondstoffen problematiek is dit niet de laatste en niet de grootste storing. Zijn we daar dan helemaal niet op voorbereid of wordt dit opgeblazen en was het allemaal niet zo ernstig, behalve overlast (hetgeen verdomde irritant kan zijn, maar dat is met zo veel zaken). Of zijn we echt bezig om al onze eieren in een verrot mandje te leggen en is iedereen te druk met KP, cybercriminaliteit en terrorisme om de daadwerkelijke problemen/gevaren te zien. Het zou dan wel een echte kopie zijn van de fysieke samenleving, ook daar is veel negatieve aandacht voor randverschijnselen i.p.v. de werkelijke uitdagingen.
Dat het te maken zou kunnen hebben met de snelheidsverdubbeling die XS4All momenteel doorvoert bij al haar klanten, kan Oudshoorn niet met zekerheid uitsluiten. Vorige week verklaarde Simon Hania, technisch directeur van XS4All, echter in Radio Online dat deze snelheidsupgrade geen rol kan hebben gespeeld, omdat 'die zorgvuldig gepland is en gefaseerd wordt uitgevoerd'.
Over de leverancier van de ATM-switches met de onvolkomen software geeft KPN aanzienlijk minder openheid van zaken. Sterker nog, het houdt angstvallig de kaken op elkaar.
Dat noem ik er omheen draaien. Zeg toch gewoon wat het is geweest, wie, wat, waar en waarom.
KPN communiceert absoluut niet open en al helemaal niet naar al die mensen die dagen zonder internet hebben gezeten. En ook niet voor wat betreft het uitkeren van schadevergoedingen veroorzaakt door deze storingen.
Huh? Voor een klant is dat niet interessant. Een consument begrijpt woorden als ATM niet, en interesseert zich daar vaak ook niet voor. De consument wil dat het gewoon werkt, eventueel een schadevergoeding, en een toezegginkje 'doen we nooit meer heh?'.
KPN heeft haar afnemers van het netwerk over geinformeerd en die afnemers hebben hun klanten geinformeerd. KPN is eigenlijk geen partij voor 'de consument'.
En voor de relatie tussen KPN en Alcatel-Lucent is hoog van de toren blazen over schadeclaims ook niet goed. Ze wachten eerst tot de storm is gaan liggen (bij zowel de klanten (ISPs, indirect consumenten), als bij KPN zelf), en dan hoor je over een tijdje hoe en wat. Ga er maar van uit dat van beide partijen een klein legertje advocaten (en techneuten) e.e.a. met elkaar aan het bespreken zijn ivm schadeclaims. Want de gedorven inkomsten ivm de SLA bij bijvoorbeeld bDSL wil KPN graag doorberekenen. ISPs zullen hetzelfde doen. De overige consumenten krijgen te horen... "pech, had u maar een SLA moeten nemen." kassa!
Goed item btw. Research (details, interviews), en technisch & taalkundig goed. Mag ook wel 'ns gezegd worden!
Hmmmm, oke ik begrijp al deze termen ook niet maar, maarre een softwarefout of bug, wordt toch gemaakt door de mensen die het programmeren, dus KPN had er wel verzekerd van moeten zijn dat het goed of minder problematisch zou gaan verlopen.
het vreemde vind ik wel
KPN en Alcatel zwijgen
als je niets te verbergen heeft en er onvoorziene omstandigheden waren, waarom dan zwijgen ????
maar ja ik ben geen IT-er dus ------.
Als je niets te verbergen hebt betekent nog niet dat je dit meteen aan de grote klok moet hangen.
KPN informeert de klanten en regelt het met haar leverancier(s). Hoewel het interessant is om te lezen, gaat het ons eigenlijk niets aan welke leveranciers dit zijn. Als je schade hebt moet je dat toch bij je ISP proberen te verhalen en niet bij de hun leveranciers.
WAT:Technisch naspeurwerk heeft uitgewezen dat een bug in de software van de ATM-nodes de grootste netwerkstoring ooit in Nederland heeft veroorzaakt. Dat bevestigt KPN desgevraagd aan Webwereld.
WAAR: In de nacht van maandag 12 op dinsdag 13 mei trad door dit mankement een overbelasting op in de ATM-backbone van KPN.
WAAROM: "De oorzaak zat in een softwarefout", stelt KPN-woordvoerder Bram Oudshoorn onomwonden. "In de switches zit een registerfunctie die capaciteitsaanvragen verwerkt. Dat register wordt ook geacht dubbele en driedubbele aanvragen eruit te wieden, om overbelasting te voorkomen. Maar dat laatste werkte niet, dat deed 'ie niet."
Dus eigenlijk gaat jouw klacht alleen over het WIE gedeelte. Zoals een andere lezer hierboven al stelde is het juist behoorlijk om niet openlijk met modder te gaan gooien. Het siert KPN juist dat ze niet de schuld afschuiven en roepen:"ik was het niet... hullie hebben het gedaan". Dat is nou net dat gedrag, waar jij zelf aan refereert, wat politici vertonen ("dat was de vorige minister van ..."). Uit een degelijke analyse over het ontstaan van deze storing kan namelijk heel wel komen dat het een configuratie fout was (schuld KPN) in plaats van een programmeer fout (schuld Lucent) en als je dan heel hard geroepen hebt dat het "HULLIE" was dan staan de advocaten van Lucent op de stoep met een (zeer terechte) claim over Imago schade.
Voordat je gaat blaten over "onder de mat schuiven" eerst even de grijze cellen gebruiken.
Precies.
Mischien was het wel een routerings fout van KPN waardoor er meer dan normaal verkeer naar een ATM switch werd gestuurd waardoor hij op z'n ... ging. Dat verkeer ging daarna door naar de volgende en dominoday of beter dominonight!!
Het is zwaar [piep] dat het gebeurt is maar shit happens en ze hebben er hard aan gewerkt om het op te lossen en de tijd genomen om het uit te zoeken en met een onderbouwd verhaal te komen.
Ook iets wat de politiek NIET doet. Er gebeurt iets en gelijk beginnen ze allemaal om het hards te blaaten om er vervolgens achter te komen dat ze onzin aan het uitbraken zijn, vaak met verstrekkende gevolgen. bv gas explosie in den haag en nog ergens anders in het land, "APK VOOR GAS"!!!! en vervolgs blijken het gasflessen te zijn en een zelfmoordpoging en gaat die APK helemaal nergens over.
"In de switches zit een registerfunctie die capaciteitsaanvragen verwerkt. Dat register wordt ook geacht dubbele en driedubbele aanvragen eruit te wieden, om overbelasting te voorkomen. Maar dat laatste werkte niet, dat deed 'ie niet."
Het gaat dus om slecht geteste software? Dit lijkt me immers niet een bug, maar software die niet conform de requirements is gemaakt en daar hoor je achter te komen voor er een release de deur uit gaat.
Ik denk dat slecht getest wat overdreven is, sommige dingen kunnen pas uit de praktijk naar boven komen. Er is niets, en dan bedoel ik niet alleen ICT, dat de echte praktijk kan simuleren. Er blijven altijd factoren die niet bedacht kunnen worden of te simuleren zijn.
Dat dit een aanleiding is om een andere manier van fail-safe te zoeken is geloof ik best wel, dat de KPN (en toeleverancier(s)) er alles aan gelegen is dit in de toekomst te voorkomen kan men wel als een feit zien. Er zullen velen er wel een leer uit trekken, netwerk technisch en afnemer kant gezien.
Deze verstoring lijkt wel heel erg veel op de klassieke (historische) software bug van AT&T van 15 january 1990 waardoor zowat heel de VS niet meer kon bellen. Het komt erop neer dat servers elkaar uitschakelen (laten herstarten) wegens software bug.
De klassieke oplossing die destijds daaruit geleerd en die elke profesionele IT-er zou moeten kennen om nooit de laatste dezelfde software op alle servers te zetten.
AT&T heeft er indertijd voor gekozen om een nieuwe release altijd op de helft van de servers te installeren (een volgende nieuwe release weer op de andere helft). Hierdoor loopt altijd één helft van de servers een release achter.
Dat is een les van inmiddels bijna 20 jaar oud die de KPN blijkbaar nog niet kent!
Dat zegt weer genoeg over de profesionaliteit van de organisatie.
Those who do not know (their competitor's) history are doomed to reimplement it, badly...
Hoe de fout in eerste instantie getriggerd is, kunnen ze waarschijnlijk niet meer achterhalen, maar met zo'n verhaal is dat in principe ook gewoon een tikkende tijdbom, en niemand weet wanneer die BOEM zegt.
Ik denk overigens dat pas bij het installeren van nieuwere software op een aantal swicthes om te kijken of het daarmee verbeterde, de enorme uitval is ontstaan: meerdere nodes in korte tijd rebooten, dus intussen moet het verkeer een paar keer een andere route gaan kiezen. En dan loop je veel sneller tegen overcapaciteit aan.
[Of zouden ze dit verhaal bedacht hebben om iets anders doms onder de pet te houden?]
Wat mij betreft is de grote boosdoener de automatische reset-functie bij overbelasting van de routers. Als een besluit te herstarten, om wat voor oorzaak dan ook, dan voel je op je klompen aan dat dat een kettingreactie kan geven in het netwerk.
Er zijn drie mogelijkheden:
1) deze functie was bekend bij de netwerkbeheerder
2) deze functie was niet bekend bij de netwerkbeheerder, echter wel gedocumenteerd, ergo de beheerder heeft zich niet goed op de hoogte gesteld
3) deze functie is alleen bekend bij de router fabrikant
Ik zou als netwerkbeheerder niet blij zijn met de wetenschap dat een router op eigen houtje kan besluiten om te resetten. Ik wil dat in de hand hebben; helemaal bij een landelijk netwerk.
Ik kan me herinneren dat een ex-collega het management op zijn blootje knietjes bedankte voor routers die automatisch resetten als ze vast liepen, omdat hij tot die tijd elke keer naar een centrale moest met zijn autootje om de oude met het handje te resetten.
Het inzetten van zulke routers betekent, dat je constant in de gaten moet houden of de router het nog doet. Bij veel bedrijven zal het er op neer komen dat gebruikers dus moeten gaan bellen. De 1e lijns gaat dan vast stellen dat een router is vast gelopen. Die escaleert het naar de 2e lijns. Die moet gaan uitzoeken welke router dan precies is vast gelopen. Indien het op locatie is, moet de 2e lijns contact op nemen met een operator (Of waarschijnlijker met de voorman van de operator). En pas dan wordt de router gereset. Dat kan lang duren, helemaal bij een landelijk netwerk.
En een router in een knooppunt, die niet automatisch reset, kan volgens mij net zo goed een kettingreactie veroorzaken als er een fout in de software zit.
Maar ik zal een ander merk klompen hebben, waardoor ik het anders aanvoel. ;-)
Dan schort er iets aan het hele router gebeuren. Er zou een detectiesysteem moeten zijn of een router het nog doet, mogelijkheid om op afstand te rebooten en eventueel per router instelbaar of deze automatisch mag rebooten. Communicatie tussen routers dat ze niet allemaal tegelijk gaan rebooten is ook een denkbare optie. Er zijn legio mogelijkheden.
Zal wel een kwestie van geld zijn dat het niet op die manier wordt opgezet...
Waarschijnlijk hebben de programmeurs aan exact dezelfde dingen gedacht die jij nu allemaal aanvoert. En toen kwam de bug in de software (Software is mensenwerk) die roet in het eten gooide. :-)
De titel zegt het al: Megastoring kwam door softwarefout. Je kan honderden veiligheidsschakelingen inbouwen in je router, maar er is maar één goed geprogrammeerde fout in de software voor nodig om ze allemaal te laten falen.
Trouwens... Op afstand rebooten als de router geen verkeer meer accepteert en communicatie tussen routers die door een fout niet meer communiceren kon wel eens lastig worden. Tenzij je de controleapparatuur aparte lijntjes geeft misschien.
De titel zegt het al: Megastoring kwam door softwarefout. Je kan honderden veiligheidsschakelingen inbouwen in je router, maar er is maar één goed geprogrammeerde fout in de software voor nodig om ze allemaal te laten falen.
Ja, maar wat doet de router vervolgens? Juist, resetten. En dat is bewust zo gemaakt. En daar heb ik mijn ernstige twijfels bij of je dat echt wilt. Juist om de gevolgen van softwarefouten te beperken.
Trouwens... Op afstand rebooten als de router geen verkeer meer accepteert en communicatie tussen routers die door een fout niet meer communiceren kon wel eens lastig worden. Tenzij je de controleapparatuur aparte lijntjes geeft misschien.
Mee eens. Dat gaat wel ver. Maar communicatie tussen routers of niet op alle routers reset-mogelijkheid aanzetten, lijkt me een reeele mogelijkheid.
We praten lang elkaar heen. Als een router door een softwarefout vastloopt dan moet het ding resetten. Of hij nou niet communiceert door een crash of door een fout in de software is lood om oud ijzer. Het communiceert toch niet.
Ik denk dat automatisch resetten vaker het probleem wel oplost dan niet.
Ik kan me geen beheerder voorstellen die het hele helpdeskcircus van handmatig resetten in het leven wil roepen omdat het soms misschien wel eens een keer mis zou kunnen gaan doordat een fout in de software zou kunnen sluipen.
Je lost liever de fout in de software op, dan dat je nuttige functionaliteit weggooit omdat je control wil houden in een situatie waarin je de controle sneller kwijtraakt door het handmatig te doen.
In een thuissituatie of een bedrijfje met één locatie en een paar honderd man zou ik nog control willen op dit vlak. In een landelijk netwerk is dat volgens mij niet meer te overzien.
Maar goed... Mijn mening, jou mening. De waarheid zal wel ergens in het midden liggen. Ik hoef het gelukkig niet te beslissen. ;)
Als iets stuk is op een manier dat alleen een reset nog helpt, laat die reset dan maar automatisch gaan. Moet je detectie natuurlijk wel goed zijn, maar daar is ook al genoeg ervaring mee.
Dat je daarmee misschien de impact van een bug groter maakt dan hoe die met handmatige resets zou zijn geweest, is helder. Maar als je door een reset ook andere systemen kunt laten omvallen, is het lood om oud ijzer.
Je kunt natuurlijk voor de en-en oplossing gaan. Een ISDN2-lijntje om ergens een reset-relais te kunnen bedienen is zeker voor KPN geen enkel probleem. Hooguit duurt het een maand voordat hij aangelegd is... :-P
Overigens verwacht ik dat die ATM-apparatuur voorzien is van allerlei snufjes om de status-monitoring onafhankelijk van de normale taken uit te voeren. Dergelijke watchdogs zijn al jaren gebruikelijk in vele soorten apparatuur. En als er dan een bepaalde "out of spec" situatie gedetecteerd wordt, kun je moeilijk gaan doen en proberen door arbitraire beslissingen de boel weer in het gareel te krijgen, maar een reset is dan doorgaans een veel handigere (en beter gedefinieerde) oplossing.
Voor de compleetheid de AT&T bug van bijna 20 jaar geleden:
January 15, 1990 -- AT&T Network Outage. A bug in a new release of the software that controls AT&T's #4ESS long distance switches causes these mammoth computers to crash when they receive a specific message from one of their neighboring machines -- a message that the neighbors send out when they recover from a crash.
One day a switch in New York crashes and reboots, causing its neighboring switches to crash, then their neighbors' neighbors, and so on. Soon, 114 switches are crashing and rebooting every six seconds, leaving an estimated 60 thousand people without long distance service for nine hours. The fix: engineers load the previous software release.
(bron: http://www.wired.com/software/coolapps/news/2005/11/69355?currentPage=all)
Wat de reden ook mag zijn dat de storing optrad, dit was echt een vervelende week voor zowel de gedupeerden als KPN zelf. Hoewel er vaak grappen worden gemaakt over de "Groene Rakkers" en is het makkelijk om de grootste speler af te kraken op bv. klantvriendelijkheid, ik vond KPN altijd wel een professionele organisatie. Deze storing is echt een klap in het gezicht van KPN wat betreft betrouwbaarheid, en dat is jammer. Ook vervelend is dat ik precies in deze week een OnCall dienst had. Ik heb 40+ uren overwerk gehad aan deze storingen. Denk dat KPN door deze storingen een boel schade claims zal krijgen (terecht of onterecht, dat laat ik even in het midden) en dus gezichtverlies lijdt. Vooral dat laatste is erg.
Het kan best zijn dat een software bug het lawine effect getriggerd heeft. Maar uiteindelijk is het een netwerk dat overboekt is dus. Overboeken is opzichzelf een toelaatbare techniek, en al jaren succesvol bij o.a. telefooncentrales. Maar als je je winsten te ver wilt optimaliseren door noodzakelijke inversteringen uit te stellen krijg je dit dus.
Echte oorzaak: hebzucht.
In de nacht van maandag 12 op dinsdag 13 mei trad door dit mankement een overbelasting op in de ATM-backbone van KPN.
Right, wij hadden die maandagochtend al geen Internet meer. Beetje vreemd niet?
Dinsdag de hele dag eruit gelegen en woensdag tegen 13:00u was het er weer. We hebben mensen naar huis gestuurd omdat ze hier op de zaak geen Inet hadden wat ze wel nodig hadden om hun werk te kunnen doen.
Hetgeen ik dan het ergste vond is dat je nergens door kwam. KPN Business Helpdesk gooide de hoorn er meteen op. Op Inet kon ik 's avonds thuis (gelukkig geen last van de storing thuis) pas lezen wat er aan de hand was. Dat vind ik nou een trieste zaak.
Dat KPN pas na 1,5 dag zo slim was om een bandje in te spreken op het helpdesk nummer is een beetje aan de late kant.
Als ik ze nu bel voor een schadevergoeding zeggen ze heel simpel, "vul het klachtenformulier op de site maar in dan hoort ie wel een keer van ons"... Een keer???
Sorry maar de service laat te wensen over. Nu ben ik de laatste die geen begrip kan tonen voor een dergelijke storing, immers hebben we te maken met elektronica maar als je vervolgens de mensen die er last van hebben gehad aan het lijntje houd kan ik niet begrijpen.
Uit het bericht maak ik op dat er nog altijd geen zekerheid is over de vraag of het om Cisco of Alcatel apparatuur ging. De formele bevestiging daarvan is er dus niet.
Om te kunnen reageren, dient u ingelogd te zijn.
2 jaar geleden: 13 februari 2010
3 jaar geleden: 13 februari 2009
4 jaar geleden: 13 februari 2008
5 jaar geleden: 13 februari 2007
14 jaar geleden: 13 februari 1998
IDG Nederland is uitgever van: AppFish
, CIO, Computer!Totaal, Computerworld, ITworld, Jobworld, MacWorld, RAW fotomagazine, TechFish, Tips & Trucs, Webwereld en Zoom.nlMeer informatie: IDG Nederland, IDG.com, Privacy-statement, Cookie-statement Hosting by Terremark.
