KPN bouwt meer knooppunten in netwerk om storing te voorkomen
KPN is bezig met het uitbreiden van het aantal cross-connects in zijn netwerk. Dat moet de kans op een storing verkleinen. Het telecombedrijf neemt de maatregel naar aanleiding van een storing vorig jaar, waardoor 112 niet bereikbaar was.
Ook heeft de telco enige tijd geleden veel van de klokkaarten in de cross-connect-punten vervangen. Cross-connects zijn knooppunten in het netwerk, waar duizenden datalijnen worden verbonden met centrale lijnen. KPN doet de aanpassingen vanwege een grote storing in Rotterdam vorig jaar, waarbij 112 enige tijd niet bereikbaar was, hulpdiensten elkaar niet konden bereiken en trams niet reden.
De falende klokkaart in de cross-connect en het gebrek aan backup voor cross-connects bleken oorzaak van de storing. Alle onderdelen zijn weliswaar dubbel uitgevoerd, maar de onderdelen die worden gebruikt en de backup staan niet los van elkaar. Daardoor kan bij een storing het hele systeem offline gaan, waardoor veel dataverbindingen in die regio niet werken.
KPN volgt veel van de aanbevelingen op die de Inspectie Veiligheid en Justitie en het Agentschap Telecom doen in een rapport over de storing. Naast de technische verbeteringen belooft KPN ook de communicatie rond storingen te verbeteren, zegt het bedrijf.
Reacties (32)
Er zijn meerdere storingen geweest bij kpn. Dit is blijkbaar gebeurd naar aanleiding van een minder recente storing dan die jij bedoelt.
Stukje uit het rapport, pagina 9:
Aanleiding
In de nacht van 26 op 27 juli 2011 pleegt KPN onderhoud aan het telecomknooppunt in
de Waalhaven te Rotterdam. Tijdens dit onderhoud treedt een technische storing op in
een zogenaamde ‘cross connect’.
Als je een FIPO hebt, check wel wel even de feiten/documenten die je worden aangeboden...
Aanleiding
In de nacht van 26 op 27 juli 2011 pleegt KPN onderhoud aan het telecomknooppunt in
de Waalhaven te Rotterdam. Tijdens dit onderhoud treedt een technische storing op in
een zogenaamde ‘cross connect’.
Als je een FIPO hebt, check wel wel even de feiten/documenten die je worden aangeboden...
hoezo als jij een storing kan beperken tot een 10 voud minder gedupeerde heb je toch al een hoop gewonnen 
Redundantie werkt wel degelijk. Wat een gebruiker met z'n PC uitspookt doet vrij weinig met netwerk infrastructuur als bekabeling en switches.
Vaak genoeg voorgekomen dat ik héél erg blij was dat er 2 switches stonden op een locatie ipv 1.
Vaak genoeg voorgekomen dat ik héél erg blij was dat er 2 switches stonden op een locatie ipv 1.
Ik moet zeggen dat mijn ervaring met redundantie ook niet echt alles is, en dat in samenwerking met grote datacentra.
Het probleem is dat er vaak nog SPOF's blijven bestaan. Bijvoorbeeld een router die 'per ongeluk' wordt gereboot omdat ze nieuwe FW distribueren of iets in die trant.
Het 'klakkeloos' toevoegen van meerdere knooppunten om verkeer om te leiden is dan ook weer waar je je vraagtekens bij kan zetten.
Het probleem is dat er vaak nog SPOF's blijven bestaan. Bijvoorbeeld een router die 'per ongeluk' wordt gereboot omdat ze nieuwe FW distribueren of iets in die trant.
Het 'klakkeloos' toevoegen van meerdere knooppunten om verkeer om te leiden is dan ook weer waar je je vraagtekens bij kan zetten.
"Redundantie is niet alles.."
"SPOF's.."
Spreekt elkaar nogal tegen..
Mits je redundantie goed is uitgevoerd, heb je geen spof's (in a perfect world natuurlijk.. realiseer me dat dit niet altijd mogelijk is of financieel niet haalbaar).
Mijn reactie sloeg voornamelijk op de zwart/wit opmerking "Haha gaat geen bal uithalen... "
Dat het geen gouden alles oplossende oplossing is begrijp ik
"SPOF's.."
Spreekt elkaar nogal tegen..
Mits je redundantie goed is uitgevoerd, heb je geen spof's (in a perfect world natuurlijk.. realiseer me dat dit niet altijd mogelijk is of financieel niet haalbaar).
Mijn reactie sloeg voornamelijk op de zwart/wit opmerking "Haha gaat geen bal uithalen... "
Dat het geen gouden alles oplossende oplossing is begrijp ik
Als er nog single points of failure zijn dan is er dus onvoldoende redundantie.Ik moet zeggen dat mijn ervaring met redundantie ook niet echt alles is, en dat in samenwerking met grote datacentra.
Het probleem is dat er vaak nog SPOF's blijven bestaan.
Dus is het probleem niet dat in het algemeen redundantie niet goed werkt, het probleem daar zit 'm in onvoldoende redundantie.
Het gaat niet alleen om het dubbel uitvoeren van hardware. De data kan dankzij meerdere knooppunten omgeleid worden. Als een graafmachine ergens een kabel kapottrekt, of een knooppunt fikt er uit, dan kan de data via een andere route alsnog zijn route bereiken.
Vergelijk het met een stukje omrijden, als ergens een weg is afgesloten door een ongeval.
Vergelijk het met een stukje omrijden, als ergens een weg is afgesloten door een ongeval.
Wat heeft het vóórkomen van storingen te maken met de (on)voorspelbaarheid van gebruikers?
Ik begrijp dat het Tweakers is en dat de techniek belangrijker is, maar de belangrijkste conclusie in dat rapport is dat het niet de schuld is van KPN, maar van de organisaties die klant waren van KPN en geen noodvoorzieningen hadden.
Het is toch van de zotte dat je bij zo'n belangrijke dienst als 112 of de metro afhankelijk bent van 1 telco? KPN garandeert vast geen 100% uptime in het contract dus dit hadden ze kunnen voorzien. Die bedrijven moeten dus of niet zeuren als het eens een keer stuk gaat vanwege pech, of geld investeren in redundante communicatie. Put your money where your mouth is.
Los hiervan natuurlijk prima dat KPN investeert om nog meer storingen te voorkomen, maar ook hiermee zullen ze nog steeds voorkomen, en wordt het achterliggende probleem wat ik hierboven beschrijf niet opgelost.
Het is toch van de zotte dat je bij zo'n belangrijke dienst als 112 of de metro afhankelijk bent van 1 telco? KPN garandeert vast geen 100% uptime in het contract dus dit hadden ze kunnen voorzien. Die bedrijven moeten dus of niet zeuren als het eens een keer stuk gaat vanwege pech, of geld investeren in redundante communicatie. Put your money where your mouth is.
Los hiervan natuurlijk prima dat KPN investeert om nog meer storingen te voorkomen, maar ook hiermee zullen ze nog steeds voorkomen, en wordt het achterliggende probleem wat ik hierboven beschrijf niet opgelost.
Maar storingen zullen dan wel minder vaak voor komen, en dat is het doel van deze operatie.Los hiervan natuurlijk prima dat KPN investeert om nog meer storingen te voorkomen, maar ook hiermee zullen ze nog steeds voorkomen,
Het doel is natuurlijk niet om storingen 100% uit te sluiten, dat kan namelijk niet en daarom claimt niemand dat dat het doel is, en het is geen rede om niet te investeren in meer redundantie.
100% uitsluiten kan nooit maar je komt er een heel stuk dichterbij als je jezelf niet afhankelijk maakt van één leverancier.
Het verbaasde mij nogal dat 112 kennelijk maar gebruik maakt van één Telco voor een aantal belangrijke verbindingen. Voor het trambedrijf lijkt me dat een acceptabele keus. Voor 112 is het dat volgens mij niet.
Het verbaasde mij nogal dat 112 kennelijk maar gebruik maakt van één Telco voor een aantal belangrijke verbindingen. Voor het trambedrijf lijkt me dat een acceptabele keus. Voor 112 is het dat volgens mij niet.
Historisch heeft 112 geweldige uptimes. De telefooncentrales zelf crashen simpelweg niet. De hele hardware is mirrored, en FW updates gaan mirrored. De problemen zijn pas ontstaan toen de netwerken complexer werden gemaakt om kosten te besparen.
Dat klinkt misschien paradoxaal, complexer en daardoor goedkoper. In de praktijk betekent het vooral dat er minder dure centrales zijn, doordat er goedkope apparatuur voor en tussengezet wordt die de centrales zou moeten ontlasten. En juist op die randapparatuur heb je vaker SPOF's
Dat klinkt misschien paradoxaal, complexer en daardoor goedkoper. In de praktijk betekent het vooral dat er minder dure centrales zijn, doordat er goedkope apparatuur voor en tussengezet wordt die de centrales zou moeten ontlasten. En juist op die randapparatuur heb je vaker SPOF's
Toch vreemd. Vroeger, toen er alleen telefoonsignaal door het koperdraad van de PTT heen ging waren deze storingen veel minder. Tegenwoordig, met internet en allerlei andere zaken over de koperdraden van KPN zijn er om de haverklap storingen.
Aan het koperdraad zal het niet liggen, tenzij iemand daar de schep in zet. De apparatuur die men nu gebruikt is kennelijk niet van de kwaliteit die men mag verwachten. Er zitten bugs in de firmware of ze vallen uit omdat ze iets te hard moeten werken. Erg jammer maar het is wél een afspiegeling van de producten die KPN bij zijn klanten in huis/kantoor neerzet.
Aan het koperdraad zal het niet liggen, tenzij iemand daar de schep in zet. De apparatuur die men nu gebruikt is kennelijk niet van de kwaliteit die men mag verwachten. Er zitten bugs in de firmware of ze vallen uit omdat ze iets te hard moeten werken. Erg jammer maar het is wél een afspiegeling van de producten die KPN bij zijn klanten in huis/kantoor neerzet.
Ik denk eigenlijk niet dat het tegenwoordig meer of minder storingsgevoelig is dan vroeger. We zijn alleen wel veel afhankelijker geworden van dit soort communicatienetwerken, waardoor het veel meer opvalt.
Nee, vroeger had je net zo goed storingen. We zijn alleen geneigd negatieve ervaringen na verloop van tijd te vergeten. Vroeger had je net zo goed dat je een nummer draaide en de verbinding niet tot stand kwam, of dat je een slechte, krakende verbinding had. Opnieuw draaien hielp soms.
Bovendien had je geen landelijke nummers, zoals 112. Je moest bijvoorbeeld altijd naar den Haag bellen als je de PTT wilde bereiken. Nu bel je gewoon 112, waar je ook bent, maar als je dat in limburg doet, kom je op een andere centrale als wanneer je dit in groningen doet.
Bovendien had je geen landelijke nummers, zoals 112. Je moest bijvoorbeeld altijd naar den Haag bellen als je de PTT wilde bereiken. Nu bel je gewoon 112, waar je ook bent, maar als je dat in limburg doet, kom je op een andere centrale als wanneer je dit in groningen doet.
Want hoe vaak storingen voor komen maakt niet uit? Jawel, dat is precies waar het om gaat.Nee, vroeger had je net zo goed storingen. We zijn alleen geneigd negatieve ervaringen na verloop van tijd te vergeten.
"Vroeger" had de PTT letterlijk ééns in een blauwe maandag een storing; aanzienlijk minder dan eens per jaar
Tegenwoordig hebben veel telecom providers meerdere keren per jaar een storing.
Je vergeet voor het gemak even dat er nu niet alleen meer Nederlanders zijn, maar dat ze ook veel meer bellen, en niet alleen met een vaste lijn maar vooral met hun mobieltjes. En er ligt veel meer in de grond. En 25 jaar geleden had niemand thuis internet of digitale televisie. Logisch dat er dan minder storingen waren.
Dus logisch dat er nu meer moet worden gedaan om het aantal storingen beperkt te houden, en kennelijk is daaraan tot nu toe onvoldoende gedaan.Logisch dat er dan minder storingen waren.
Vroeger moest je naar Den Haag bellen om de PTT te bereiken maar nu bel je gewoon 112? Sinds wanneer heeft 112 iets met de PTT te maken en met Den Haag?
Vroeger moest je in elke stad een ander nummer draaien om de hulpdiensten te bereiken. Bedoel je dat misschien?
Vroeger moest je in elke stad een ander nummer draaien om de hulpdiensten te bereiken. Bedoel je dat misschien?
Het is goed om te zien dat ze ook bij KPN weer leren dat een storing nu eenmaal niet altijd te voorkomen is en dat je dan zeker geen behoeft hebt aan een primaire en backup oplossing op een locatie. Het is kinderlijk eenvoudig net als je je belangrijkste data center en de backup hier van niet in een stad en liever ook niet in een land wilt hebben geld dit ook voor eigenlijk alle andere oplossingen die een backup nodig hebben.
Als er een stroomstoring is in een regio is dat nog geen reden om meteen maar een volledig knooppunt te verliezen net als wanneer er een brand is in een locatie hoeft dat echt geen Vodaphone resultaat te hebben. Het is simpel weg een kwestie van de miljarden die je verdiend aan je netwerk voor een iets groter deel gebruiken om dit netwerk betrouwbaar te maken ook in geval van een serieus probleem op een belangrijke locatie.
Als er een stroomstoring is in een regio is dat nog geen reden om meteen maar een volledig knooppunt te verliezen net als wanneer er een brand is in een locatie hoeft dat echt geen Vodaphone resultaat te hebben. Het is simpel weg een kwestie van de miljarden die je verdiend aan je netwerk voor een iets groter deel gebruiken om dit netwerk betrouwbaar te maken ook in geval van een serieus probleem op een belangrijke locatie.
Dat zeg je wel ff heel makkelijk zonder iets van de infrastructuur af te weten. Misschien is het wel helemaal niet mogelijk om een hot-standby backup oplossing fysiek op een andere locatie te zetten. Ik ben wel eens in z'n knooppunt geweest en je moet eens een idee hebben hoeveel kabels daar wel niet binnen komen vanuit andere nodes en punten. je legt dan niet zomaar even een 2e lijntje naar een andere nieuwe centrale.
Trouwens stroomvoorziening van die knoopunten zelf zijn vaak dik in orde. ze zijn minimaal met 2 aparte net aansluitingen aangesloten en voorzien van generatoren als het echt mis gaat (en daarbij nog afspraken met leveranciers die kunnen zorgen voor 3e backup generatoren en diesel aanvoer).
Trouwens stroomvoorziening van die knoopunten zelf zijn vaak dik in orde. ze zijn minimaal met 2 aparte net aansluitingen aangesloten en voorzien van generatoren als het echt mis gaat (en daarbij nog afspraken met leveranciers die kunnen zorgen voor 3e backup generatoren en diesel aanvoer).
Hoe wil jij een backup van een fysieke kabel in Rotterdam realiseren, als die fysieke kabel (naar een externe partij) in Den Haag jou pand binnen komt? Dit zul je moeten afspreken met de externe partij, die dan ook weer twee locaties nodig heeft. Als die externe partij er geen geld voor over heeft, kan KPN investeren wat het wil, maar zul je nooit een volledig SPOF vrij netwerk hebben.
Veel telefonie verkeer gaat nog steeds over "ouderwetse" ISDN of ATM verbindingen, waarbij koppelingen met externe partijen nog enkel zijn uitgevoerd. Deze verbinding zijn niet simpel dubbel uit te voeren, zoals dat tegenwoordig wel kan met allerlei IP technieken.
Veel telefonie verkeer gaat nog steeds over "ouderwetse" ISDN of ATM verbindingen, waarbij koppelingen met externe partijen nog enkel zijn uitgevoerd. Deze verbinding zijn niet simpel dubbel uit te voeren, zoals dat tegenwoordig wel kan met allerlei IP technieken.
ISDN2 is consumententechnologie, ISDN30 is MKB. Serieuze netwerkverbindingen zoals ATM (i.c.m. ISUP/SS7) laten wel degelijk rerouting toe.
ATM is als netwerk-technologie op papier veruit superieur aan IP/ethernet. Pas jaren later is veel van dezelfde functionaliteit voor IP gerealiseerd in protocollen zoals MPLS.
ATM wordt uitgefaseerd omdat het te duur is en nu goedkopere alternatieven bestaan.
Het is gedeeltelijk een "betamax" verhaal. Te duur en de rest van de wereld had al ethernet/IP. Dat doet echter niets af aan het protocol en de mogelijkheden daarvan.
ATM wordt uitgefaseerd omdat het te duur is en nu goedkopere alternatieven bestaan.
Het is gedeeltelijk een "betamax" verhaal. Te duur en de rest van de wereld had al ethernet/IP. Dat doet echter niets af aan het protocol en de mogelijkheden daarvan.
Mooi gezegd maar technisch is dit een vak apart en weliswaar kinderlijk eenvoudig om als gedachte te uiten maar zeker niet kinderlijk eenvoudig om uit te voeren.
Sommige dingen die we zouden willen kunnen ook niet. Een active active databasecluster heeft bv vaak een <1ms latency eis. Dan kan je die twee datacenters bv al niet heel ver uit elkaar zetten, ook al zou je dat willen, daar gaat licht niet snel genoeg voor.
Grote bedrijven spenderen serieus veel geld aan redundante datacenters, dat weegt makkelijk op tegen de kosten bij uitval (zowel in directe kosten als in de PR schade). Vodaphone zal de impact die dat brandje had ook niet verwacht hebben. Dat komt lang niet altijd door gebrek aan investeringen maar ook vaak omdat het niet kinderlijk eenvoudig is en je de laatste schakels van de redundante keten soms pas inzichtelijk krijgt als er een keer iets echt stuk gaat.
Sommige dingen die we zouden willen kunnen ook niet. Een active active databasecluster heeft bv vaak een <1ms latency eis. Dan kan je die twee datacenters bv al niet heel ver uit elkaar zetten, ook al zou je dat willen, daar gaat licht niet snel genoeg voor.
Grote bedrijven spenderen serieus veel geld aan redundante datacenters, dat weegt makkelijk op tegen de kosten bij uitval (zowel in directe kosten als in de PR schade). Vodaphone zal de impact die dat brandje had ook niet verwacht hebben. Dat komt lang niet altijd door gebrek aan investeringen maar ook vaak omdat het niet kinderlijk eenvoudig is en je de laatste schakels van de redundante keten soms pas inzichtelijk krijgt als er een keer iets echt stuk gaat.
Theoretisch heb je gelijk, maar voor dit soort functionaliteit is active-passive clustering voldoende. Een 1 seconde storing van 112 is acceptabel, zeker als verbindingen alleen onderbroken en niet verbroken worden. 1 Minuut is vervelend. 1 Uur is onacceptabel.
Het was ook maar een voorbeeld om te illustreren dat niet alles dat kinderlijk eenvoudig lijkt ook zo is
Overigens duurt een overschakeling van een grote actieve database naar de backup zeker langer dan een minuut, en een uur is ook niet vreemd. Vooral omdat een dergelijke overstap potentieel risicovol is en vaak bij voorkeur niet automatisch wordt gedaan. Ik ken echt verhalen van platformen waar door de leverancier wordt aangegeven dat switch van de database van site A naar site B 'binnen 4 uur' kan vanwege de omvang en complexiteit. Een IP verbinding met een of ander routeringsprotocol eroverheen kan in no time herrouteren, maar dat zo werkt het op hogere OSI lagen vaak niet.
Maar een database lijkt me niet aan de orde voor de bereikbaarheid van 112, wellicht wel voor hun informatieverwerking, maar die is primair niet nodig als er ergens een ambulance of brandweerwagen heen moet.
Overigens duurt een overschakeling van een grote actieve database naar de backup zeker langer dan een minuut, en een uur is ook niet vreemd. Vooral omdat een dergelijke overstap potentieel risicovol is en vaak bij voorkeur niet automatisch wordt gedaan. Ik ken echt verhalen van platformen waar door de leverancier wordt aangegeven dat switch van de database van site A naar site B 'binnen 4 uur' kan vanwege de omvang en complexiteit. Een IP verbinding met een of ander routeringsprotocol eroverheen kan in no time herrouteren, maar dat zo werkt het op hogere OSI lagen vaak niet.
Maar een database lijkt me niet aan de orde voor de bereikbaarheid van 112, wellicht wel voor hun informatieverwerking, maar die is primair niet nodig als er ergens een ambulance of brandweerwagen heen moet.
Kritiek leveren kan op vele momenten en wellicht inderdaad ook hier. Maar ik hou het ditmaal bij 'netjes'. Het valt te prijzen dat men bij KPN in elk geval tracht (!) situaties, zoals beschreven in het artikel, in de toekomst te voorkomen.
Op dit item kan niet meer gereageerd worden.
Onderwerpen
Populair: Tablets Samsung Websites en communities Mobiele telefoons Google Sony Microsoft Games Consoles Politiek en recht
© 1998 - 2013 Tweakers.net B.V. Contact Over Tweakers Jouw privacy Algemene voorwaarden Cookies
Tweakers wordt uitgegeven door De Persgroep en wordt gehost door True
