Ukendt fejl åd hukommelsen på 32 af TDC's største routere

4. april 2013 kl. 13:5110
Det var en fejl i forbindelse med migreringen af TDC's netværk for erhvervskunder, som onsdag førte til et større nedbrud på TDC's netværk.
Artiklen er ældre end 30 dage
Manglende links i teksten kan sandsynligvis findes i bunden af artiklen.

Hovedårsagen er endnu ukendt, men onsdag eftermiddag gik 32 af TDC's største routere ned i forbindelse med, at teleselskabet var i færd med at omlægge systemerne for at ensrette driften i de nordiske lande.

»Selve rodårsagen kender vi ikke endnu, men det er en ændring, der er gået galt. Det ramte de 32 største routere, så det gjorde problemet værre,« forklarer funktionsleder Henrik Vestergaard hos TDC til Version2.

Nedbruddet ramte blandt andet SAS, der måtte udskrive boardingkort i hånden, og Aarhus Kommune, der hele onsdag eftermiddag var uden kontakt til medarbejdernes kritiske it-systemer.

TDC er i gang med at sørge for, at selskabets netværk i alle de nordiske lande, opererer på samme måde. I dag foregår eksempelvis overvågningen af erhvervskundernes drift forskelligt på TDC's egne netværk og de netværk, TDC har overtaget gennem opkøb.

Artiklen fortsætter efter annoncen

De kunder, som blev ramt, var erhvervskunder med interne MPLS-forbindelser, der kører over TDC's netværk.

De 32 routere gik ned, fordi IP-adresserne i routningen blev dubleret mange gange, indtil hukommelsen blev fyldt op.

»Vi fik rettet fejlen efter 17 minutter, men derefter skulle vi genstarte routerne. Det kunne vi gøre centralt for routerne i Danmark, men der var nogle få routere i resten af Norden, hvor vi skulle tænde og slukke for dem,« fortæller Henrik Vestergaard.

Netværk med 1.400 routere

TDC's netværk består af cirka 1.400 routere, men fejlen ramte blot 32 af routerne, som til gengæld var de største routere, og det var grunden til, at mange kunder blev berørt af fejlen.

Onsdagens nedbrud betyder, at denne fase af TDC's migrering er rullet tilbage, og selskabets teknikere skal nu finde ud af, hvordan migreringen kan foretages, uden at nedbruddet gentager sig.

»Vi skal stadig have udført denne aktivitet, så det kommer til at tage nogle uger, fordi vi skal have kigget det igennem,« siger Henrik Vestergaard.

10 kommentarer.  Hop til debatten
Denne artikel er gratis...

...men det er dyrt at lave god journalistik. Derfor beder vi dig overveje at tegne abonnement på Version2.

Digitaliseringen buldrer derudaf, og it-folkene tegner fremtidens Danmark. Derfor er det vigtigere end nogensinde med et kvalificeret bud på, hvordan it bedst kan være med til at udvikle det danske samfund og erhvervsliv.

Og der har aldrig været mere akut brug for en kritisk vagthund, der råber op, når der tages forkerte it-beslutninger.

Den rolle har Version2 indtaget siden 2006 - og det bliver vi ved med.

Debatten
Log ind eller opret en bruger for at deltage i debatten.
settingsDebatindstillinger
8
4. april 2013 kl. 19:09

TDC fiber og var nede fra ca. 13:15 til ca. 14:15

7
4. april 2013 kl. 18:22

Jeg blev en smugle nervøs, da jeg så at alle vores services var offline. Det var kun de services, der hostes på det kontor jeg selv var på, der stadig var online. ( dvs printerne virkede ).

Vores servere havde det heldigvis fint. Det eneste der var nede var vores MPLS forbindelse i København. Og den bruger vi ikke til andet end til at køre overvågning af vores servere. Så alt andet var, så vidt jeg ved, stadig online.

Det tog lige knap 30 minutter.

MPLS er i øvrigt et netværk, som kan sammenlignes med VPN. Den store forskel er, at VPN forbindelser har 2 ender, hvor MPLS kan have flere. MPLS kan både køre over fiber og ADSL, og det giver mening til interne systemer som fx intranet og ip telefoni, eller til at erstatte flere VPN forbindelser. Man kan køre en MPLS og internet over den samme ADSL forbindelse, men MPLS kører ikke via ip og derfor heller ikke via internettet.

Og så kan man generelt ikke kører MPLS på tværs af ISP. Så det er også en glimrende vendor lock-in mekanisme.

6
4. april 2013 kl. 16:40

Vores firma sidder med MPLS forbindelse, og vi blev påvirket - men da ikke i de "påståede" 17 minutter - Næh, fra vi oplevede problemer til det blev fuldstændigt løst gik der i hvert fald 2½ time. Længe nok til at jeg endelig fik sat en wan failover over 4g op på vores firewall.

5
4. april 2013 kl. 16:30

I min IT-karriere har vi ofte talt om tidspunktet hvor det er mest optimalt at lave større omlægninger. Indimellem har nogen foreslået "Lad os tage en onsdag eftermiddag", og den har vi så grinet lidt af hver gang, da det jo dybest set er prime time for langt de fleste virksomheder, systemer osv. Det kan sagtens ske at denne fejl ikke var forudsigelig, men jeg kunne godt tænke mig at høre hvorfor man lige har valgt dette tidspunkt til sådan en omlægning, givet dens potentielle impact?

9
4. april 2013 kl. 22:27

Der kan faktisk være mange rigtig gode grunde til at vælge at gøre det i almindelig kontortid. I gamle dage slukkede sidste mand for computeren når man gik hjem,og første mand tændte for den næste morgen ;-) Idag er der ingen tidspunkter på døgnet hvor trafikken er lav - der flyver fly næsten døgnet rundt til og fra Kastrup, der sker kritiske dataudvekslinger imellem datacentrene om natten etc etc. Impact om natten er lige så stor som om dagen, men den er muligvis af en anden karakter. Derfor kan man lige så godt lave det i dagtid. Folk er friske og veludhvilede og beredskabet er maksimalt. Skal man have fat i specialister hos leverandøren, så er de lige til at ringe til etc etc. Og så vil mange changes i et netværk snildt kunne laves om dagen, da redundans og god planlægning ofte vil sikre kontinuert drift.

Men måske man skal holde sig fra begyndelsen af april måned sådan helt generelt. IBM's "Sorte torsdag" var den 9. april for nogen år siden hvor nettet også gik i sort i datacenteret i København :-)

10
5. april 2013 kl. 14:08

Jeg er helt enig med Michael, et andet scenarie kan være hvis man drifter internationalt på kryds og tværs af tidszoner.

4
4. april 2013 kl. 15:07

Nu er der jo altid en vis fortolkning, når der skrives en artikel, men det lyder ikke som om den udtalende funktionsleder har prøvet at konfigurere større routersystemer og udtalelserne er derfor temmelig intetsigende eller indholdsløse ...... eller måske er han bare god til at udsende netop indholdløse beskeder.

Anyway det lyder måske lidt som om de har haft en konfigureringsfejl ved sammenlægning af autonome netværk måske. Tvivler dog på, at der ikke er tale om en fejl-fyrre frem for en eller anden fuldstændig uforudsebar teknisk fejl. At migrere fra eBGP til iBGP uanset routningsprotokol kræver erfaring og der er ikke mange tilbage i Danmark med den slags. Mon ikke bare det var noget så banalt som fejl i access-listerne til udveksling routningstabeller eller måske at de har brugt sammenfaldende RFC1918-adresser, hvor de ikke skulle :)

mvh

3
4. april 2013 kl. 14:45

Selv intern IP-telefoni i Københavns kommune var nede

1
4. april 2013 kl. 14:28

De kunder, som blev ramt, var erhvervskunder med interne MPLS-forbindelser, der kører over TDC's netværk.

Lyder som om det kun var kunder med MPLS-forbindelser der blev ramt. Det er på ingen måder tilfældet. Rigtig mange privat kunder var ramt (se f.eks. TDC's Facebook side), og på vores kontor var vores G.SHDSL forbindelse nede.