'Uforklarlige netværksproblemer' lammer Statens IT og flere ministerier

Netværksproblemer hos Statens IT har sendt flere ministeriers hjemmesider til tælling, og derudover vil alle Statens IT's kunder sandsynligvis opleve udfald i forskellig grad, oplyser Statens IT.

En stikprøve foretaget af Version2 viser, at mindst tre ministerier har problemer med deres hjemmesider. Erhvervsministeriet oplyser, at fejlen for deres vedkommende ligger hos Statens IT.

Sådan ser det ud, når man forsøger at tilgå Erhvervsministeriets hjemmeside. Illustration: Mads Lorenzen, screendump

Statens IT er da også selv blevet lagt ned af, hvad pressechef Louise Veino kalder 'netværksproblemer'. Ifølge pressechefen betyder det, at flere af ministeriernes og Statens IT's hjemmesider ikke kan tilgås.

»Netværksproblemerne er sporadiske, men rammer bredt. Det betyder også, at alle vores kunder bliver ramt bredt og oplever udfald på deres systemer. Dermed ikke sagt, at intet fungerer, for der er tale om udfald, ikke et nedbrud,« siger Louise Veino, der fortæller, at Statens IT oplevede de første alarmer fra deres netværksovervågning omkring middagstid.

Fejlrettelse skabte ny fejl

Statens IT oplyser til Version2, at det var en fejlrettelse, der åbnede for nye problemer hos den statslige it-leverandør.

»Der var en fejl på vores centrale netværk, som vi skulle udbedre – og i forbindelse med denne udbedring opstod der desværre driftsustabilitet på vores netværk i form af et netværksloop,« skriver Louise Veino i en mail til Version2 og understreger, at nærmere kan hun ikke komme det.

Umiddelbart var det kun Erhvervsministeriet, Uddannelses- og Forskningsministeriet og Transportministeriet, der har problemer med hjemmesiderne. Andre ministerier ser ud til at være oppe. Det vides ikke, om de øvrige systemer, Statens IT leverer til det offentlige, også er berørt.

Artiklen er opdateret 22/10 kl. 13:45 med uddybende kommentarer fra Louise Veino.

Artiklen er opdateret 23/10 kl. 10:30 med årsag til og varighed af nedbruddet.

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

Nogen gange kan et nedbrud faktisk være ganske trivielt, men uforudsigeligt af natur.

Jeg har oplevet hele netværk trukket ned af en enkelt netværkskomponent som en hub eller en switch, trods det netværket faktisk var ganske fornuftigt opbygget - og selvfølgelig kan man prøve at sikre sig i h&r mod nedbrud, men Myrphy er altid en trofast følgesvend.

Så der behøver såmænd ikke være så meget andet i det, end det selvfølgelig er drønirriterende.

  • 10
  • 0
Lars John Jørgensen

Rent teknisk er det for fattigt at man ikke vil dele den viden man har fået - kun ved at lære af fejl kan vi alle blive bedre.

Desværre skal man nok ikke forvente for meget fra den kant. Den statslige sektor er kendt for at feje fejl under gulvtæppet i stedet for at lære af dem. Indrømmer man fejl i staten knækker karriere-stigen...

  • 9
  • 0
Klavs Klavsen

Jeg har oplevet hele netværk trukket ned af en enkelt netværkskomponent som en hub eller en switch, trods det netværket faktisk var ganske fornuftigt opbygget - og selvfølgelig kan man prøve at sikre sig i h&r mod nedbrud, men Myrphy er altid en trofast følgesvend.


Selvom de havde Spanning Tree Protokollen opsat? Den afhjælper det meste.. bortset fra defekte switche og "halv-forbundne/defekte" kabler som ikke er defekte nok til at blive detekteret automatisk.
Men disse problemer, kan en god overvågning hjælpe på at detektere meget hurtigt - desværre ser jeg meget meget få steder, der indsamler al den data man faktisk kan få fra switche (via SNMP typisk), samt klient overvågning (pakketabscheck fra klienterne af f.ex. til de endpoints de skal snakke med) og får opbygget en fornuftig overvågning heraf.

  • 1
  • 0
Christian Nobel

Selvom de havde Spanning Tree Protokollen opsat?

Øh ja.

Spanning tree har primært betydning på installationstidspunktet, det ændrer sådan set ikke så meget hvis en netværkskomponent senere svigter - men som de fleste top-down netværker er opbygget nu om dage, så er riskoen for loops begrænsede.

Apropos spanning tree (vi taler lag 2 her), så skal man i øvrigt også huske, som en klog mand engang sagde til mig, at Kirchoff's love gælder ikke for datanetværker.

Og hvis du skal overvåge en switch, så et det altså absolut ikke trivielt at opsætte en fornuftig SNMP installation - og det fordrer i øvrigt at switchene er intelligente før det er relevant.

  • 0
  • 1
Klavs Klavsen

Så dyr er en intelligent switch ikke.. Ingen seriøs drift kører forhåbentlig på en ikke-intelligent switch :)
Med f.ex. https://www.robustperception.io/snmp-monitoring-with-prometheus (prometheus + grafana) kan man ret nemt bygge dashboards til at give et godt overblik - og så har jeg fundet mange netværksproblemer (fw cpu'er der var overloadede i spikes, fiber kabler der ikke helt virkede osv.) - ved at have ordentlig klient overvågning (overvågning af IO waits - og se alle hosts på tværs - identificerer generelle IO problemer, hvis de ligger på et delt SAN) - og f.ex. vedligeholder vi en liste af destinationer vores servere skal kunne nå i vores centrale (puppet) config - så vi definerer al config for den givne service (og dermed dens servere) - og så indstilles firewalls til kun at kunne nå de destinationer (så glemmer man ikke nogen ;) - og så sender den automatisk 100 tcp syn pakker hvert 5. minut - og ser om den får alle 100 syn-ack's tilbage.. Det fanger faktisk forbløffende mange netværks ressource problemer - og hvis man så lige laver lidt scripted tegning (destinationer+kilder overlayed med fysiske netværks enheder) - så kan sådanne fejl, hjælpe kraftigt til at finde nålen i høstakken :)

Jeg smider de tal ind som tællere til noget ligesom prometheus (graphite idag) - så man kan have en samlet graf, der nemt viser hvis nogen endpoints har pakketab. Det tog mig faktisk ikke mere end én dag - da vi jo allerede havde monitoring backend kørende - så var det bare en smule perl + lidt opbygning af dashboard i grafana.

  • 1
  • 0
Anne-Marie Krogsbøll

Nogen havde glemt at teste, inden man førte rettelser over i produktionssystemet?


Fra opdateringen i artiklen..

"Statens IT oplyser til Version2, at det var en fejlrettelse, der åbnede for nye problemer hos den statslige it-leverandør.
»Der var en fejl på vores centrale netværk, som vi skulle udbedre – og i forbindelse med denne udbedring opstod der desværre driftsustabilitet på vores netværk i form af et netværksloop,"

Nærmere kommer vi det nok ikke.....

  • 0
  • 0
Klavs Klavsen

Spanning tree har primært betydning på installationstidspunktet, det ændrer sådan set ikke så meget hvis en netværkskomponent


Jeg har set flere steder, hvor nogen "lige kablede noget" og så gik ting i skoven pga. manglende STP - og det kostede noget ordentlig oprydning bagefter.. de færreste har alt på plads ved opsætningstidspunktet desværre :)

  • 0
  • 0
Christian Nobel

Jeg har set flere steder, hvor nogen "lige kablede noget" og så gik ting i skoven pga. manglende STP - og det kostede noget ordentlig oprydning bagefter.. de færreste har alt på plads ved opsætningstidspunktet desværre :)

Og så er det faktisk meget sjovt, for i det citat fra Anne-Marie lige ovenfor, så er det åbenbart præcist det der er sket.

Det ville så være rart at vide hvem der er leverandøren.

Men overvågningen er IMHO den vigtigste

Sådan set ikke uenig, men det er bare desværre ikke sådan virkeligheden altid ser ud, eller at nettet har en størrelse hvor det er en realitet.

  • 0
  • 0
Christian Nobel

Det lyder faktisk præcis som om et problem korrekt opsat STP burde have fandet, og lukket den ene port (og logget at den gjorde det - hvilket de så burde reagere på)

Er de fleste switche, hvis vi bare lige er et niveau over det allerbilligste, nu om dage ikke mere eller mindre født med en STP algoritme, som lukker porten hvis den ser samme MAC adresse optræde på begge sider af porten?

  • 0
  • 0
Klavs Klavsen

Sådan set ikke uenig, men det er bare desværre ikke sådan virkeligheden altid ser ud, eller at nettet har en størrelse hvor det er en realitet.


Man har vel altid en der laver overvågning af servere - og for dem er det altså nemt også at overvåge netværksenheder.. (som du så i mit link til prometheus ovenfor :)

iøvrigt checker mit script også lige at alle dns navne kan resolv'es - så man fanger hvis der f.ex. er dns problemer.. Netværks byggesten er rigtig trælse når de fejler, hvis ikke man overvåger dem direkte - så ser man kun de afledte affekter og spilder nemt tiden.

  • 0
  • 0
Klavs Klavsen

Er de fleste switche, hvis vi bare lige er et niveau over det allerbilligste, nu om dage ikke mere eller mindre født med en STP algoritme, som lukker porten hvis den ser samme MAC adresse optræde på begge sider af porten?


kva. hvad der åbenbart skete her - så nej? :)

Normalt skal man aktivt slå STP til.. og jeg ved ikke noget om det du taler om her i nyere switche.. Har altid kun set switche hvor man skulle slå det til i config.

Men STP har jo den fordel at den virker på tværs af ALLE switches på samme net - så den også fanger og "fikser" det, når man laver et loop på tværs flere switche på samme net. Det tænker jeg ikke noget "automatisk" ville kunne?

  • 0
  • 0
Klavs Klavsen

Sådan set ikke uenig, men det er bare desværre ikke sådan virkeligheden altid ser ud, eller at nettet har en størrelse hvor det er en realitet.


Vi kan godt blive enige om at når man har en størrelse som Statens-IT - så er det for dyrt IKKE at have ordentlig overvågning?

Og det er altså ikke særlig dyrt at lave, hvis du har kompetente folk på opgaven - og de kan bruge eksisterende prometheus (eller lign. metric store + overvågning) + grafana til opgaven.

Hvis du ikke har ordentlig overvågning (der kan se på metrics på tværs af systemer og alarmere på dem) - så skal det selvf. opsættes først.

  • 0
  • 0
Christian Nobel

Vi kan godt blive enige om at når man har en størrelse som Statens-IT - så er det for dyrt IKKE at have ordentlig overvågning?

Absolut ikke uenig - men alligevel så viser virkeligheden sig så at være en anden.

Ud fra det lidet vi ved om historien, så kunne man gætte sig til at der nok er røget en switch, hvilket i sig selv er hvad der kan ske, men så har man i panik skiftet den og kylet patchkablerne i uden at bruge den indvendige side af hovedet - og så går det galt.

Så de kan sådan set godt have haft en ok overvågning, men da de så skulle udbedre fejlen, så var det balladen opstod.

  • 0
  • 0
Klavs Klavsen

Men når vi kommer længere ned i hierakiet (mao. ned i størrelse) og befinder os der hvor 98,7% af samtlige danske virksomheder er, så ser verden altså anderledes ud - desværre.

Jeg er helt enig i at det for mindre/mellemstore virksomheder (og nogen gange selv de store) ikke kan betale sig at have sine egne folk til opgaven..

Men det findes adskillige services, der laver sådan overvågning som en service..

Jeg driver selv en af slagsen, netop foranlediget af at jeg har bygget den slags for adskillige store virksomheder, og har måtte fortælle en del mindre firmaer, at vedligeholdelse af et godt overvågningssetup så absolut ikke er gratis og derfor er for dyr en opgave, deres størrelse taget i betragtning.

Og som en der laver den slags, synes jeg det er uinteressant at bygge den samme overvågning for flere forskellige kunder - så er det mere interessant at bygge det ét sted - og så kan alle kunder få glæde af det. Det er også derfor vi bygger alt på Open Source - og helst ikke laver forbedringer/ændringer i koden - uden også at lave en Pull-Request til upstream.

  • 1
  • 0
Christian Nobel

Jeg er helt enig i at det for mindre/mellemstore virksomheder (og nogen gange selv de store) ikke kan betale sig at have sine egne folk til opgaven..

Men det findes adskillige services, der laver sådan overvågning som en service..

Det er nu sådan set ikke et spørgsmål om hvorvidt det kan betale sig, men om at man ikke vil bruge penge på det.

Jeg har selv tidligere beskæftiget mig med salg af overvågningsløsninger, og det er altså op ad bakke - mange virksomheder behandler desværre deres netværker som et stedbarn, og bare det at skulle ofre nogle få tusinde kroner, i selv en stor virksomhed, er et helvede at få igennem.

Hvorimod der sjovt nok ikke er nogen problemer med prisen på de firmabiler der står på parkeringspladsen.

Og som en der laver den slags, synes jeg det er uinteressant at bygge den samme overvågning for flere forskellige kunder - så er det mere interessant at bygge det ét sted - og så kan alle kunder få glæde af det. Det er også derfor vi bygger alt på Open Source - og helst ikke laver forbedringer/ændringer i koden - uden også at lave en Pull-Request til upstream.

Hatten af :-)

  • 0
  • 0
Morten Brørup

og så sender den automatisk 100 tcp syn pakker hvert 5. minut - og ser om den får alle 100 syn-ack's tilbage.


Snedigt!

Vores StraightShaper-produkter har en Network Latency Monitor, der sender en enkelt ping-pakke en gang i sekundet for at måle og visualisere latency, jitter og pakketab. Det bliver til 300 pakker på 5 minutter, altså samme størrelsesorden som dine 100 pakker hvert 5. minut.

Hvis vi ser bort fra applikationsmonitoreringsaspektet og at mange servere som standard ikke svarer på ping, og kun forholder os til det som ren netværksovervågning, er de to metoder nogenlunde sammenlignelige. Der er dog en væsentlig forskel:

Med din metode er der begrænset sandsynlighed for at detektere netværksudfald af få sekunders varighed, fordi netværksudfaldet skal ske på præcis det samme tidspunkt, som du sender dine testpakker.

Hvis netværket er kontinuerligt hårdt belastet, kan der være begrænset sandsynlighed for at vores metode detekterer det, fordi visse typer netværksudstyr sjældent taber en enlig pakke. Derimod vil enhver overbelastet switch/router give pakketab på et burst af 100 pakker, så din metode vil detektere det.

Har du gjort dig nogen tanker om dette?

Og af ren nysgerrighed: hvor hurtigt efter hinanden sender du de 100 TCP SYN-pakker?

mvh
Morten Brørup
CTO, SmartShare Systems

  • 0
  • 0
Klavs Klavsen

Har du gjort dig nogen tanker om dette?

Bestemt.. det er ingenlunde perfekt - og jeg kan også konstatere at der er pakketab, som ingen gider gøre noget ved :(

Det har vist sig at den test hvert 5. minut har været tilstrækkelig til at den ping'er når vi har et reelt problem, selvom den bestemt ikke vil fange alle situationer..

Og allerhelst burde switch portene overvåges betydeligt bedre :)

Jeg sender aldrig en syn-ack - så min tcp-ping når aldrig at fuldende tcp-handshaket - og derfor er det et meget bililgt check for serverne - da det aldrig når forbi kernen - så jeg kunne godt checke med større interval hvis det skulle være.

Og af ren nysgerrighed: hvor hurtigt efter hinanden sender du de 100 TCP SYN-pakker?


så hurtigt jeg kan.. (bruger lige nu bare https://metacpan.org/pod/AnyEvent::Ping::TCP ) De fylder uendeligt lidt - da det jo kun er en SYN pakke - og generer heller ikke modtageren, da jeg aldrig får fuldendt tcp handshaket.

  • 0
  • 0
Morten Brørup

Det er godt tænkt, Klavs.

jeg kan også konstatere at der er pakketab, som ingen gider gøre noget ved :(


Hmm... Hvis pakketabet overstiger 1 % er det generelt et problem, der skal gøres noget ved. Ved mindre tabsrater bliver det hurtigt en smagssag, selvom det egentlig burde afhænge af applikationernes behov. Og ja, desværre er folk ikke altid så lydhøre overfor præventivt vedligehold - især hvis det koster deres tid og/eller penge.

Jeg sender aldrig en syn-ack - så min tcp-ping når aldrig at fuldende tcp-handshaket - og derfor er det et meget bililgt check for serverne - da det aldrig når forbi kernen


For de uindviede kan jeg oplyse, at TCP-stakken i kernen venter til den modtager ACK-pakken fra klienten, før den giver server-applikationen besked om den indkommende TCP-forbindelse. Det er fx beskrevet i denne artikel: How TCP backlog works in Linux

Og allerhelst burde switch portene overvåges betydeligt bedre :)


Ja. I princippet burde SNMP etherStatsDropEvents og ifInDiscards/ifOutDiscards tælle hastigt frem, når det går galt. Har du nogen erfaringer med det?

Og af ren nysgerrighed: hvor hurtigt efter hinanden sender du de 100 TCP SYN-pakker?
så hurtigt jeg kan.. (bruger lige nu bare https://metacpan.org/pod/AnyEvent::Ping::TCP ) De fylder uendeligt lidt - da det jo kun er en SYN pakke


Enig. Sådan et microburst fylder kun ca. 6,4 KB i swichens pakkehukommelse, så her kan selv en billig unmanaged switch følge med uden pakketab, hvis den ikke er overbelastet. Også i en netværkstopologi, hvor switchen er nødt til at buffere størstedelen af dine SYN-pakker, fx hvis de ankommer på en 10 Gbit/s-port og afsendes på en 100 Mbit/s-port.

mvh
Morten Brørup
CTO, SmartShare Systems

  • 0
  • 0
Morten Brørup

så smider router/switche gerne icmp ping pakker først, så hvis vi har pakketab på icmp pakker er alle netværksadmins ligeglade.


Ping-pakker til en routers/switchs egen IP-adresse har tendens til at blive prioriteret lavt, da disse pakker skal håndteres af routerens/swichens management-CPU, som ofte er en 200 MHz 32 bit single core MIPS eller lignende - jeg har endog set flere forskellige 8 bit 8051-lignende CPUer blive brugt i billige managed switche. Derfor er der ind imellem meget stort jitter, hvis man pinger en router/switch.

Og derfor kan man ikke altid læse så meget ud af ping-målinger på kontrolplanet i en switch/router.

Men hvis man i et almindeligt netværk har konfigureret sine switche/routere med QoS på en sådan måde, at dataplanet håndterer ICMP ECHO anderledes end almindelige datapakker, er der - efter min mening - noget helt galt med den måde, man bruger QoS. (Der kan naturligvis være undtagelser, fx satellitforbindelser.)

mvh
Morten Brørup
CTO, SmartShare Systems

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