Halvdød switch kvalte danske internetbetalinger fredag morgen

Problemer på netværket hos IBM betød, at det var vanskeligt at gennemføre kortbetalinger via internettet fredag morgen.

Danske internethandlende og brugere af eksempelvis MobilePay havde problemer med at gennemføre transaktioner i cirka tre timer fredag morgen. Det oplyser Nets, der står for internetbetalingerne, til Version2.

Problemerne begyndte tidligt fredag morgen og ramte især danske webbutikker, hvor det i praksis var umuligt at gennemføre betalinger.

»Cirka klokken seks i morges og frem til klokken ni havde vi netværksproblemer på en switch, som ikke var helt død, men næsten, og det betød, at det tog os lidt tid at finde den og få den erstattet med en ny,« fortæller pressekoordinator Carsten Grønning fra IBM Danmark til Version2.

IBM står for driften af Nets' systemer, og det var altså en fejl på IBM's netværk, der gav problemer. Ifølge Carsten Grønning blev fejlsøgningen på netværket besværliggjort af, at switchen fungerede delvist og dermed ikke umiddelbart optrådte som den primære årsag til netværksproblemerne.

De berørte systemer hos Nets var alle systemer, som bruges til at gennemføre kortbetalinger via internettet, hvilket omfatter tjenester som internetbutikker og Danske Banks MobilePay. Transaktioner via de terminaler, som bruges i fysiske butikker, var ikke påvirket af netværksproblemerne.

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Kommentarer (30)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Xx Zz

Under hele forløbet frem til kl ca 10 hvor det begyndte at fungere igen var status på Nets:

"Al drift ok.
Nets afvikler transaktioner med betalingskort på normal vis"

Faktisk skulle man til f.eks Dibs eller Quickpay for at finde ud af der var problemer ....

  • 7
  • 0
Peter Mærsk-Møller

Jo

http://www.version2.dk/artikel/ibm-nedbrud-hvad-ved-vi-6983

Sølvpapirshattene menes at mene at switchfejlen den gang var en kloning af trafikken til overvågning og dataindsamling til efterretningsbrug, der gik galt. Men det er jo lige så langt ude som at påstå at FE skulle bistå med indsamling af rå nettrafik til udenlandsk efterretningsvæsen ... og hvem ville dog tro på sådan en uhyrlig påstand ;-)

  • 2
  • 0
Peter Mærsk-Møller

Når jeg brugte udtrykket svært, så var det en kraftig underdrivelse i forbindelse med en opgave der er alt andet end triviel.

Det har man da kunne i mindst 20 år. I Ebone i sluthalvfemserne og begyndelsen af 00'erne lavde jeg da aktiv pakketest for at kunne dokumentere at vi med vores guldservice holdte, hvad vi lovede, nemlig 0.00% pakketab i 99.99% af tiden målt i fem minutters intervaller i modsætning den dramtisk ringere nu til dags udbredte service med højest X % pakketab i 100% af tiden og med højest 99.9X % oppetid.

Så jo, det kan man sagtens måle, hvis man har kompentente folk, der forstår netværkstrafiks natur og de underliggende protokoller og arkitekturer. For de inviede er alting jo nemt.

  • 4
  • 3
Christian Nobel

Det har man da kunne i mindst 20 år. I Ebone i sluthalvfemserne og begyndelsen af 00'erne lavde jeg da aktiv pakketest for at kunne dokumentere at vi med vores guldservice holdte, hvad vi lovede, nemlig 0.00% pakketab i 99.99% af tiden målt i fem minutters intervaller i modsætning den dramtisk ringere nu til dags udbredte service med højest X % pakketab i 100% af tiden og med højest 99.9X % oppetid.

Det er jo noget helt andet du taler om her.

Det du taler om her er lave monitorering, og hvis der så viser sig at være fejl, så agerer du.

Men hvis vi taler en hardware baseret Ethernet switch, så har du ikke en kinamands chance for umiddelbart at vide hvad der sker mellem to vilkårlige porte, derfor kan en switch sagtens være halvsyg som Baldur siger, uden der er nogen der opdager det.

Og kva en switch's natur, så kan man ikke lave backup, kun forholdsregler for hvornår man skal hive alle kablerne ud, og erstatte boksen - og Kirchhoffs love gælder ikke for computernetværk.

Man kan selvfølgelig godt lave overvågning på vigtigere porte, eksempelvis dem der går videre til en router, og så agere hvis der kommer fejl, men fsva. switchen vil det være i form af en alarm, eller måske portskift til en backup port - det hjælper bare ikke ret meget hvis der er en fejl internt i switchen, og alarmen aldrig går.

Så jo, det kan man sagtens måle, hvis man har kompentente folk, der forstår netværkstrafiks natur og de underliggende protokoller og arkitekturer. For de inviede er alting jo nemt.

Drop bare doseringen, jeg har arbejdet med netværksudstyr og målinger i over 25 år, og har nok været en af de første der overhovedet installerede (Ethernet)switche her i landet, og hvis man påstår at ting er nemme, så er det fordi man ikke forstår problemerne og ikke har respekt for dem.

  • 6
  • 2
Thomas Jensen

Nets gik ned ca. 6.30

Helt ekstraordinært blev der faktisk sendt driftmelding fra Nets 6.47. Ekstraordinært fordi normen er at der ikke sendes driftmeldinger.

Desværre står mailserveren som distribuerer disse driftmeldinger på samme fejlfyldte netværk (gætværk). I al fald kom driftmeldingen ikke frem førend timer senere, da ting fungerede igen.

Så Nets/IBM skal have ros for rent faktisk at forsøge at informere (deres hardcodede grønne html på nets.eu gider jeg slet ikke kommentere på), men skal lige tilbage til tegnebrædtet mht. at adskille kommunikationskanaler fra det tekniske setup der skal driftsmeldes omkring.

Måske næste år ... nu ser vi :)

vh
thomas jensen

  • 5
  • 0
Peter Mærsk-Møller

Hej Christian.

Det du taler om her er lave monitorering, og hvis der så viser sig at være fejl, så agerer du.

Bedst er det naturligvis, hvis fejlscenarier er forudset og systemerne reagerer automatisk, når et threshold nås, så 3rd level support ikke skal tilkaldes på ukristelige tidspunkter med deraf forsinkelse til følge.

Men hvis vi taler en hardware baseret Ethernet switch, så har du ikke en kinamands chance for umiddelbart at vide hvad der sker mellem to vilkårlige porte, derfor kan en switch sagtens være halvsyg som Baldur siger, uden der er nogen der opdager det.

Nu er der jo mange fejlscenarier for en switch og der findes ikke en enkelt metode til at opdage den slags fejl. Men der findes en palette af værktøjer, der med den rette indsigt og snilde kan depolyeres for at spotte de fleste fejl. Mit bud er, at man aller højest indsamler lidt data omkring switchens performance med SNMP og måske lidt på serversiden, men så heller ikke mere.

Og kva en switch's natur, så kan man ikke lave backup, kun forholdsregler for hvornår man skal hive alle kablerne ud, og erstatte boksen - og Kirchhoffs love gælder ikke for computernetværk.

Man kan sagtens lave hot standby backup for en switch, men uden anden hjælp, virker det jo i sagens natur ikke, hvis switchen kun fejler "lidt". En hot standby switchover skal i beslutningsprocessen hjælpes på vej af et omfattende sæt af overvågning og dataindsamlinger og der skal bruges statistiske metoder til at spotte begyndende fejl, hvor en switch kun fejler lidt.

For det første skal der laves aktiv pakketabstest gennem switchen mod alle servere man ønsker at beskytte. Dette lyder omfattende, men er ret nemt at implementere. Dernæst skal alle servere man ønsker at beskytte, have en aktiv sessionsmonetorering af ALLE de services man ønsker at beskytte inklusiv underliggende services som der afhænges af. Det lyder omfattende, men er ikke så svært, når man først har fundet ud af hvordan og, ressourcerne der kræves er heller ikke overvældende. Sidst, men ikke mindst, skal man lave, hvor det er muligt, sessionsmoneterering på klienter, der benytter de beskyttede data. Det er lidt mere omfattende, men absolut muligt idet flere firmaer og hospitaler i Danmark bla. bruger et dansk produkt til dette.

Det hele skal sættes op, hvilket kræver expertviden, på en sådan måde, at data analyseres statistisk og, at der er sat intelligente alarmer der går på en sådan måde, at "lidt" defekte netværkskomponenter klart identificeres. Alt dette vil klart kunne fange og identificere switche, der kun fejler "lidt".

Meget lidt af det beskrevne er naturligvis gratis, selv om noget af det kun koster lidt, men driver man mission critical, så er det berettiget og tæt på påkrævet som et absolut minimum.

og hvis man påstår at ting er nemme, så er det fordi man ikke forstår problemerne og ikke har respekt for de


Jeg skriver blot, at ved man, hvad man skal kigge efter og gøre, så er det ikke så svært. Sagt på en anden måde, det er ikke rocket science, men der skal anvendes eksperter til at designe det og sætte det op. Endvidere skal man bruge eksperter til at designe en tolkning af indsamlede data, men tolkningen kan sagtens automatiseres. Der er ikke brug for ny viden, der skal ikke forskes i nye metoder. Vi har alle de værktøjer og teknologier, der skal til. De skal blot anvendes og anvendes fornuftigt. Deri lå det "nemme". Det nemme betyder ikke man kan have nogle lavt betalte teknikere til at fumle rundt med lidt netværksudstyr.

Kort fortalt. Jo man kan godt fange defekte switche, hvis man vælger at kunne og vælger at bruge de rigtige folk til at sætte det sammen.

  • 2
  • 2
Baldur Norddahl

På DKNOG var der et foredrag om "the evil chip". TDC oplevede en fejl i deres backbone, hvor et linjekort begyndte at lave et bitfejl i trafikken, dog sådan at CRC blev genberegnet korrekt. Pakkerne var med andre ord ok for en overfladisk test. Men data indeni var korrupt.

Det er fint nok at applikationslaget opdager at der er noget galt, men hvordan finder du den switch, som laver ballade?

  • 3
  • 1
Peter Mærsk-Møller

Hej Thomas

Desværre står mailserveren som distribuerer disse driftmeldinger på samme fejlfyldte netværk (gætværk). I al fald kom driftmeldingen ikke frem førend timer senere, da ting fungerede igen.

Har du ret, så viser det, at fejlscenarier ikke er tilstrækkeligt gennemanalyseret eller, man har valgt ikke at kunne rapportere fejl, når det net fejler. Begge dele er tankevækkende.

Dog kan der også være opståede en række ikke relaterede fejl samtidig. Det sker.

  • 0
  • 2
Peter Mærsk-Møller

Det er fint nok at applikationslaget opdager at der er noget galt, men hvordan finder du den switch, som laver ballade?

Det gør man ved at opsamle data for applikationer både på serversiden og på så mange klienter som muligt. Der findes programmer til det. Ud af datamaterialet kan man så med simple og nogle gange mere langhårede statiske metoder finde de netværkssegmenter, der fejler underforstået systemet er sat op så man har en fuld forståelse af, hvordan tingene er sat sammen.

Pointen omkring switchen, der fejler lidt er, at man ikke finder fejlen ved at opsamle data på switchen, men ved at opsamle data omkring de applikationer og services, der benytter switchen. Her er der dog en udfordring, da det kræver samarbejde på tværs af de administrative og operative søjler man typisk finder i et teleselskab lige som ikke alle netværkseksperter er specielt dygtige til statestik og ofte ej heller har større viden om applikationer på serversiden.

mvh
Peter

  • 2
  • 2
Baldur Norddahl

Peter, du ser ikke ud til at forstå pointen. Hos TDC viste alle analyser at der var fejl på nogle switche. Men det var bare de forkerte switche. Den egentlige fejl var på en helt anden switch. De switche der lavede pakketab fejlede absolut intet.

Kun ved at sample trafikken fra et punkt, hvor der ikke var pakketab, kunne man finde frem til hvad der foregik. Men vi kan jo altså ikke permanent køre med fuld logning af trafik på alle porte og der findes ikke noget software, som automatisk kan finde et problem, som det TDC beskriver. De fandt fejlen og det gjorde IBM/Nets også - men ikke uden manuel fejlsøgning, som tager tid.

  • 3
  • 1
Christian Nobel

Kort fortalt. Jo man kan godt fange defekte switche, hvis man vælger at kunne og vælger at bruge de rigtige folk til at sætte det sammen.

Jeg begynder at blive lidt i tvivl om du overhovedet ved hvordan en switch fungerer.

For jo man kan selvfølgelig godt begynde at omklamre switchen med hubs og andre switches (og så lige tage hensyn til de spanning tree problemer man så beder om) hvorved man ender i en voldsom kompleks og dyr opbygning der giver nye problemer i sig selv, eller man kan forlade sig på swichens egen monitorering.

Begge dele kan dog have umådeligt svært ved at fange problemet med "the evil chip" som Baldur omtaler, og som givetvis har været af den karakter hos IBM.

Det er altså også de færreste banevæsener der sætter et sæt skiftespor op før og efter et skiftespor, sådan bare for en sikkerheds skyld - og tænk på hvor mange skiftespor man så har der kan fryse til.

Og når det så drejer sig om en periodisk sjatfejl, så er er vilje og rette folk først løsningen, når man har indset (fanget, opdaget) at der er en fejl, og man har en ide om hvilken vej kikkerten skal rettes.

Jeg har så mange gange været ude for at foretage fejlsøgninger, hvor fejlen lå et helt, helt andet sted end det der på nogen måde virkede umiddelbart - og fandt IBM ikke fejlen i løbet af nogle timer?

At IBM så måske burde bruge noget tid på selvransagelse, især hvis det også var samme type switch der fejlede sidste gang, det er en helt anden sag.

  • 2
  • 2
Baldur Norddahl

Det er heldigvis billigere at bygge netværk end at lægge skinner :-). Almindeligvis har man mindst N+1 redundans, således at når du først har fundet den defekte switch, så kan du bare slukke for den. Så vil netværket af sig selv route udenom den.

Jeg gætter på at problemet i denne sag ikke var manglende redundans, men at finde frem til den komponent der fejlede. En helt død switch er meget bedre end en halvdød.

  • 2
  • 0
Peter Mærsk-Møller

Hej Baldur.

Peter, du ser ikke ud til at forstå pointen. Hos TDC viste alle analyser at der var fejl på nogle switche. Men det var bare de forkerte switche. Den egentlige fejl var på en helt anden switch. De switche der lavede pakketab fejlede absolut intet.

Prøvede nu ikke på at fortælle, hvordan man kunne finde fejlen hos TDC i den case, der blev postet, men forholdt mig såmænd bare til om det er muligt at fange den switch, som IBM havde problemer med. Og med det rette setup, kan man godt detektere de netværkssegmenter inkl. switche, hvor der måtte komme småfejl. Granulariteten af de netværkssegmenter man kan finde således, afhænger af setup'et. Vi kan hurtig opsætte scenarier, hvor granulariteten er stor og indsigten derved stærkt begrænset og sikkert uden særlig værdi, men omvendt kan vi også opsætte scenarier, hvor granulariteten er lille med meget præcise individuelle billeder af selv små segmenter og her bliver det jo så nemmere.

Men som sagt, skal ikke pt. kunne sige, hvad TDC kunne have gjort bedre, da jeg ikke har studeret den case. Beklager, hvis det har givet anledning til misforståelser.

mvh
Peter

  • 0
  • 2
Peter Mærsk-Møller

Hej Christian

Jeg begynder at blive lidt i tvivl om du overhovedet ved hvordan en switch fungerer.

For jo man kan selvfølgelig godt begynde at omklamre switchen med hubs og andre switches (og så lige tage hensyn til de spanning tree problemer man så beder om) hvorved man ender i en voldsom kompleks og dyr opbygning der giver nye problemer i sig selv, eller man kan forlade sig på swichens egen monitorering.

Jeg skal ikke kunne sige, hvorfor du mener jeg ikke forstår switche eller antyder at jeg foreslår hubs og andre netværkskomponeneter. Måske er det fordi jeg foreslår, at med måling på applikationsniveau, kan man fange både netværkskomponenter, der fejler totalt, men også netværkskomponenter, der begynder at fejle lidt.

Den software jeg tænker på, er en software med et lille ressourcemæssigt footprint, der for et stort antal klienter måler den service de pågældende klienter får, fra et antal servere. Data fra disse klienter konsolideres automatisk og grundet de store tals lov, bliver de enkelte hændelser lige gyldige, men et større antal anormale hændelser, vil indikere problemer. Sammenlignes data automatisk med en baseline indhentet på et tidspunkt, hvor alt fungere normalt, ville der forekomme signifikante ændringer i de konsoliderede måledata, når netværkskomponenter begynder at småfejle. Sammenholdes de målte data med den faktiske og fysiske netværkstopologi, vil det hurtigt kunne fastslås, hvor omtrent problemerne opstår. Med en velgennemtænkt opsætning, vil man endda kunne fastslå helt ned på switchniveau, hvor fejlen opstår. Har man hot swap redundans, vil man kunne lave det sådan, at et netværkssegment eller endda en switch automatisk kobles ud og en alarm sendes til en tekniker med henblik på enten udskiftning eller i det mindste en manuel analyse.

Den specificerede metode virker og jeg har været medvirket til design og opsætning af sådanne systemer. Men det skal da indrømmes, at det er muligt at specificere scenarier, hvor de foreslåede metoder ikke vil kunne implementeres. Det er dog ikke min opfattelse, at det er aktuelt her. Men som altid, man og specielt jeg kan jo tage fejl, men så må man jo bare se om der er andre indirekte metoder man kan anvende til at opnå det samme.

SKulle det ikke være klart, så foreslår jeg ikke at man måler direkte på porttrafikken. Jeg foreslår heller ikke at man ud fra switchens SNMP-data i det konkrete tilfælde kan se noget fornuftigt, der kan bruges til at finde fejl.

mvh
Peter

  • 1
  • 2
Lasse Hillerøe Petersen

Er der nogen der ved hvor Nets gemmer en evt driftstatusside? På http://www.nets.eu/dk-da/Pages/default.aspx er der en fin lille tekst der popper op hvis man ved et tilfælde kommer til at køre musen hen over det rigtige sted, men jeg har ledt forgæves efter en rigtig side. Der er vist potentiale i at sælge lidt UX-design til Nets...

  • 0
  • 0
Henrik Kramshøj Blogger

Jeg sad tilfældigvis i denne weekend og læste denne sjove historie:
http://mina.naguib.ca/blog/2012/10/22/the-little-ssh-that-sometimes-coul...

om bitfejl langt ude i netværket, tak til Claus for linket.

Den viser at der KAN ske sjove ting med pakkerne ude omkring, og jeg vil anbefale folk at være lidt mindre skråsikre med hvad der kan lade sig gøre og hvordan man laver robuste systemer. Der er mange forudsætninger for at kunne opdage og fjerne fejl. DOG bør man i hvert tilfælde prøve at gøre sine systemer mere robuste fremover, jo mere man ved - så man ikke rammes af de samme fejl gentagne gange.

  • 4
  • 0
Baldur Norddahl

Mærkeligt du får toms down, for at påpege at det ikke at kunne finde fejlen skyldes mangle på kompetance.

Det er ikke det han får thumps down for. Det er for påstanden om at det altid vil være muligt at opbygge nettet, så at alle fejl findes automatisk. Det er bare for naivt. Det er et ideal. Men de er ikke nødvendigvis dumme og inkompetente blot fordi det mislykkedes. Det er de kun hvis de ikke lærer af fejlen.

Jeg bemærker - igen - at de godt kunne finde fejlen. Det krævede blot manuel fejlsøgning og den slags tager tid.

  • 2
  • 1
Christian Nobel

Jeg bemærker - igen - at de godt kunne finde fejlen. Det krævede blot manuel fejlsøgning og den slags tager tid.

Præcis, og det er også derfor jeg siger at man skal have respekt for problemtikken, og ikke påstå at der findes en nem løsning til forlods at kunne finde problemet.

For at skære det ud i pap:

Hvis man har et switched Ethernet, hvor der bruges on-the-fly switche, og en af disse begynder at småfejle, således at der introduceres en fejl på lag 2, så vil fejlen først blive fanget når man enten går igennem noget store-and-forward udstyr med CRC check, eller bevæger sig op på lag 3.

I begge tilfælde behøver det ikke være den nærmeste nabo til enheden der genererer fejlen som opdager den.

Hvis en switch ryger ned med et brag, så er opgaven triviel, men isolerede bitfejl kan være pokkers svære at fange på udstyr der af natur er transparent.

Det er for påstanden om at det altid vil være muligt at opbygge nettet, så at alle fejl findes automatisk. Det er bare for naivt.

Man må også vælge sine slag med omhu - som regel er der så langt mellem en switch ryger i dørken, og problemet med the evil chip forekommer så sjældent, at man kynisk må overveje om det kan betale sig at indklamre netværket med overvågningsudstyr, så man risikerer at generere en ny fejlkilde.

Men det er klogt at evaluere, når fejl sker, helt korrekt.

  • 1
  • 1
Log ind eller Opret konto for at kommentere