Så arbetar NOC

av Jörgen Städje den 13 Nov 2017

SUNET och NORDUnet skulle inte hålla länge om inte nätdriftcentralen NUNOC på Tulegatan ständigt var på alerten och snokade överallt, noterade alla fel och skickade ut reparatörer som fixade trasiga routrar, transceivrar och fibrer. De utför ett heroiskt arbete dygnet runt, året runt så att alla alltid kan nå sina tjänster.

Nordic University Network Operations Centre (NUNOC) är en ovanligt tyst inrättning. Ett rum på Tulegatan fullt med bildskärmar och allvarliga människor som tittar koncentrerat på dem. Det är ungefär som en flygledningscentral. Datorerna håller koll på flygplanen, beräknar alla inbördes avstånd och kontrollerar att alla flygregler följs. Ingen säger något, eller pratar åtminstone bara lågmält.

Verkligheten är en absolut kontrast mot hur Hollywood vill att vi ska se flygledning, eller datordrift, som i scenen ur filmen Airport ovan. Inga vilda, arga chefer som springer omkring och skäller, med klasar av security clearance-brickor dinglande från bröstet, inga tekniker som spiller kaffe i tangentborden och välter omkull högar med radskrivarpapper, inga datorer som sprutar gnistor när de är överbelastade.

Visserligen märker man på det hårda sättet när en server eller någonting i nätverket inte fungerar, men det vore ännu bättre att få veta exakt var och när ett problem är på väg att uppstå.

Jonas Hagström är lugnet själv. Han ser allt, hör allt och tar beslut om vilka felindikeringar man kan strunta i och vilka som ska eskaleras till serviceorganisationen, och i förekommande fall, vilken serviceorganisation. Utifrån inkommande larm från utrustningen avgör han och hans kolleger vilken typ av utrustning som är trasig, och rapporterar detta på överenskommet sätt till den övriga organisationen, samt till allmänheten som tittar på NUNOCs webbsida.

Allt som händer, eller planeras hända i nätets olika delar, blir till ärenden (Trouble Tickets). NOC har inga hemligheter utan rapporterar det mesta offentligt så att alla som är beroende av SunetC och NORDUnet har full insikt i nätets driftläge.

Det finns både planerade (scheduled) och oplanerade (unscheduled) händelser. Bland de planerade räknas till exempel omstarter av servrar efter uppgradering av operativsystem och bland de oplanerade räknas sådant som avgrävda fibrer och trasiga interface i routrar.

Här har vi ett exempel på en oförutsedd sådan.

Det var illa. SunetC har tappat kontakten med routern i Narvik. Det måste fixas. Vi ska se hur fel rapporteras in och hur de klassificeras och åtgärdas.

NOC driftorganisation

NUNOC har ansvar för driften av alla delar av nätet, tjänsterna och nåbarhet till vissa av de virtuella maskinerna i molntjänsten. Ansvaret för själva SunetC tar slut vid avlämningspunkten på lärosätet, medan ansvaret för NORDUnet omfattar både NORDUnets utrustning (routrar) i världen och avlämningspunkterna i de fem nordiska länderna. När ett ärende (Trouble Ticket) skapats av en tekniker i systemet, vidtar felsökningen. Mer om detta nedan.

Systemet är uppbyggt med routrar överallt. Så fort en påverkan uppstår, ett fiberbrott, en trasig utrustningsdel osv, kommer ett larm från en router. Advas optiska utrustning har sitt eget larmsystem, även om ett fel i en Adva-apparat sannolikt också orsakar ett larm från närmsta router.

Andra vägar för larm är telefon och e-post, om en människa upptäckt ett fel som systemet inte upptäckt. Slutligen finns en lista med planerade avbrott, såsom olika typer av systemunderhåll som ska utföras på förutbestämda tider, eller servrar som fått en uppdatering av något slag och måste startas om. Då försöker man genomföra omstarterna när de stör så lite som möjligt, till exempel på nätter eller helger. I fallet med programuppdatering är det uppdaterade systemet som själv anmäler att det behöver startas om. Även om detta inte är ett driftfel, så kommer det med i ärendehanteringssystemet som planerat underhåll, så alla ska veta vad som är på gång.

Tittar man på trafikstatistiken för Adobe Connect (http://stats.sunet.se/) ser man att det handlar om i medeltal cirka 600 studenter som använder distansundervisning varje dag. Den tjänsten får inte sluta fungera.

En annan viktig tjänst är e-postfiltret som sorterar bort en hel massa skräppost varje dag. Skulle det sluta fungera, skulle väldigt många anställda inte få sin e-post, eftersom breven måste passera filtret först, innan de går vidare till mottagaren. Statistikdiagrammet ovan visar fyra dagars drift, där bara de gröna staplarna representerar giltig e-post. Resten är olika former av skräp.

Allt driftdata samlas in via ett protokoll kallat SNMP: Simple Network Management Protocol, som är en standard för övervakning av nätverk och servrar. De flesta servrar, routrar, skrivare och arbetsstationer stödjer protokollet. Sådana enheter har en inbyggd SNMP-agent som kan ge upplysningar om enhetens tillstånd och konfiguration till en SNMP-manager, som finns i det program som vill använda informationen.

Larmnivåer

NOC har tre larmnivåer, från Minor till Critical.

Minor är ett mindre fel utan driftpåverkan, som att en viss funktion i en router inte går som avsett, som till exempel ett felaktigt logg-meddelande, men det kan även vara ett konstaterat falsklarm.

Major inträffar om ett system förlorar redundans någonstans. Det påverkar inte kunden, men det är fortfarande ett fel som måste åtgärdas. 99,9 % av alla allvarliga fel är av typen Major, vilket visar att nätverkskonstruktörerna tänkt rätt.

Critical inträffar om ett lärosäte förlorar båda de redundanta förbindelserna till SunetC, eller om en av stamnätsnoderna (POP, Point of Presence) från stamnätet förloras. Det gäller även om någon av Sunets tjänster har en allvarligare störning. Den skiftansvarige matar in detta som en Critical i ärendehanteringssystemet och då larmas även driftchefen Jonny Lundin automatiskt med ett SMS. Han beslutar om man bör sätta upp en telefonkonferens med teknisk personal och säkerställer att relevanta aktörer jobbar aktivt med en lösning.

Att föra ut information snabbt utgör en stor del av själva felhanteringen, särskilt när det innebär stor kundpåverkan. Kunderna vill gärna ha information så fort som möjligt, för att snabbt veta om hur felsökningen fortlöper och när det kan väntas vara löst. Det kan lätt bli mycket ringande om det inte finns aktuell information att tillgå så det är av största vikt att informationen kommer ut fort.

De olika larmsystemen

Det finns alltså tre olika klasser av utrustning, Advas optiska växlar, ROADM och liknande, Junipers routrar och Sunets egna servrar. Dessa tre larmar till varsitt speciellt anpassat larmsystem. Här ska vi titta på dem i detalj.

Adva FSP Network Manager

Adva-utrustningens larm visas i en larmlista som denna. Du ser beskrivningen ute till höger, till exempel ”Loss of signal” (fibern blev svart). Då har antingen en laser gått sönder i andra änden av den fiber som kommer in på denna port eller också har en optisk förstärkare gått sönder på vägen.

Vid ett larm kontrollerar man även i nätverkskartan som visas i Adva NMS var de trasiga noderna är belägna. Det är i detta skede man kan råka få klart för sig om det är en fiberförbindelse mellan två intilliggande noder som är orsaken till larmet, om de båda rapporterar till exempel ”loss of signal”. Då kan det vara en grävmaskin som varit framme.

Slutligen kan man undersöka varje enskild utrustning i detalj. Här har vi valt en ROADM med beteckningen KLX1 som är en apparat som står i Kalix och är hopkopplad med utrustningarna i Luleå respektive Haparanda. Den är en av två i samma nod. Chassit kallas FSP 3000 och innehåller två optiska moduler, nämligen en EDFA (optisk förstärkare, den blå till vänster) och en ROADM (optisk växel, den blå till höger). Mera om detta hittar du i artikeln om ROADM (https://www.sunet.se/blogg/we-have-liftoff-del-2-av-2/). Just nu är det ingenting som är trasigt så det finns inga röda varningsmärken.

Nagios

Alla tjänster och servrar rapporterar till larmsystemet Nagios. Nagios betyder ”Nagios Ain’t Gonna Insist On Sainthood”, ett rekursivt skämt.

Alla servrar i SUNETs datorhallar och de servrar som hanterar sunettjänster, övervakas med Nagios. Servrarna i IaaS som utgör molnsystemet hanteras och övervakas av Safespring. NOC ansvarar bara för att instanserna av virtuella maskiner som körs på dessa molnservrar, lever och mår bra. En enda Nagios-instans avfrågar ständigt de virtuella maskinerna och skulle svaret ta för lång tid rapporteras instabilitetsproblem till huvudinstansen av Nagios som NOC-operatörerna ser. Då kan det vara lämpligt med ett samtal till Safesprings operatörer.

ZINO med RITZ

Routrarna rapporterar in till larmsystemet Zino (”Zino is not Openview”, ytterligare ett rekursivt skämt, om Openview, en konkurrent). NOCens version av Zino är specialanpassat för hantering av Juniperroutrar.

Zino undersöker ständigt driftläget för routrarnas alla optiska gränssnitt, trafikflödet genom alla gränssnitt, om signalvägarna mellan anslutna routrar fungerar och om routrarna skickar andra typer av driftlarm.

Zino är det centrala systemet, medan Ritz (Remote Interface To Zino), vars skärmbild visas ovan, är själva rapportklienten som används av personalen.

Av den insamlade informationen kan Zino också bygga belastningskartan.

Belastningskartan

Statistikinsamlingsprogrammet ”Stats” går ständigt, i både hallen i Fredhäll och på Tulegatan, som samlar in trafikstatistik från alla routrar i nätet. Programmet bygger tabeller med belastningsdata och av dem gör det diagram över trafiken på alla nätets delar över tid, och en karta som presenterar alla länkars belastning i nuläget. Det är utmärkta verktyg för felsökning. Trafikstatistiken finns med olika upplösning, både på dags-, vecko- och månadsbasis och över flera år.

Vad man enkelt kan se i diagrammet över de senaste två årens trafik mellan NORDUnet och Sunet är att volymerna pekar uppåt, uppåt och uppåt. Volymerna har nära nog fördubblats på två år, exakt som förväntat. Någonstans mitt i det här diagrammet startades SunetC och kapaciteten ökade från 40 Gbps till 100 Gbps för alla. Det kanske syns?

SUNET är på inget sätt ensamt om att använda denna metod för att rita belastningskartor eller trafikstatistik. I stort sett alla nätdriftorganisationer världen över använder samma programvara och metoder. Det är oerhört viktigt att vara proaktiv och studera trender, innan de stora trafikstockningarna uppstår. Det är också bättre att undersöka felförekomster under flera dagar eller månader och försöka uppskatta när en del av utrustningen går sönder, snarare än att vänta på katastrofen. På samma sätt kan NUNOC hjälpa de anslutna kunderna med att påpeka tänkbara framtida fel.

Trouble Tickets – ärenden

Den operatör som har ansvaret för ärendehanteringen och ser ett larm, funderar på om det är ett giltigt larm eller ett falsklarm och hur allvarligt det är. Efter att han tagit reda på vilken enhet det är som är trasig, och huruvida felet ska visas offentligt eller bara internt, formulerar han ett ärende, en Trouble Ticket och matar in i ärendehanteringssystemet. Systemet har två ansikten, dels det som visas internt på NOC och dels den del som visas offentligt på Internet.

Vem som helst kan läsa de offentliga ärendena i systemet på http://www.nunoc.org/nunocweb/open_trouble_tickets.html

Klickar man på ett ärende visas alla dess detaljer.

Överst ser du ärendets ordningstal, som är lätt att komma ihåg. Typen visar att det rör sig om schemalagt underhåll som förhoppnignsvis inte ska betyda något för någon ansluten. Status ”Open” anger att ärendet inte är klart ännu, och det är uppenbart när man ser att ärendet startades 1 november, men arbetet ska inte ska påbörjas förrän 20 november och avser fiberunderhåll mellan Malmö och Tomelilla. Om allt gick bra ändras ärendestatus till ”Closed” efteråt.

Larm – flödesschema

Ett larm kommer in. Nu är det illa. Bildskärmarna tappar synken och datorerna brinner.

Operatören börjar med att avgöra om felet är av sådan art att det ska visas enbart internt eller kan visas externt, och försöker isolera vilken enhet som är trasig genom att använda sig av de olika larmsystemen och fyller i de viktigaste uppgifterna i ärendehanteringssystemet. Är felet av allvarlig art larmar systemet själv den ansvarige, som får börja med att informera alla de drabbade, starta telefonkonferenser osv. Är felet av mindre allvarlig art, så att kunderna inte märker något, är det bara att gå vidare till nästa steg.

Trasig maskinvara

Är det maskinvara som är trasig eskaleras ärendet till den serviceorganisation som har kontrakterats för respektive typ av utrustning, servrar, routrar eller optisk utrustning. Om nödvändigt lämnar operatören över loggar med registrerade felmeddelanden till serviceorganisationen och väntar på återkoppling från denna. Underhållsorganisationen ska återkomma med en analys inom en fastställd tid och sedan meddela hur lång tid avhjälpningen tar. Detta matas in i ärendehanteringssystemet.

Därefter får serviceorganisationen vidta de åtgärder som behövs för att avhjälpa felet inom överenskommen tid, alltså skicka ut reparatörer, försedda med lämpliga reservdelar och så vidare. Efter avhjälpning meddelar serviceorganisationen att detta utförts.

Skulle det till exempel vara ett interface som bytts ut, eller måhända en hel router, måste den förses med ny programvara. Det initieras av NOC och man inväntar resultatet. Efter detta undersöks om utrustningen faktiskt är helt återställd och fungerar som den ska. Skulle så vara fallet ändrar operatören Ticket Status från ”Open” till ”Closed”.

Men det räcker inte. Felet skulle kunna återkomma, utrustningen skulle kunna fungera otillförlitligt eller liknande. Därför sätts den under särskild övervakning i allt från ett dygn till en vecka beroende på typ av utrustning.

Avgrävd fiber

Ungefär samma rutin används om man kunnat konstatera att en fiber är skadad. ”Skadad” behöver inte betyda att den blivit avknipsad. Det skulle lika gärna kunna vara att en fiberkontakt blivit nedsmutsad vid en serviceåtgärd som gällde något helt annat, eller att en tekniker varit i fiber-stugan och råkat klämma en fiber i en dörr eller liknande, så att förlusterna av ljus blivit för stora.

Oavsett orsak tar operatören reda på fiberns ID-nummer hos Tele2 som är underleverantör av fibernätet och felanmäler denna.

Efter avslut mäter NOC upp fiberns transmissionsparametrar för att se att de ligger inom specifikationerna, och om så är fallet ändrar operatören Ticket Status från ”Open” till ”Closed”.

Men man kan inte lita på att felet är helt borta utan även i fallet fiberfel håller man ögonen på denna fibersträckning i upp till en vecka efteråt.

Avslutning

När allt är över står inga polisbilar krockade, datorer står inte och ryker och vansinniga chefer får inte blodstörtning på sitt kontor och måste ta piller.

Alltihop slutar med en enkel rad på NUNOCs webbplats med det förtroendeingivande ordet ”Resolved”.

Så var det över för den här gången. I just detta fall hade länken mellan Jönköping och Växjö slutat fungera. En fiber hade fått sådana klämskador att reflektionen blivit för hög och ramanförstärkaren hade slutat fungera. Den lokala operatören hade haft något för sig och skadat fibern. Det fixades och sedan fungerade allt normalt igen. Trots att felavhjälpningen tog två dygn märkte användarna aldrig något, tack vare den utmärkta redundansen.

Läs mer

Lite om NOC: http://www.nunoc.org/nunocweb/-_operations.html

Om det värsta händer kan NOC flytta till annan driftplats: https://www.sunet.se/blogg/redundans-ar-allt/

Mer om Nagios: https://en.wikipedia.org/wiki/Nagios

Mer om Adva FSP Network Manager: http://www.advaoptical.com/en/products/automated-network-management/fsp-network-manager.aspx

Zino är skriven av norska universitetsnätverket Uninett: https://www.youtube.com/watch?v=TzzqP6lYc2g

Mysteriet med den kraschande routern: https://www.sunet.se/blogg/teknisk-djupdykning-den-mystiska-routerkraschen/

Fler blogginlägg av Jörgen Städje

SUNET i Hongkong

20 Sep 2017
/ Bloggen fiberfeber

SUNETs handbok i informations- och IT-säkerhet

1 Sep 2017
/ Bloggen fiberfeber

Den ökända hästen från Troja

31 Jul 2017
/ Bloggen fiberfeber

Redundans är allt

3 Jul 2017
/ Bloggen fiberfeber

SNIC-snack

2 Jun 2017
/ Bloggen fiberfeber

We have liftoff: del 5 av 2

3 Maj 2017
/ Bloggen fiberfeber

Maria Häll: We are at the Forefront!

13 Apr 2017
/ Bloggen fiberfeber

Maria Häll: Vi ligger i framkant!

10 Apr 2017
/ Bloggen fiberfeber

We have liftoff, del 4 av 2

22 Feb 2017
/ Bloggen fiberfeber

We have liftoff, del 3 av 2

30 Jan 2017
/ Bloggen fiberfeber

We have liftoff! Del 2 av 2

9 Jan 2017
/ Bloggen fiberfeber

We have liftoff! Del 1 av 2

16 Dec 2016
/ Bloggen fiberfeber

Long Read – Cleanliness is a Virtue

20 Sep 2016
/ Bloggen fiberfeber

Långläsning - tvättar bäst som tvättar först

16 Sep 2016
/ Bloggen fiberfeber

Följa fiber – från Tulegatan till Stockholms universitet.

26 Aug 2016
/ Bloggen fiberfeber

Ericsson, then swänske Lars Magnus

7 Jun 2016
/ Bloggen fiberfeber

One ring to rule them all

24 Maj 2016
/ Bloggen fiberfeber

Den tunga bakgrundstrafiken

12 Maj 2016
/ Bloggen fiberfeber

Long read: How to Design a Fibre Optic Network

5 Maj 2016
/ Bloggen fiberfeber

Welcome to the Fiber Fever Blog!

3 Maj 2016
/ Bloggen fiberfeber

Procuring an Optical Network – Smooth as Silk

2 Maj 2016
/ Blogg

The Breadth and Width of a Megabit

29 Apr 2016
/ Blogg

The Nobel Prized Piece of Glass

28 Apr 2016
/ Blogg

What’s the time? Really?

28 Apr 2016
/ Blogg

SUNET in i molnet (3) – molnsäkerhet

26 Apr 2016
/ Blogg

SUNET in i molnet (2) – vad är molnet egentligen?

25 Apr 2016
/ Blogg

SUNET in i molnet (1) – det här får du

25 Apr 2016
/ Blogg

Read about the brand new Sunet network.

11 Apr 2016
/ Bloggen fiberfeber

GÉANT och NORDUnet – bästa kompisar

14 Mar 2016
/ Bloggen fiberfeber

Ljuset kommer från Tyskland

3 Mar 2016
/ Bloggen fiberfeber

Thunderbirds are GO!

19 Feb 2016
/ Bloggen fiberfeber

Ett panorama av verkligheten

17 Feb 2016
/ Bloggen fiberfeber

Det allseende ögat

15 Feb 2016
/ Bloggen fiberfeber

Förstärkning på längden

15 Jan 2016
/ Bloggen fiberfeber

Dämpning och förstärkning i optisk fiber

14 Jan 2016
/ Bloggen fiberfeber

Grundläggande om L-bandet

14 Jan 2016
/ Bloggen fiberfeber

C-bandet – grundläggande om

14 Jan 2016
/ Bloggen fiberfeber

Logaritmer, min käre Watson

14 Jan 2016
/ Bloggen fiberfeber

CERN – krossen som slår sönder materiens minsta byggstenar

12 Jan 2016
/ Bloggen fiberfeber

Riksarkivets samarbete med SUNET

11 Jan 2016
/ Bloggen fiberfeber

One Ring to Rule them - Vetenskapsrådet

21 Dec 2015
/ Bloggen fiberfeber

Alla jättars jätte - Cisco

19 Dec 2015
/ Bloggen fiberfeber

En värld av siffror - belastning

19 Dec 2015
/ Bloggen fiberfeber

Ur led är inte alls tiden - atomur

19 Dec 2015
/ Bloggen fiberfeber

En djungel av kontaktdon

4 Dec 2015
/ Bloggen fiberfeber

Elektronisk enbärsdricka - Juniper

27 Nov 2015
/ Bloggen fiberfeber

Vad är Géant?

26 Nov 2015
/ Bloggen fiberfeber

Radar Love - Eiscat

25 Nov 2015
/ Bloggen fiberfeber

The Color Purple - dispersion

25 Nov 2015
/ Bloggen fiberfeber

Full Metal Packet - switchen

10 Nov 2015
/ Bloggen fiberfeber

Get your kicks on route 66 - routrar

10 Nov 2015
/ Bloggen fiberfeber

Game of Stones - kvarts

10 Nov 2015
/ Bloggen fiberfeber

The Twilight Zone - fotonen

10 Nov 2015
/ Bloggen fiberfeber

Peering – SUNETs ekonomiska ryggrad

9 Nov 2015
/ Bloggen fiberfeber

I mörkret är alla katter infraröda

4 Nov 2015
/ Bloggen fiberfeber

Fibertyperna i nätet och deras optiska felaktigheter

29 Okt 2015
/ Bloggen fiberfeber

Vad är klockan? Egentligen?

21 Okt 2015
/ Bloggen fiberfeber

Nätets centrum

20 Okt 2015
/ Bloggen fiberfeber

Den optiska transceivern

17 Okt 2015
/ Bloggen fiberfeber

Polarisation och informationsöverföring

1 Okt 2015
/ Bloggen fiberfeber

Laserns historia

30 Sep 2015
/ Bloggen fiberfeber

Koherent ljus, vad är det?

28 Sep 2015
/ Bloggen fiberfeber

När allt är klart

28 Sep 2015
/ Bloggen fiberfeber

SUNET – nu ännu bättre!

16 Sep 2015
/ Bloggen fiberfeber

Fibern fruktar fukten

11 Sep 2015
/ Bloggen fiberfeber

Att få kontakt

11 Sep 2015
/ Bloggen fiberfeber

Så tillverkas optisk fiber

31 Aug 2015
/ Bloggen fiberfeber

EMC – EMI – EMP

31 Aug 2015
/ Bloggen fiberfeber

Glasbiten som gav nobelpris

21 Aug 2015
/ Bloggen fiberfeber

Megabit på längden och tvären

21 Aug 2015
/ Bloggen fiberfeber

Långartikel: Fibern från Frostmofjället

21 Aug 2015
/ Bloggen fiberfeber

Upphandling av optiskt nät

25 Jul 2015
/ Bloggen fiberfeber

OptaSense – när fiber blir sensorer

3 Jul 2015
/ Bloggen fiberfeber

Teknisk djupdykning: Optisk magi med ramanförstärkare

2 Jul 2015
/ Bloggen fiberfeber

Teknisk utvikning: 130.000 fibrer som i en liten ask

1 Jul 2015
/ Bloggen fiberfeber

NOCen spekulerar 2: Felrapporter

27 Jun 2015
/ Bloggen fiberfeber

NOCen spekulerar 1: hög belastning

26 Jun 2015
/ Bloggen fiberfeber

Teknisk djupdykning: Optisk magi med EDFA

22 Jun 2015
/ Bloggen fiberfeber

Långartikel: Så designar man ett fiberoptiskt nät

11 Jun 2015
/ Bloggen fiberfeber

Bredare motorväg för svenska data – äntligen en offensiv satsning!

22 Maj 2015
/ Bloggen fiberfeber

Om den interaktiva tidslinjen

21 Maj 2015
/ Bloggen fiberfeber

Om den interaktiva kartan

20 Maj 2015
/ Bloggen fiberfeber

Fiberfeber: Vad som har varit och vad som komma skall

19 Maj 2015
/ Bloggen fiberfeber

Följ bygget av Sunets nät på bloggen Fiberfeber!

18 Maj 2015
/ Bloggen fiberfeber

Teknisk djupdykning: den mystiska routerkraschen

11 Jun 2006
/ Bloggen fiberfeber

2000–2013: Sunet mognar och kapaciteten ökar. Identitetsfederation skapas.

1 Jan 2000
/ Bloggen fiberfeber

1990–1999: Kapaciteten stiger, 2 – 34 – 155 Mbps

1 Jan 1990
/ Bloggen fiberfeber

1968–1989: Idéernas tidevarv. Internets vagga.

1 Jan 1968
/ Bloggen fiberfeber

Jörgen Städje

Jag heter Jörgen Städje och har skrivit om teknik och vetenskap sedan 1984. Friskt kopplat, hälften brunnet!