Nedbrud: Når man kæmper mod uret

Der er altid to sider af en mønt, og i det meste af den tid, jeg har haft æren af at skrive på version2, har jeg fortalt om vores optur, vores succes og alle de ting, vi generelt er lykkes med.

I dag skal det handle om det modsatte - et nedbrud, vi har haft i den forløbne uge, som har trukket tænder ud.

Det trækker op til storm

Det startede, da vores kundeservice en formiddag begyndte at modtage mange opkald fra brugere i et specifikt område i København.

Kunderne klagede over, at de lige pludselig ikke kunne komme på internettet.

Vores overvågningssystem, der pinger samtlige kunder hvert 5. minut og holder øje med kundernes DHCP leases, havde ikke registreret nogen udfald. De kunder, som klagede, svarede på ping, og de havde også en DHCP-lease, hvilket måtte betyde, at der i hvert fald var en eller anden form for hul igennem.

Når vi loggede ind på en fejlramt kundes router og foretog en række tests derfra, kunne vi se, at trafikken tog den helt forkerte vej ud på internettet.

I stedet for at blive routed gennem vores samarbejdspartners netværk og ind til os, blev trafikken sendt direkte ud på internettet gennem samarbejdspartnerens egne peering-links.

Det burde ikke kunne ske, da vores samarbejdspartner kører vores trafik i en separat VRF, som er en virtuel routing-instans.

Det svarer til, at man adskiller et fysisk netværk i to adskilte netværk, som ikke kommunikerer med hinanden, selv om begge netværk anvender det samme fysiske hardware.

Kontrol af samarbejdspartnerens routere viste, at alt så normalt ud - men ikke desto mindre kunne vi konstatere, at trafikken fra kunderne endte i den forkerte VRF.

Konfigurationen så helt korrekt ud, og der var ikke foretaget nogen ændringer, der åbenlyst kunne forklare, hvad der gik galt.

Vi nåede derfor frem til, at der måtte være tale om en softwarefejl i routerens firmware, som fik den til at smide trafikken over i den forkerte VRF.

Det er en kritisk fejl, for de af vores kunder, som ikke har en offentlig IP-adresse, skal routes forbi vores CGN-routere for at komme på internettet - hvis de routes direkte på internettet, vil trafikken blive droppet med det samme, da de IP-adresser, der anvendes til CGN, ikke kan bruges på det offentlige internet.

Damned if you do - damned if you don't

Nu var gode råd dyre - vi kunne vælge at genstarte en specifik router hos vores samarbejdspartner, men det ville gå ud over mange flere end blot de fejlramte kunder, da en af opkoblingerne fra vores samarbejdspartner til TDC ikke er redundant.

Og generelt er en genstart af fysisk hardware den sidste udvej, medmindre man kører Windows.

Vi startede derfor med at genstarte nogle specifikke interfaces - det tager kortere tid, og håbet var, at det ville trigge en ændring i routerens tilstand, så den ville virke korrekt igen.

Det gjorde ingen forskel - og da vi var tæt på middagstid, og de berørte kunder havde været uden internet i en times tid eller to, måtte vi tage den tunge beslutning at genstarte den router, vi mistænkte for at være fejlramt.

Efter genstarten, som tog ca. 15 minutter, måtte vi konstatere, at det kun havde løst problemet for nogle af de berørte kunder, mens andre kunder stadig var ramt.

Nu begyndte det at blive rigtig træls, for at sige det på godt jysk - i alt var det ca. 400 kunder, der var ramt, og selv om vi holdt vores kunder opdaterede om situationen via Facebook, kunne vi mærke, at henvendelserne til kundeservice blev flere og flere.

Og hvad værre var, vi havde ingen løsning på problemet, for alt så korrekt ud i vores samarbejdspartners konfiguration.

Et nødvendigt hack

Når man står over for et uløseligt problem, kan man reagere på mange måder. Man kan blive frustreret, man kan give op, man kan skyde skylden på andre eller på sig selv - men ingen af disse reaktioner får problemet til at gå væk.

Det kan derfor være nødvendigt at improvisere, når man står i situationen.

Mens vi sad i de indledende faser og fejlsøgte, var der en mulig løsning, som begyndte at materialisere sig i mit baghoved.

I november 2016 købte vi et /21-scope af offentlige IP-adresser fra Styrelsen for IT og Læring, som solgte ud af deres IP-adresser, og det scope havde vi endnu ikke taget hul på.

Et /21-scope er 2.048 IP-adresser, og vi havde ca. 400 fejlramte kunder.

Hvis nu vi kunne give hver af disse fejlramte kunder en offentlig IP-adresse, kunne de i det mindste komme på nettet, selv om trafikken ikke blev routed gennem vores eget netværk.

Mens vores samarbejdspartner fortsatte fejlsøgningen på deres netværk, gik vi derfor i gang med at tildele offentlige IP-adresser til de berørte kunder.

Det er ikke en simpel opgave, når man kæmper mod uret og skal være kreativ på kommando - ideelt set skulle det løses med et script, men vi skulle også passe alvorligt på, det ikke gik ud over resten af vores adskillige tusinde kunder, hvis internet virkede fint.

Hvert minut, der bruges på at udtænke en kreativ løsning, kunne have været brugt på at løse opgaven på lavpraktisk maner, og i en krisesituation er man derfor nødt til at prioritere, om man har tid til at løse problemet på smukkeste vis, eller om man skal bruge en mere primitiv, men til gengæld let tilgængelig løsning.

Derfor besluttede jeg mig for at gennemføre opgaven manuelt med en række SQL-kommandoer og en CLI til databasen i vores CRM-system.

Det tog lige knap en time at tildele offentlige IP-adresser, og de fejlramte kunder begyndte lige så stille at komme på igen.

Lidt for stille.

Det viste sig, at vores DHCP-servere stadig uddelte de gamle CGN-adresser til visse af kunderne, og så måtte jeg i gang med at debugge på dem også.

En fejl i synkroniserings-mekanismen mellem vores CRM-system og database-clusteret bag DHCP-serverne havde gjort, at visse kunde-abonnementer var oprettet to gange - og opdateringen af kundens IP-adresse var kun slået igennem på den ene kopi.

Efter en hurtig oprydning i databasen kom resten af kunderne online i løbet af få minutter, og vi kunne begynde at trække vejret normalt igen.

Stilhed efter stormen

Vores samarbejdspartner arbejder lige nu sammen med hardwareproducenten om at finde en permanent løsning på softwareproblemet i den pågældende router.

Vi har en mistanke om, at fejlen skyldes en halv-bagt implementation af et såkaldt BVI-interface, der anvendes som et virtuelt loopback-kabel, men før vi begynder at rykke for meget rundt på netværket, skal vi have konstateret, om der er hold i vores mistanke.

I mellemtiden har jeg dannet nogle konklusioner i vores ende:

  • Det er vigtigt at have en proaktiv kommunikation med kunderne, især når der er problemer. Drengene i vores kundeservice gjorde en fremragende indsats med at holde kunderne opdateret, men en automatiseret besked direkte pr. SMS til de berørte kunder havde hjulpet dem meget
  • Pingtest af kunders udstyr er ikke nok. Det skal også testes, om de har hul igennem til internettet generelt
  • Man må aldrig gå ned på cola
  • At kunne skrive hurtigt på et tastatur er generelt guld værd, men er ekstra vigtigt, når man har travlt. Jeg sender en dybfølt tak til Ingrid, som i 6. klasse hev os igennem de ugentlige lektioner i elektronisk tekstbehandling. Det er nok det skolefag, der har haft den bedste ratio mellem tidsforbrug og nytteværdi nogensinde!

Kære læser - har du selv stået midt i et nedbrud, og hvad gjorde du for at holde hovedet koldt og løse problemet - mens chefen stod og rev sig i håret, og kollegerne løb i cirkler?

Yoel Caspersens billede
Yoel Caspersen er direktør hos Kviknet, har en baggrund som udvikler og har gennem en længere årrække beskæftiget sig med udvikling af hostede PBX-løsninger, internetbutikker og software til online video- og tv-distribution. Dagbog-bloggen er en stafetblog for iværksættere.

Kommentarer (33)

Jn Madsen

God fejlretning, hatten af :-)

Man leder altid efter noget der er fælles for fejlmeldingerne.
Desværre er der fejl,- dem man finder og kan rette, og så er der dobbelt fejl.
Skjulte fejl der udløses af en anden fejl. En potentiel katastrofe der venter på at noget andet udløser den.
Det giver forvirrende fejlbilleder, det er svært at finde fællesnævneren for de målepunkter man har.

Jeg har ingen gode råd, - erfaring, interesse, masser af tid i lab tests ... så bygger man stille og roligt på arsenalet man bruger "when the shit hits the fan".

Men det ser ud til, at du har haft den "luksus", at alle berørte kunder havde en backbone router som fællesnævner. Det er da en god start.
Havde du ingen advarsler omkring CPU eller RAM?
Hvorfor virkede det den ene dag og ikke den næste?
Er der en grænse for hvor meget trafik/konfigurationer den pågældende router kan bære?

Jeg er nok lidt for bundet af "hold kæft klausuler" til at jeg vil nævne konkrete fejlretninger.

Claus Juul

Husk nu at udnytte katastrofen, ret op på de fejl I er støt på og undersøg hvorfor de er sket bla. Den med synkroniseringen mellem Crm og DHCP.

Rasmus nix

Fedt, at du fortsat holder os opdateret :)

Kan næsten ikke forestille mig, hvor presset man er i sådan en situation. Hele ens forretning kan være ødelagt på så få timer, og man aner ikke, hvad der er galt.

Yoel Caspersen Blogger

Havde du ingen advarsler omkring CPU eller RAM?

Mig bekendt nej. Nu var fejlen i vores samarbejdspartners router, men der var ingenting, der indikerede, at den var i en fejltilstand - og havde vi ikke undersøgt fejlen fra brugernes side af netværket som noget af det første, havde det taget os endnu længere tid at finde ud af, hvor problemet lå.

Hvorfor virkede det den ene dag og ikke den næste?

BVI-interfacet var sat op et par dage tidligere, da vi skulle have udvidet kapaciteten i netværket på grund af vores vækst. Indtil da havde vi anvendt et fysisk loopback-kabel (endnu et hack, som bruges i mange setups rundt omkring), men vi skulle have frigjort portene, så vi kunne opgradere kapaciteten på backbonen.

Det første stykke tid virkede BVI-interfacet som dokumenteret af producenten, og vi ved ikke, hvad der helt præcist udløste fejlen - derfor er producenten sat på sagen.

Det er i øvrigt endnu en ting, der taler for en løsning baseret på software-routere - en hardware-router kan håndtere langt større trafikmængder, men til gengæld er det en black box, hvor kun producenten (og diverse efterretningstjenester) har indsigt i kildekoden bag firmwaren. Software-routere baseret på Linux er langt nemmere at debugge på, og bugs i open source software er generelt veldokumenterede og nemt tilgængelige, mens proprietær software kan indeholde hvad som helst.

Er der en grænse for hvor meget trafik/konfigurationer den pågældende router kan bære?

Givetvis. Nogle af disse limits er kendte, mens andre er hemmelige eller udokumenterede.

Jn Madsen

Det er i øvrigt endnu en ting, der taler for en løsning baseret på software-routere

Helt enig, det er fremtiden. Nogle af teknologierne er modnet meget, andre er ved at ende i ingenting.

Hvis jeg i dag skulle skyde noget i gang, så ville jeg bruge Mikrotik som CPE'ere og Cumulus Networks til alt andet.
Det burde kunne gøres, men jeg ved ikke om Cumulus kan gøre hele ISP delen. Det skulle ihvertfald tjekkes.

Ellers bare en stak refurbed Juniper grej. Der er ikke så meget pjat, det virker.

Yoel Caspersen Blogger

Husk nu at udnytte katastrofen, ret op på de fejl I er støt på og undersøg hvorfor de er sket bla. Den med synkroniseringen mellem Crm og DHCP.

Det er en vigtig pointe, som ikke kan gentages for tit. Man skal lære af fejl, og forbedre sit system, i stedet for at feje dem væk under gulvtæppet og håbe på, de forsvinder af sig selv.

At fortælle andre om de fejl, man begår, kan være en mental øvelse i sig selv, men jeg tror på, det er en fordel i sidste ende.

I den konkrete case med synkroniseringen mellem CRM-systemet og MySQL-clusteret bag DHCP-serverne var der ingen kontrol af, om et abonnement tilfældigvis fandtes flere gange i DHCP-databasen. Scriptet, der foretager synkroniseringen som et cron-job, opdaterede således kun den første instans af et givent abonnement, og der var ingen kontrol af, om et abonnement var oprettet to gange i databasen, da forudsætningen er, at scriptet kun opretter abonnementet, hvis det ikke findes i forvejen.

Den elegante løsning på dette er naturligvis at indføre et unikt index på abonnements-ID'et i MySQL-clusteret bag DHCP-serverne, så et abonnement ikke kan optræde to gange. Det forklarer ikke, hvorfor fejlen er opstået i første omgang, men det kan forhindre, at det sker igen, og det gør systemet mere robust.

Yoel Caspersen Blogger

Første skud i fejlretningen kunne have været at rulle tilbage til gammel opsætning?
Det kræver så lige, at man har mulighed for det :-)

Var fejlen opstået med det samme, havde det naturligvis været løsningen. Men når der er gået flere dage med normal drift, og der var sket mange ændringer i mellemtiden, ville det tage lang tid at rulle tilbage, og prioriteten var at få de berørte kunder online igen hurtigst muligt. Men ja, havde vi ikke kunnet løse problemet på anden vis, havde vi naturligvis været nødt til at rulle tilbage til en kendt konfiguration, der virkede.

Yoel Caspersen Blogger

Kan næsten ikke forestille mig, hvor presset man er i sådan en situation. Hele ens forretning kan være ødelagt på så få timer, og man aner ikke, hvad der er galt.

Det værste er faktisk den dårlige samvittighed over at nogle af kunderne er offline, når man står i situationen.

Jeg tror, rigtig mange systemadministratorer kender følelsen. Det er mandag morgen, og begge domænecontrollere strejker på grund af en automatiseret Windows-update natten forinden. Medarbejderne i firmaet tripper omkring kaffeautomaten, nogle kommer med dårlige jokes og andre skælder ud - chefen kigger irriteret på uret og spørger, om man snart er færdig, og man ved, at det kan ende rigtig skidt, hvis ikke man finder en løsning snart.

Hvis man mentalt er fuldstændig uberørt af situationen, er man enten den perfekte mand til jobbet eller den helt forkerte ;-)

Jens Jönsson

men en automatiseret besked direkte pr. SMS til de berørte kunder havde hjulpet dem meget

Denne kan jeg kun bifalde. Siden jeg er begyndt at benytte SMS til at oplyse kunderne, så er der meget mere ro på og glade kunder.
(Nu mangler bare at få færdig udviklet systemet, så det er nemt at trykke på knappen og give besked)

Kunder kan generelt godt forstå at der kan opstå fejl. Problemet opstår, når man ikke orienterer dem, så de ikke aner om det er hos dem selv eller hos dig fejlen er.
FB + SMS er en super god kombi til orientering, som tager en gevaldig brod af kundeservice telefon presset.

Christian E. Lysel

Jeg kom for 15 år siden til at slette /etc/ på en Linux maskine, der drev betalings delen for et større dansk website.

Det spændende ved det, var at webserveren kørte ganske fint videre, ingen kunne dog logge på den. En ganske effektiv hardning ... heldigvis havde jeg en SSH forbindelse åben.

Kommandoer som "ls" virkede ikke .... men min bash kørte jo ... så man kunne fx bruge "echo *" som "ls".

Jeg satte mig over i et hjørne med papir og blyant og lagde en trin for trin plan for hvordan jeg fik kopieret /etc til serveren, uden at skulle kører den lange tur.

En time senere havde jeg en plan, der kunne udføres uden noget drift stop.

Af mere skøre ting jeg har oplevet er en switch med et defekt layer 3, hvor IP routning over interfaces en gang i mellem droppede pakker for "udvalte" IP adresser. Da jeg så sammenhængen, var mit største problem at overbevise mine kollega om det i switchen layer3 lag fejlen lå .... Det lykkedes ikke, selvom tcpdump viste pakker forsvandt ... men da de mødte ind om morgenen, virkede alt igen, og alle var glade .... Indtil de spurgte hvor min bærbar var ... "Den agere layer3 i switch miljøet, indtil vi får en ny switch".... Der gik ikke så lang tid, så fik vi en ny switch :)

Snakken omkring hardware og software ... tit overser man hvor meget software der ligger i hardware enheder.

Tag en server, der er koblet på et Direct-attached storage (DAS) ... vi snakker om 5 firmwares mellem server og data.

1) Serverens disk controller.
2) DAS'ets controller.
3) DAS'ets backplane
4) DAS'ets board alle diskene er koblet til.
5) Diskenes firmware.

Jesper Nielsen

Der er lidt "morbidity and mortality" over det :)

Det kunne være fedt, hvis Hiper kom med en lignende redegørelse for deres lange (vist landsdækkende) nedbrud i påsken.

Har I planer om at lancere coax i Københavnsområdet (Valby)?

Yoel Caspersen Blogger

Det kunne være fedt, hvis Hiper kom med en lignende redegørelse for deres lange (vist landsdækkende) nedbrud i påsken.

Ja, det kunne være vældig interessant at vide lidt mere om. Ikke kun af ren nysgerrighed, men fordi branchen som helhed bliver bedre af at lære af hinandens fejl. Jeg begynder så småt at synes bedre og bedre om PHK's ide om en IT-havarikommission.

Har I planer om at lancere coax i Københavnsområdet (Valby)?

Ja, det er på tegnebrættet og meget tyder på, vi snart bliver klar til at udvide til hovedstadsområdet også.

Yoel Caspersen Blogger

Af ren og skær nysgerrighed: Findes der noget á la SBBU på coax?

Til de ikke-indviede: SBBU står for Skift af BredBåndsUdbyder - dvs. det der sker, når ens nye internetudbyder opsiger abonnementet hos den gamle udbyder for en og sikrer, at det nye abonnement kommer op at køre samtidig med at det gamle bliver taget ned.

SBBU er formaliseret som en aftale mellem internetudbyderne i telebranchen, og det administreres i praksis af TDC.

Det findes desværre ikke på coax - men det kan faktisk være en fordel for kunden. Coax-nettets natur gør nemlig, at man kan have flere abonnementer i gang samtidig på samme kabel, og på den måde kan man som kunde vente med at lukke sit gamle abonnement, til det nye er oppe at køre, og på den måde helt undgå nedetid. Man kan også beholde begge udbydere, hvis man af en eller anden grund har brug for dette.

Bente Hansen

Have nogen udstyr stående i en klimatiseret kasse. Men om sommeren gav det fejl, det viste sig at udstyret blev for varmt. Have "isoleret" enhederne, så egen varmen gav en fornuftigt driftstemperatur om vinteren.

Så med til vedligeholdelse af det skab, var der flytning af skumplast en gang årligt.
Da det var nemt at tilgå, og tit fik besøg, så var det nemmere og langt billigere end andre løsninger. Men ikke noget jeg ville sælge til nogen.

PS: TIl alle, pass på med enehder under tag, og ved isolering. Det kan nem bliver meget varmt, når solen står på. Eller hvis et batch vælter ned over noget udstyr.
Her er kælder bedre, men så kan fugt tage liv af stik. Som skal masseres en gang imellem

Christian Nobel

Havde en grim oplevelse forleden med en captive portal som stoppede med at virke.

Alt så umiddelbart fornuftigt ud, begge interfaces kørte som de skulle osv., men opdagede så at dhcp serveren brugte uforholdsmæssig meget hukommelse.

Det viser sig at isc-dhcp serverens leasetabel bare vokser i det uendelige, selv om leasetiden er sat til at være relativt kort.

Hele tabellen som nu var på over 2G bliver så læst ind i memory, og det får simpelthen DHCP serveren til at stoppe med at udlevere adresser - kuren er at flushe leasetabellen og genstarte dhcp serveren.

Umiddelbart har jeg ikke fundet på nogen anden kur end fremover at lade et script gøre det måske en gang om måneden.

Klavs Klavsen

Jeg foretrækker selv at designe mine sql strukturer, så der sikres konsistens - vha. foreignkeys, compound keys, unique etc. - og i de sjældent nødvendige tilfælde en smule kode i databasen - så jeg ikke KAN komme til at smide åbenlyst ugyldige data ind i databasen. Jeg foretrækker at insert'en fejler, istedet for at jeg tilfældigt opdager det senere :)

Klavs Klavsen

Så anbefaler jeg automatisering.. scripts har den fordel at de generelt kun bliver bedre.. hvor vi mennesker bare varierer vores fejl :)

Og så har jeg stor glæde af at anvende mine OS'er eksisterende pakkesystemer (rpm/deb) til at pakke software i, når jeg skal rulle det ud.

Yoel Caspersen Blogger

Jeg ved kun ganske lidt om emnet, men med den nye, offentligt tilgængelige IP-adresse, bliver kunden så ikke mere sårbar, overfor f.eks. portscan udført på mere eller mindre tilfældige IP-blokke ?

I teorien jo, men i praksis nej. Der er indbygget firewall i de routere, vi udleverer til kunderne, og det må forventes, at kunder, der vælger en ren modem-løsning fra os, selv har styr på firewall etc.

Selv om en CGN-adresse ikke kan nås fra internettet, er den jo ikke mere "privat" eller "sikker" end at den kan nås fra alle vores andre CGN-kunders udstyr. I alle sammenhænge, hvor vi anvender CGN-adresser, betragter vi nettet som offentligt, og dermed usikkert, selv om vi ikke kan nå det fra det egentlige internet.

Yoel Caspersen Blogger

Jeg foretrækker selv at designe mine sql strukturer, så der sikres konsistens - vha. foreignkeys, compound keys, unique etc. - og i de sjældent nødvendige tilfælde en smule kode i databasen - så jeg ikke KAN komme til at smide åbenlyst ugyldige data ind i databasen.

Jeg er enig, for så vidt at det stadig er nemt at gennemskue databasens struktur. Hvis man begynder at bruge triggers og stored procedures, begynder databaselaget efter min smag at blive lidt for autonomt og "magisk".

Havde systemet været designet efter et puristisk ideal, havde jeg slet ikke kunnet opdatere vores kunders IP-adresser med SQL-sætninger. Så havde jeg været pisket til at køre et script, som loader de rigtige objekter, kalder de rigtige funktioner, validerer input osv.

Den løsere kobling mellem databaselaget og business-laget er netop det, som gjorde det muligt for mig at kortslutte systemet i en nødsituation og få vores kunder online igen. Det var så også den løsere kobling, kombineret med en smule manglende fantasi og for megen travlhed, da jeg kodede synkroniseringsscriptet, der gjorde at lige præcis den fejl kunne opstå.

Der er altid to sider af mønten :-)

Yoel Caspersen Blogger

Snakken omkring hardware og software ... tit overser man hvor meget software der ligger i hardware enheder.

Tag en server, der er koblet på et Direct-attached storage (DAS) ... vi snakker om 5 firmwares mellem server og data.

Meget relevant pointe. Og hvor tit er det lige, at de 5 stykker software bliver opdateret med fejlrettelser, sammenlignet med resten af systemet? Og ikke desto mindre er hver eneste af disse stykker software en kritisk showstopper, når det går galt.

I øvrigt en sjov historie om din sletning af /etc/. Jeg gætter på, en hjertekirurg har lidt af den samme følelse, når patienten overlever en bypass-operation.

Dennis Andersen

Måske et dumt spørgsmål men har i nogen overvågning af jeres CGN-routere her tænker jeg specifikt på overvågning af trafikmængden.
Har selv siddet i en situation hvor trafik pludselig løb forkert gennem netværket efter en opdatering, hvilket gjorde at en række kunde servere ikke kunne komme på internettet, men fordi vi havde en hyppig polling af SNMP på vores routere samt underliggende infrastruktur kunne der hurtigt ses et voldsomt dyk i trafikmængden mod internettet, hvilket gjorde at vi hurtigt blev alarmeret herom.

Yoel Caspersen Blogger

Måske et dumt spørgsmål men har i nogen overvågning af jeres CGN-routere her tænker jeg specifikt på overvågning af trafikmængden.

Ja, alle porte i netværket monitoreres, og vi følger løbende med i trafikforbruget. Vores monitoreringsværktøj er sat op til at sende alarmer, hvis trafikken overstiger en vis procentdel af båndbredden på den givne port. Det er på min to-do-liste at få indført alarmer over det modsatte, altså bratte fald i trafikken.

Det havde dog næppe hjulpet i lige præcis denne situation, da trafikken fra 400 kunder midt på en formiddag på en hverdag ikke fylder alverden på vores CGN-routere - en CGN-router håndterer trafik for adskillige tusinde kunder.

En mulig forbedring, vi overvejer, er at automatisere en række tests, herunder en speedtest, fra hver enkelt kundes CPE et antal gange i døgnet. Der er dog grænser for, hvor ofte vi kan gennemføre disse tests uden at genere den enkelte kunde.

Michael T. Jensen

En mulig forbedring, vi overvejer, er at automatisere en række tests, herunder en speedtest, fra hver enkelt kundes CPE et antal gange i døgnet. Der er dog grænser for, hvor ofte vi kan gennemføre disse tests uden at genere den enkelte kunde.

Helt så omfattende, at man generer kunden, behøver det jo ikke være. I kan jo lade routeren hente en lille fil hver anden time (eller noget lignende) og time, hvor lang tid det tager. Downloadtiden uploades til en database. På denne måde (med en stor fil) har jeg testet vores netværk på alle AP'er, for at være sikker på deres performance. Går det lidt langsommere om dagen end om natten, er det som det skal være...

Log ind eller opret en konto for at skrive kommentarer