Nätverkslösning för Nordsken 2016 EXAMENSARBETE

(1)

Nätverkslösning för Nordsken 2016

Filip Blylod Markus Granberg

Karl Sadinmaa 2016

Högskoleexamen Datornätverk

Luleå tekniska universitet

(2)

EXAMENSARBETE D0032D

LTU CAMPUS SKELLEFTEÅ

INSTITUTIONEN FÖR SYSTEM & RYMDTEKNIK

Markus Granberg Filip Blylod Karl Sadinmaa

2016

(3)

och vägledande under arbetet som varit.

(4)

sagt, allt som har med så kallade "nördkultur". Den är öppen för både deltagare som spelar olika brädspel, rollspel och går på föreläsningar men även för LANdeltagare.

Vi fick i uppdrag att planera och upprätta av en nätverkslösning för hela evenemanget. Både för nätverk och allt som omger det, men också ett trådlöst nätverk som täcker hela området av evenemanget. Själva evenemanget äger rum i Scandic Skellefteås lokaler och omfattar 3 våningar. Under evenemanget tillhandahöll vi underhåll av nätet och agerade support för de som kunde komma tänkas att behöva det.

Under månaderna före evenemanget planerades nätverket och en bild av de tjänster som skulle komma att behövas för att underlätta driften. Totalt användes 31 switchar och 17 accesspunkter. Vi hade även 2 servrar varav en delades in i flera virtualiserade maskiner för att tillhandahålla de tjänster och verktyg som behövs för att underhålla och hantera

nätverket.

För att sammanfatta gick upprättande och drift av nätverket relativt bra. Några små problem stöttes på under tiden men inget som inte kunde åtgärdas inom en rimlig tid.

Det trådlösa nätverket fungerade dock dåligt. Vi hade problem att få det tillräckligt snabbt och roamingfunktionen fungerade inte som önskat under hela evenemanget. Under evenemangets första dag var detta ett stort problem men vi lyckades förbättra det något under de senare dagarna. I rapporten finns en del tankar kring lösningar som skulle kunna implementeras för att förbättra funktionen på det trådlösa nätet.

(5)

tournaments in different tabletop games and also LAN computer gaming.

We were tasked with planning and establishing a network solution for the entire event. Both for the LAN and everything surrounding it, but also a wireless network covering the entire area of the event. The event itself takes place in Scandic Hotel Skellefteå’s locales and covers 3 floors. During the event we ran maintenance of the network and support for any of the participants who might need it.

The months beforehand were spent planning and structuring the network and the services needed. A grand total of 31 switches and 17 accesspoints were used. 2 servers which of one ran several virtualized machines were also established to provide the services and tools needed to maintain and manage the network.

In conclusion the running of the network services during the event went smoothly. We had a few minor issues concerning missing cables and connections for a couple of the participants.

However none of these issues couldn’t be solved in a timely manner.

The wireless network however did not work as expected and we had problems getting an acceptable speed and roaming function throughout the event. The first day the wireless network faced major issues due to the automatic power and channel configurations of the accesspoints. We have included several conclusions as to why the wifi did not work as expected and also a couple of solutions which may be implemented to improve the quality of the wireless network.

(6)

1. Inledning ………1

2. Teori ………...2

2.1 Mjukvara ………... 2

2.1.1 Tacacs+ ... 2

2.1.2 Opennms ……… 2

2.1.3 MRTG ………..2

2.1.4 ESXI ……… 2

2.1.5 ISCDHCPServer ………. 2

2.1.6 pfSense ……….. 2

2.1.7 Ubiquiti Unifi Controller ……….3

2.1.8 TFTP ………3

2.1.9 VLAN ………...3

2.2 Nätverk ………..4

2.2.1 CORE ………..5

2.2.2 Unifi AP ………...5

2.2.3 UbiquitiEdgeswitch(PoE) ……… 6

2.2.4 Distributionslager ……….. 6

2.2.5 Accesslager ………6

2.2.6 Switch för Esport Crew ………7

2.2.7 Switch för Utställare och LTU ………..7

2.2.8 Switch för WLAN på övre konferensplan ……….. 8

2.2.9 Switch för Nätverkscrew och WLAN samt utställare ………... 8

3. Metod och planering…...………. 9

3.1 Metod ………...………. 9

3.2 Arbete inför Nordsken ……….9

3.2.1 Planering ………..9

3.2.2 Konfiguration ……….. 10

3.2.3 Test ……….. 10

3.3 Arbete under Nordsken ……….. 11

3.3.1 Montage ……….. 11

3.3.2 Underhåll ………. 11

3.3.3 Support ……… 11

3.4 Arbete efter Nordsken ……….11

3.4.1 Demontering ………... 11

4. Trådlöst Nätverk ……….. 12

5. Servrar ……….. 13

6.1 Server 1 ……… 13

(7)

5.1.2 MRTG ……….. 13

5.1.3 OpenNMS ………13

5.1.4 TACACS+ ... 14

5.1.5 ISCDHCPServer ………..14

5.1.6 Owncloud ……….... 14

5.1.7 WLC ………. 14

5.2 Server 2 ……….... 15

5.2.1 pfSense ………15

6. Resultat ………. 16

6.1 Inför ………16

6.2 Under ……….16

6.3 Efter ………...17

6.3 Trådlöst ………. 17

6.4 Servrar ……….. 17

7. Diskussion ……… 18

7.1 Trådlöst nätverk ………...18

7.2 MRTG ………20

7.3 DNS ………...20

7.4 Nätverk och adressering ………....20

7.5 Slutsats ………. 21

Källförteckning ………..22

Bilagor ………23

(8)

1. Inledning

Nordsken är ett evenemang för serie, spel, teknik, och filmintresserade. Det är en årlig

företeelse som lockar en stor mängd besökare inte bara för LANspelande men även allt ifrån att se konstutställningar till att se film eller pröva den senaste tekniken.

I år hade evenemanget över 500 deltagare i LANdelen och sammanlagt över 9000 besökare. Ett flertal utställare var också på plats för att visa upp och marknadsföra sina produkter. Utställarna kommer ifrån många olika delar av “nördkulturen” med exempelvis skådespelare, serietecknare, cosplayers, spelutvecklare, med mera.

Under helgen så skall inte bara LANdeltagarna ha tillgång till ett nätverk och internet men det skall också finnas en Wifilösning för hela evenemanget. Inte bara för utställare och de som arbetar med evenemanget men också för besökare. Då evenemanget för första gången nu är på ett flertal våningsplan och en betydligt större yta än det har varit tidigare år så är detta en uppgift som krävt en hel del planering och omtanke.

Rapporten beskriver hur vi har gått till väga med planering, konfiguration och installation samt underhåll av hela nätverkslösningen för Nordsken 2016. Rapporten innefattar även problem med att implementera trådlösa nätverk i täta miljöer där befintliga etablerade WiFinät konkurrerar om kanalspekrumet.

Syftet med rapporten är att dokumentera den mjuk och hårdvara som använts för att åstadkomma en godtycklig nätverkslösning för ett större evenemang med både trådlöst och trådburet nätverk.

Rapporten tar även upp en del problem som uppstod med det trådlösa nätverket och tankar kring vad som skulle kunna orsaka detta samt förslag till åtgärder för att öka prestandan i framtiden.

De förkortningar och begrepp som används i rapporten kan ses under Bilaga 1.

(9)

2. Teori

I detta avsnitt berskrivs teorin bakom implementationen samt vilken mjukvara som används och dess funktion. Dessa valdes ut för att fylla de kriterier som Nordsken ställde samt att underlätta drift och öka säkerheten av nätverket. Valen grundades i tidigare erfarenhet samt rekommendation av handledare.

2.1 Mjukvara

2.1.1 Tacacs+

Är ett protokoll för AAA som är utvecklat av Cisco. Tacacs+ tillhandahåller en högre standard av säkerhet för att kunna ansluta till nätverksenheter som routrar, switchar, och brandväggar.

Användes för att begränsa tillgången till nätverksenheter och på så sätt öka säkerheten på nätverket.

2.1.2 Opennms

Är en mjukvara som tillhandahåller funktioner för nätverksövervakning via SNMP och traps.

Användes för att ge tillgång till enheters status under drift från en central övervakningsenhet.

2.1.3 MRTG

Multi router traffic grapher, tillhandahåller realtidsgrafer över nätverksinterface och deras bandbreddsförbrukning. Användes för att få tillgång till en överblick av hur mycket trafik som gått igenom nätverket efter att eventet var över.

2.1.4 ESXI

Är en typ ett hypervisor som används för att skapa flera virtuella servrar på en fysisk server. Användes för att kunna installera ett flertal servrar på 2 fysiska servrar.

2.1.5 ISCDHCPServer

Är en open source DHCPserver för Unixbaserade operativsystem, en DHCPserver tilldelar dynamiska IPadresser till klienter.

(10)

2.1.6 pfSense

PfSense är ett open source brandvägg/routeroperativsystem som är baserat på FreeBSD.

Detta användes för att få möljigheten att köra det öppna trådlösa nätverket på ett eget publikt nätverk.

2.1.7 Ubinquiti Unifi Controller

Är en mjukvarubaserad wireless controller för konfiguration och statistik av Ubiquitis accesspunkter. Är tillgängligt för operativsystemen Windows, Linux och Mac.

2.1.8 TFTP

Är en enklare version av filöverförningsprotokollet File Transfer Protocol (FTP). Användes för att spara konfiguration från nätverksenheter på en server.

2.1.9 VLAN

LANdelen av nätet delades in i ett flertal VLAN för att öka säkerheten och främst för att förminska broadcastdomänernas storlek över nätverket. Det skapades även ett

Management VLAN för att kunna ge tillgång till samtliga enheter på nätverket för att kunna hitta eventuella fel under evenemangets gång.

(11)

2.2 Nätverk

T3 tillhandahöll en adressrymd i form av en CIDR /22 adress. Detta innebär att sammanlagt 1022 klienter kan ha tillgång till nätverket samtidigt. Nätverket delades upp i core, distribution, och accesslager.

Utrustningen som användes var ett antal switchar och accesspunkter. Den mesta utrustningen var antingen ägd av Nordsken eller hyrd från playstar av Nordsken. 16 stycken switchar lånades utav LTU Campus Skellefteå.

Nätverksutrustningen såg ut enligt följande:

SG500X 1 St

Ubiquiti Edge Switch 24 PoE 1 St

Cisco Catalyst 2960 26 St

Cisco Catalyst 2960G 2 St

Cisco Catalyst 3560G 1 St

Unifi AP 12 12 St

Unifi APACPRO 14 St

För att begränsa storleken på broadcastdomänerna samt öka säkerheten för utställare och utrustning under evenemanget så delades adressrymden upp i ett flertal mindre VLAN med egen adressrymd.

Det trådlösa nätet skulle användas främst för kommunikation mellan de som arbetade under evenemanget men även för de utställare som behövde tillgång till nätverk för kortläsare, datorer, och dylikt. Men det skulle även finnas ett öppet WLAN tillgängligt för samtliga besökare under evenemanget.

Då LANdeltagarna som skulle vara på plats beräknades vara ca 550 personer samt att arbetande och utställare tog upp en hel del adresser så beslutades det att göra ett trådlöst nät på 256

adresser för utställare och arbetande medans det öppna fick bestå av ett privat nät på 1024 adresser. Detta översattes via PAT till en av de publika adresserna. De VLAN och samtliga subnät som användes kan avläsas under bilaga 2.

(12)

2.2.1 CORE

En switch av modellen SG500X från Cisco användes som coreswitch, det vill säga länken mellan det LAN vi satt upp och T3 som levererade vår adressrymd.

Denna placerades i ett installationsutrymme som kan ses under bilaga 4. Detta för att få en relativt bra distans till annan hårdvara då kablage var i åtanke. Samt för möjlighet att patcha till andra våningar fanns i detta rum.

Som det kan avläsas på bilaga 4 så är ett antal switchar samt servrar kopplade mot coreswitchen. Dessa portar är konfigurerade som trunkportar då flera vlan ska kunna färdas över dessa portar. Porten mot T3 sätts som en lager 3 port med utsatt IPadress och en defaultgateway mot denna. En accesslista sattes så att SSH bara kunde ske från management vlanet samt att inloggning skulle ske via Tacacs+.

Switchen har en inbyggt GUI som är webbaserat, detta stängdes av efter konfigurationen var klar av säkerhetsskäl. För mer ingånde konfiguration se bilaga 7.

2.2.2 Unifi AP

Nordsken köpte in 12 stycken Unifi APAC pro utöver dem befintliga Unifi AP. Placeringen av dessa kan avläsas under bilaga 5. Dessa konfigurerades med Unifis mjukvarubaserade WLC. Dessa skulle innehålla två stycken SSID då ett skulle vara öppet för besökare och ett slutet för crew. Dessa SSID placerades på två stycken olika VLAN för att kunna skilja och kontrollera trafiken. VLAN 65 för det öppna samt VLAN 70 för det slutna.

2.2.3 UbiquitiEdgeswitch(PoE)

Denna köptes in av Nordsken för att underlätta placering av accesspunkter då denna switch har stöd för Power over Ethernet. Vilket innebär att accesspunkten får sin strömförsörning via ethernetkabeln och det resulterar i mindre kablage.

Ny skärmad kabel kontakterades då Unifi APAC pro kräver mer ström än de gamla

accesspunkterna. Portarna mot accesspunkterna var tvungen vara trunkportar då flera vlan skulle färdas över dessa, VLAN 65 samt VLAN 70 för det trådlösa nätet och VLAN 90 för DHCP. Två stycken olika PoE inställningar användes för de två olika modellerna av accesspunkter. Passive för Unifi AP samt auto för Unifi APAC pro. Detta då Unifi APAC pro inte kräver en ständig matning av ström då switchen känner av om en av dessa accesspunkter är inkoplade i porten medans Unifi AP behöver ständig matning.

(13)

2.2.4 Distributionslager

De två distributionsswitcharna som skulle komma att placeras i taket ovanför LANdelen av evenemanget (se bilaga 4). Konfigurerades i huvudsak med trunkportar för de olika accessswitchar som var på de olika borden i lokalen.

Den andra distributionsswitchen (Dist2) hade dock en extra port för att ge tillgång till den switch som skulle ge tillgång till en del av utställare och crewnätet.

En switch på den övre konferensvåningen användes också för att ge access till de trådlösa accesspunkter, LANdeltagare, och utställare på denna våning. Denna hade åtkomst till CORElagret via en fiber som dragits sedan tidigare mellan våningsplanen och kopplades in på Scandics befintliga patchpaneler för att ge åtkomst ut i lokalerna. Detta på grund av att switchen befann sig i ett förråd i ett trapphus klassat som brandzon och tillfällig kabel inte kunde dras då dörrarna var tvungna att kunna stängas.

Förutom en accesslista som blockerade all SSHåtkomst till switchen samt att inloggning skulle ske mot en Tacacs+ server så utfördes ingen speciell säkerhetskonfiguration då switcharna ansågs vara säkra nog i och med att när evenemanget påbörjats var de fysiskt oåtkomliga på grund av deras placering.

2.2.5 Accesslager

Accessswitcharna konfigurerades med ett antal switchar som användes för dels

deltagarna i LANdelen av evenemanget och ett några switchar för utställare och de som arbetade med evenemanget.

Samtliga switchar hade en grundkonfiguration för säkerhet och AAA som såg likadan ut på alla enheter (se bilaga 7).

De switchar som användes på LANdelen var konfigurerade med samtliga portar i accessläge tillhörande de VLAN som bordet de placerades på tillhörde. En av gigabitportarna på switchen konfigurerades som trunk och tillät åtkomst för

accessportarnas VLAN samt Management för tillgång via SSH. Den andra gigabitborten slogs av.

Det fanns även ytterligare en LANdel på evenemangets övre konferensvåning som hade fyra stycken switchar. Skillnaden mellan dessa switchar och de på den nedre planens LAN var att alla fyra switchar hörde till samma VLAN då detta var anpassat för 70 användare.

Switcharna hade samtliga fastethernetportar i accessläge för vlanet och båda gigabitportarna i trunkläge för access mot CORE och Internet. Dessa fyra switchar

(14)

kopplades sedan samman i en så kallad daisychain. Detta på grund av att

distributionsswitchen för dessa befann sig i en annan del av byggnaden och mängden utrustning var begränsad.

De switchar som användes av utställare och arbetande vid evenemanget konfigurerades med mestadels accessportar för VLAN 55 och en del portar som trunk för WLAN ifall de skulle kommas att användas för accesspunkter under evenemanget. De portar som inte var i bruk slogs av när evenemanget väl startat. Även på dessa var en av gigabitportarna trunk för de vlan som användes på switchen.

Switcharna som användes av utställare och arbetare såg ut enligt följande:

2.2.6 Switch för Esport Crew

Denna switch befann sig bakom scenen (se bilaga 4). Den användes av det team som arbetate med livestreaming och anordning av evenemangets esport. Samtliga portar i denna switch konfigurerades i accessläge för det VLAN som tillhörde LANdelen på evenemangets övre plan. Detta på grund av att det fanns en stor del adresser över som aldrig skulle komma att brukas på detta VLAN.

En av portarna konfigurerades även för att ge tillgång till VLAN 50 som var tänkt för de som arbetar med evenemanget då den användes av mediateamet för att ge nätverksaccess till en kamera som de använde på scenen.

2.2.7 Switch för Utställare och LTU

Denna switch placerades i taket närmare biblioteket (se bilaga 4). Den användes för att ge access till T3s mätningsutrustning som skapade en graf över hur mycket trafik som gick ut ur nätet under hela evenemanget. LTU hade även fyra stycken datorer för att visa upp projekt som gjorts under året och hade nätverksaccess via denna switch.

Ett antal accesspunkter var även kopplade till denna switch.

(15)

2.2.8 Switch för WLAN på övre konferensplan

På den övre konferensplan så placerades en switch i taket i korridoren för att get

accesspunkterna på våningen nätverksåtkomst. Den användes även för att ge en dator vid figurspelsborden nätverk. Förutom detta så var även de accesspunkter som placerades i biblioteket anslutna till denna switch.

2.2.9 Switch för Nätverkscrew och WLAN samt utställare

Denna switch placerades där utrustningen för underhåll av nätverket befann sig (se bilaga 4). Den gav även access till en av utställarna och ett antal accesspunkter.

Det var den enda switchen som hade accessportar i VLAN 90, Management, och man kunde på så sätt komma åt samtliga enheter i nätverkstopologin via SSH från denna plats.

(16)

3. Metod och planering

I detta avsnitt tas processen innan, under, och efter evenemanget upp. Topologi samt

konfigurering och uppsättning av nätverket och tillvägagångssätten under Nordsken beskrivs på ett mer ingående vis.

3.1 Metod

Tidigare rapporter som publicerats inom nätverkslösning för Nordsken studerades för att se hur de löste uppgiften samt se om förbättringar kunde åstadkommas. Kontakt oftast i form av

videokonferenser hölls med Nordsken vänner från ett tidigt skede i arbetet, där vi fick de kriterier som skulle uppnås samt att vi kunde presentera våra lösningar och stämma av allt eftersom. De funktioner som önskades var i stort relativt ospecifika då man i princip bad om ett fungerande nätverk med WIFI. Efter diskussion med våran handledare beslutades det att nätverket skulle delas in i ett flertal VLAN för att förhindra onödig broadcasttrafik samt kunna förhindra åtkomst till servrar och de utställare som befann sig på evenemanget. Informationen som behövdes för utförandet kom främst ifrån manualer för utrustning, internet, samt den tidigare nämnda rapport som publicerats på LTU om ett liknande arbete utfört 2013.

3.2 Arbete inför Nordsken

Denna del ger en beskrivning av det förberedande arbete som utfördes innan evenemangets början.

3.2.1 Planering

En grov tidsplan sattes upp för hur arbetet skulle schemaläggas innan evenemanget. Allt eftersom satte vi i gruppen upp muntliga tidsramar som vi tyckte skulle vara löst innan utsatt tid. Vi skapade även en plan över vilka tjänster och verktyg vi skulle behöva på våra servrar.

Lokalerna där Nordsken skulle äga rum besöktes för planering av bland annat placering av hårdvaran och patchning för att bruka det befintliga nätet där vi ej kunde dra tillfälligt kablage.

Inventering av switchar samt kablage utfördes och sorterades då viss kablage inte uppnåde kraven.

(17)

3.2.2 Konfiguration

Konfigurering av hårdvara samt installation av serverar och mjukvara skedde under den schemalagda tiden innan Nordsken. För fullständig konfiguration av nätverksenheter se bilaga 7.

3.2.3 Test

Dagarna innan evenemanget så testades samtlig utrustning så att all konfiguration var korrekt sparad och inte behövde ytterligare konfiguration efter att utrustningen startats. Det som undersöktes var främst att alla anslutna enheter fick en adress tilldelat via DHCP inom korrekt adressrymd samt att samtliga enheter på nätverket kunde nås via SSH från

Management nätet.

Detta testades igenom att utrustningen kopplades ur och stängdes av fullständigt för att sedan koppla ihop allt som det skulle komma att se ut under evenemanget. Samtliga enheter prövades ett antal gånger.

(18)

3.3 Arbete under Nordsken

3.3.1 Montage

Två dagar innan evenemanget fick nätverksgruppen på Nordsken tillgång till lokalerna på Scandic. Placering av switchar, accesspunkter och kabeldragning pågick fram till start av evenemanget. De verktyg som användes för detta var bland annat buntband, saxlift, stegar och tejp för att underlätta demontering.

Placeringen av utrustning kan avläsas under bilaga 4.

3.3.2 Underhåll

Under evenemangets gång krävdes en del kabeldragning, konfigurering och felsökning då dels andra grupper i Nordskencrew ville få åtkomst till internet och andra tjänster i diverse placeringar i lokalen. Nya switchar placerades ut samt byttes ut på grund av dålig

prestanda. Det trådlösa nätverket försöktes optimeras ständigt under evenemanget.

3.3.3 Support

När evenemanget var igång agerade nätverksgruppen som support för nätverksrelaterade problem hos LANdeltagare. Dessa problem var mestadels enklare problem som

saknade drivrutiner för nätverkskort etc.

Under de dagar som Nordsken var öppet gick nätverksgruppen skiftgång för att finnas till support dynget runt.

3.4 Arbete efter Nordsken

3.4.1 Demontering

Efter att evenemanget slutat så monteras samtliga enheter ned och kablage återlämnas till Nordskens förråd. Switchar och diverse nätverksenheter töms på konfiguration och de switchar som lånats från LTU Campus Skellefteås Ciscolab återlämnas.

Nätverksutrustningen som tillhörde Norsken återlämnades till densamma.

(19)

4. Trådlöst Nätverk

Implementationen av trådlöst nätverk var det största åtagandet under projektet. Då skalan på det planerade nätet var av en helt annan omfattning än gruppens tidigare erfarenhet. Att upprätta ett nät i en så stor miljö med redan befintliga nätverk kommer visa att vara sig mycket mer

komplicerat än beräknat. Störningar från andra nät, mängden användare, signalstyrka på

accesspunkter, och kanalplanering är något som måste ses över innan nätet kan etableras för en fullduglig funktion. Att utföra en mätning med exempelvis Ekahau Site Survey före implementering av nätverket är att rekommendera då detta kan underlätta avsevärt med konkurrerande nätverk.

Ifall ett redan existerande nät som anpassats specifikt för de miljöer där ett tillfälligt nät skall sättas upp måste detta tas i åtanke för att inte störa ut det mindre nätet.

Det trådlösa nätverket bestod av sammanlagt 17 accesspunkter varav 13 var av modellen UnifiACPRO. Dessa var nyinköpta för i år med förhoppningen att höja standarden på det nätverket. Även 4 av de äldre UnifiAC användes också, dessa fanns kvar sedan tidigare år.

För konfiguration av samtliga accesspunkter användes mjukvaran Unifi Controller. Denna mjukvara är ett licensfritt konfigurationsprogram för Unifi accesspunkter och underlättar konfigurering samt överblick över samtliga accesspunkter i nätverket. Kan hämtas från Unifi’s hemsida. För mer information om programmet se Unifi WLC user’s manual [1].

Accesspunkterna anslöts till en Ubiquiti PoE switch i den mån det var rimligt att göra så (se bilaga 4). Detta för att undvika att använda PoE injektorer i så stor utsträckning som möjligt.

I övrigt anslöts samtliga accesspunkter på det övre planet samt biblioteket till en switch i korridoren på konferensvåningen. Med undantag från två av accesspunkterna då det fanns tillgång till

anslutningar som medförde betydligt mindre kabeldragning(se bilaga 4).

(20)

5. Servrar

Servrar valdes att användas för att underlätta drift samt att öka säkerheten. Samt att vår nätverksutrustning inte skulle behöva lägga prestanda på tjänster som exempelvis DHCP.

Två stycken serverenheter användes i topologin, en Dell poweredge 2590 och en Dell poweredge R320. Båda servrana installerades med Esxi för att kunna skapa flera virtuella maskin. En server för samtliga verktyg och tjänster för nätverket och den andra endast för DHCP och PAT för det öppna trådlösa nätet. På alla virtuella maskinerna installerades Vmware tools som gör att Esxi kan lättare hålla reda på hur mycket av hårdvaran som används och ger extra funktioner som att dom virtuella maskinerna startas när serven startas.

5.1 Server 1

5.1.1 TFTP

Användes för att spara befintlig konfiguration och eventuell ändring i switcharna.

Archive är en inbyggd funktion i vissa IOS från Cisco. Archive används för att spara runningconfig till en extern plats vid sparning av konfigurationen. I detta fall från switch till TFTPserver.

5.1.2 MRTG

Installerades på en VM med Ubuntu server 14.04 med syftet att ge grafer som visade på hur mycket trafik som gick igenom distributionslagret samt Coreswitchen i nätverket.

5.1.3 OpenNMS

Installerades på samma VM som MRTG för att ge en överblick över samtliga enheter på nätverket. Via webinterface kunde man se status på samtliga länkar på enheterna men även de traps som konfigurerats på enheterna vid exempelvis förändringar i konfiguration.

(21)

5.1.4 TACACS+

Tacacs+ installerades på en VM med Windows Server 2008 för att definiera användare som har tillgång till nätverksenheterna via SSH. Switcharna skickar en förfrågan till denna server ifall den användare som försöker logga in mot switchen har rättighet att göra det.

När användaren sedan försöker göra en förändring eller exekvera kommandon. Den sparar även loggar på samtliga som loggar in eller gör förändringar i enheterna på nätverket.

5.1.5 ISCDHCPServer

Installerades på en VM med Ubuntu server 14.04 med syfte att tilldela dynamiska

IPadresser till klienterna på både det trådburna och trådlösa nätverket. Eftersom vi delar upp varje rad av bord i olika VLAN med olika adressrymder så måste man använda sig utav DHCPrelay detta ser till att DHCPförfrågningar kan gå mellan olika VLAN och kan nå DHCPservern. DHCPrelay fungerar så att om en DHCPDISCOVER som är en broadcast kommer till en enhet med DHCPrelay så gör den om meddelandet till ett unicastmeddelande. Detta medelande har IPadress som sourceadress och skickar den till DHCPservern. DHCPservern jämför sourceadressen mot DHCPscope för att bestämma vilken adress som ska tilldelas .

För mer ingående DHCP konfiguration se bilaga 6

5.1.6 Owncloud

Installerades på en VM med Ubuntu server 14.04, syftet med owncloudet var att vi skulle kunna lagra filer på detta men owncloudet användes aldrig för det var snabbare att bara lagra allt på google drive.

5.1.7 WLC

En mjukvarubaserad WLC från Unifi installerades på ett Windowsoperativsystem. Detta kunde sedan administreras via webbläsaren om man surfade mot den

virtuella maskinens IPadress från VLAN 90.

(22)

5.2 Server 2

5.2.1 pfSense

Installerades på en separat server för att ge den så hög prestanda som möjligt. Detta för att det öppna trådlösa nätverket inte skulle upplevas med försämrad kvalitet då samtliga klienter anslutna till detta översattes via PAT till en och samma publika adress. Servern hade två nätverksinterface varav ett av detta fick agera gateway för det öppna trådlösa nätverket och det andra endast skickade och tog emot trafik ut mot internet.

Det trådlösa nätet kunde då göras användbart av en stor mängd användare medans det faktiskt bara använde en av de publika adresserna. VLAN 65 konfigurerades för detta nät med en adressrymd på 192.168.64.0 /22

(23)

6. Resultat

6.1 Inför

Inventeringen resulterade i att en hel del kablage märktes vara trasig eller på annat sätt obrukbar sedan tidigare år. Antingen pågrund av fysiskt slitage eller att vissa kablar inte fick kontakt över vissa par i kabeln. Det resulterade i att mer kabel fick köpas in inför evenemanget.

Veckorna innan evenemangets början hade vi ännu inte fått tillgång till den adressrymd som vi skulle använda på plats. Vi fick därför lösa prövning av konfiguration av servrar och nätverksenheter med tillfälliga IPadresser som fick bytas ut veckan innan start då vi fick de faktiska adresserna.

Det LAN som var på den övre konferensplan var i princip tom ända fram till 23 dagar innan evenemanget med bara en handfull bokade platser. Detta förändrades dock och vi var tvungna att dela på det tänkta Crewnätverket som då var en hel /24 adressrymd.

Resultatet blev två stycken /25 adresser samt en extra switch till LANdelet på övre plan.

Konfigurationsmässigt hade vi inga större problem med den mesta utrustningen och det flöt på riktigt bra. Den nya Cisco SG500X switchen som användes som Core var dock baserat på ett nytt OS som ingen av oss varit i kontakt med tidigare så det krävdes en del läsning för att komma på hur det fungerade. Inga problem orsakades dock av detta.

Inför etableringen och montage av nätverket på plats så saknades det en beskrivning över vilka av utställarna som faktiskt behövde en trådad anslutning och vilka som klarade sig med trådlöst. Detta resulterade i att ett flertal justeringar fick göras under evenemangets gång men i stort så var detta inget större problem och kunde lösas relativt enkelt.

6.2 Under

Under evenemangets uppstart så uppmärksammade vi att DNSförfrågningar gick otroligt långsamt via den DNSserver vi blivit tilldelade av T3 och funderade på att istället hänvisa till Googles DNSserver från vår DHCP. Vi beslutade att ändra till Googles DNSservrar för att se till att evenemanget skulle fungera så bra som möjligt

Vi hade även ett kort avbrott över hela nätverket under fredagskvällen då Telia hade ett tillfälligt avbrott på sitt nätverk. Detta varade dock endast några minuter och hade inget med våran utrustning att göra.

(24)

Vi hade även problem med den switch som användes av de som tillhandahöll livestreaming av Esport och höll i de turneringar som anordnades under evenemanget. De tappade anslutningen till internet med jämna mellanrum och vi beslutade att byta ut switchen helt.

Konfigurationen i de båda switcharna var likadan och inga problem upptäcktes efter att switchen bytts ut.

I övrigt så upptäcktes det att det saknades kablage för anslutning av exempelvis en kamera som skulle användas för att sända ut föreläsningar från den stora scenen samt att

mediateamet behövde ha ett eget trådlöst nätverk i sina lokaler för sin utrustning. Detta löstes med en Zyxel trådlös router som placerades i rummet. Routern sattes i AP mode och kopplades in i den befintliga switchen för att agera som accesspunkt, dock på ett annat vlan än de befintliga wlanen för att inte behöva konkurera med de andra.

6.3 Efter

Efter evenemangets slut så gick demonteringen av samtlig utrustning oväntat snabbt.

Jämfört med en monteringstid på ca 18 timmar så tog demonteringen 45 timmar med avkonfiguration av switchar inräknad. Utrustningen packeterades och flyttades till Nordskens förrådslokaler och den utrustning som hörde till LTU Campus Skellefteå återlämnades där.

6.3 Trådlöst

Det trådlösa nätverket var under den första dagen något instabilt. Roamingen fungerade inte riktigt när man gick mellan våningsplanen och när det var som flest besökare var detta betydligt märkbart. Detta kunde dock lösas under evenemangets andra och tredje dag då vi efter en del justeringar i signalstyrka, bandbredd, och kanalplanering kunde uppnå en godtycklig effekt på roamingen.

Trots detta var det trådlösa nätverket i stort långsamt under evenemangets gång och det hände att klienter tappade sin anslutning mot accesspunkterna.

6.4 Servrar

De två servrar vi använde fungerade felfritt under hela evenemanget. Med undantag för MRTG som i och för sig fungerade. Men graferna var i stort sett obrukbara då de lika gärna hade kunnat visa på om länken var uppe eller nere. Graferna var inte skapade för nog mycket trafik och låg konstant på max från det att evenemanget startade tills dess att nätverket stängdes ner.

(25)

7. Diskussion

Denna del av rapporten behandlar tankar kring nätverket i stort under evenemanget. Vad som gick bra och vad som gick dåligt. Det innehåller även en diskussion kring hur det trådlösa nätverket skulle kunna förbättras med dels den kunskap som vi fått under vår utbildning men också från andra studier som gjorts i ämnet.

7.1 Trådlöst nätverk

Det trådlösa nätverket fungerade som sagt i stort inte så bra. Under evenemangets andra och tredje dagar så var det trots allt acceptabelt men prestandan på det hela var ändå inte var den hade kunnat vara. En större inblick i hur wifi fungerar i så pass stor utsträkning och under så högt användande som faktisk föregick under evenemanget hade vart otroligt bra.

Nästa år skulle vi rekommendera att göra en “site survey” med ett mätningsprogram för att få en bra överblick hur det redan implementerade nätverket ser ut för att kunna planera kring det och slippa störningar i så stor utsträckning som möjligt.

Detta kan bero på ett antal orsakar varav en förmodligen ligger i det faktum att vi inte har någon riktig erfarenhet i att hantera trådlösa nätverk i en så här stor utsträckning. Att sätta upp en accesspunkt i en laborationsmiljö och få tillgång till den är inte riktigt samma sak som att sätta upp 20 stycken accesspunkter i en konferensmiljö där det redan finns andra nät som kan störa signalen. Scandic hade redan ett etablerat trådlöst nätverk som vår utrustning var tvungen att konkurera mot. Denna utrustning är planerad för att täcka hela Scandics yta och har automatiskt kanalplanering. Detta gör det även svårt att göra en bra planering för vår utrustning. Denna skulle man nog med fördel kunna slå av i framtiden för att få mindre störningar på signalerna.

Då inställningarna för signalstyrka, kanal, och utnyttjad bandbredd görs automatiskt som grundinställning på accesspunkterna så försökte vi lösa problemet från början med att starta om enheterna då detta skulle lösa en del problem enligt leverantören. Dock kunde vi manuellt ställa in samtliga av dessa attributer. Då vi ställt ner signalstyrkan, förbättrat kanalplaneringen för att förhindra oönskat kanalöverlapp, och ställt bandbredden till 20

respektive 40MHz för 2,4 och 5GHz antennerna så kunde vi se en betydlig förbättring i kvalitén.

Vi ställde även in UnifiACPRO accesspunkterna att föredra att använda 5.0GHz över 2.4GHz där möjligheten fanns.

Vi ställde även in accesspunkterna på att försöka lastbalansera efter det att de tagit emot 50st klienter. När accesspunkten nått upp i 50 klienter ber den nästkommande klienter att försöka hitta en annan accesspunkt att ansluta till i första hand. Hittar den ingen så kan den

(26)

ändå ansluta till den första. På så vis försökte vi sprida klienterna över de accesspunkter vi satt upp i lokalerna.

I publikationen WiFox: Scaling WiFi Performance for Large Audience Environments[2]l.

Föreslår man en lösning för större Wifimiljöer som syftar i att prioritera olika datatyper baserat på vilket protokoll det använder samt vilken typ av data applikationen faktiskt sänder. Med hjälp av en QoS lösning med filter för olika typer av data kan man helt enkelt öka prioriteten på vissa svar mellan klient och accesspunkt och öka prestandan på det trådlösa nätverket.

Då publikationen bara en modell testat i en miljö med 45 stycken accesspunkter så kan en liknande QoS baserat lösning med olika prioriteter vara en utmärkt lösning för just

Nordsken. En prioritetsordning på exempelvis utställare,media, arbetare, besökare, hade nog gett en betydligt bättre prestanda där det behövdes. Trots detta så skulle det ändå behöva en betydlig prestandaökning i det lägsta nivåerna.

I Designing High Performance Enterprise WiFi Networks[3]. Föreslår man en lösning som bygger på wifi i en kontorsmiljö med ett flertal olika klientenheter i konstant rörelse.

Metoden bygger på vad man kallar en “Dense AP structure” och syftar i att man har fler accesspunkter än vad som faktiskt behövs som sammankopplas och de överflödiga accesspunkterna ställs i ett passivt läge. Allt detta sköts av en WLC som sköter

lastbalansering och kanalplanering mellan dessa för att kunna hantera hög belastning och man beskriver i rapporten hur man kommit fram till en bra lösning för ett trådlöst nät där bra roaming under högt tryck är ett krav. Dock utfördes denna undersökning i en kontorsmiljö med en mängd mindre rum snarare än vår miljö där det övre planet kan liknas vid detta men det nedre planet är en betydligt mer öppen miljö.

Någon av dessa metoder skulle kunna vara en lösning för att få det trådlösa nätverket att fungera bättre. En första lösning som skulle behöva prövas är att just använda fler

accesspunkter då vi faktiskt hade sammanlagt 27 att tillgå medans endast ca 18 användes.

Med den lösning som presenteras i [3] så kan man nog få betydligt högre prestanda med hjälp av alla accesspunkter. Möjligtvis om detta inte duger så kan man även byta ut de accesspunkter som är av modellen unifi ac så att man har sammanlagt 30 av modellen unifi ac pro.

(27)

7.2 MRTG

Graferna producerade av MRTG var som sagt oanvändbara. De visade på ett maximalt trafikflöde för grafen konstant under deras användning. Detta hade förmodligen kunnat lösas igenom att öka maxvärdet på grafens axel så att den kunde visa på ett högre värde.

Detta är på grund av att i våran testmiljö innan evenemanget början så hade vi inte ens i närheten av samma mängd trafik och vi underskattade nog mängden som gick igenom distributionslagret.

7.3 DNS

DNSförfrågningarna gick innan evenemanget kom igång extremt långsamt. Det var förmodligen på grund av att ingen har använt den än, detta betyder att den inte har hunnit cacha några DNSnamn.

Vi beslutade att ändra till Googles DNSservrar för att se till att evenemanget skulle fungera så bra som möjligt Det löste problemet och fungerade perfekt under hela evenemaget.

7.4 Nätverk och adressering

Eftersom att vi enbart fick en /22 address som resulterar i 1022 användbara andresser blev vi tvungen att tänka om och kompromissa lite. Efter att ha uppskattat antalet besökare så valde vi även att använda en privat adressrymd för det öppna trådlösa nätverket och använda oss utav PAT för att översätta dessa till en publik adress för att spara på adresser.

Trots att adressrymden i början kändes för liten så var det i slutändan inga problem och var nog precis det som behövdes. Då det öppna trådlösa nätet löstes med ett privat nätverk slutade det med att vi hade ett 20tal adresser över.

(28)

7.5 Slutsats

I sin helhet är vi nöjda med våran insats i arbetet. Med tanke på arbetets utsträckning sett mot vår tidigare erfarenhet av laborationsmiljöer. I planeringsfasen av arbetet hade vi ännu inte tillgång till den adressrymd vi skulle använda under evenemanget men samtlig

konfiguration kunde prövas eftersom med tillfälliga adresser. Det enda man gärna sett var bättre var det trådlösa nätverket. Det fungerade som sagt men hade gärna sett att det fungerade lika bra som det trådade nätverket.

Då Nordsken blir allt större från år till år skulle tiden vi har tillgång till lokalen innan evenemanget överses, speciellt för den trådlösa planeringen. Längre tid att ha tillgång till lokalen innan evenemanget skulle även underlätta för kabeldragning, montering av

switchar och accesspunkter då det detta år var ganska ont om tid för detta. I allmänhet var arbetet för Nordsken väldigt lärorikt och band samman mycket av den utbildningen vi läser.

(29)

Källförteckning

1. https://dl.ubnt.com/guides/UniFi/UniFi_Controller_V3_UG.pdf Manual for Unifi WLC controller

2. https://www.cs.princeton.edu/~arpitg/pdfs/wifox.pdf

WiFox: Scaling WiFi Performance for Large Audience Environments

Arpit Gupta et al. Dept. of Computer Science, North Carolina State University 3. http://research.microsoft.com/pubs/73427/denseap.pdf

Designing High Performance Enterprise WiFi Networks

Rohan Murty† , Jitendra Padhye‡ , Ranveer Chandra‡ , Alec Wolman‡ , Brian Zill‡

†Harvard University, ‡Microsoft Research 4. Nordsken: Installation | Konfiguration | Drift

Hadi Bitar, Sebastian Stenlund, Robin Ågren

Högskoleexamen, (Examensarbete för Högskoleexamen, 2åriga utbildningar) Datornätverk, 2013

5. www.nordsken.se

(30)

Bilagor

Bilaga 1, Förkortningar

● LAN Local Area Network

Ett LAN är ett localt nätverk, exempelvis en byggnad med få subnät och ett begränsat antal anslutningar mot omvärlden.

● AP Accesspunkt

Trådlös enhet som används för att ansluta och skicka trafik till ett trådlöst nätverk.

Exempelvis en trådlös router.

● WLCWireless LAN Controller

Central enhet i ett trådlöst nätverk som sköter konfiguration och hantering av accesspunkter i nätverket.

● DHCP Dynamic Host Configuration Protocol

DHCP är ett nätverksprotokoll som ger möjligheten att ge nätverksinformation via ett nätsegment och tilldela datorerna dynamiska IPadresser samt default gateway och DNS

● PAT Port Address Translation

Översätter interna IPadresser till en yttre IPadress.

● DNS Domain Name System

Kopplar ihop IPadresser och domännamn.

● SSID Service Set Identifier

Det identifierar det trådlösa nätverlet.

● WLAN Wireless Local Area Network Ett trådlöst nätverk

● VLAN Virtual Local Area Network Är en virtuell avgränsning i en switch

● TFTP Trivial File Transfer Protocol Är ett filöverföringsprotokoll

● MRTG Multi Router Traffic Grapher

● PoE Power over Ethernet

Ger möjligheten att försörja ström via ethernetkabel

● SSH Secure Shell

Är ett säkert sätt för uppkoppling till en annan enhet över internet

● CLI Commandline interface Textbaserat användargränsnitt.

● CIDRClassless interdomainrouting

Metod att sköta ipadressering inom en domän. Ger möjligheten att dela upp nät i mindre

“subnät”.

(31)

(32)

Bilaga 3, Subnät

(33)

(34)

(35)

(36)

(37)

(38)

(39)

Bilaga 5, Wifi

Källarplan

Entréplan

(40)

Plan 2

(41)

ddnsupdatestyle none;

defaultleasetime 600;

maxleasetime 7200;

authoritative;

logfacility local7;

option domainnameservers 8.8.8.8, 8.8.4.4;

#option domainnameservers 80.244.65.3, 80.244.65.130;

#Management

subnet 192.168.90.0 netmask 255.255.255.0 { range 192.168.90.150 192.168.90.250;

option routers 192.168.90.55;

}

#Crew Vlan

}

#Bord A

}

#Bord B

}

#Bord C

}

#Bord D

}

(42)

#Bord E

}

#Bord F

}

#Bord G

}

#Bord H

}

#Wifi slutet

}

#Wifi open

}

#bord ijkl

}

(43)

Core

configfileheader Core

v1.3.0.62 / R750_NIK_1_3_647_260 CLI v1.0

set system queuesmode 4

file SSD indicator encrypted

@

ssdcontrolstart ssd config

ssd file passphrase control unrestricted no ssd file integrity control

ssdcontrolend cb0a3fdb1f3a1af4e4430033719968c0

!

vlan database

vlan 5,10,15,20,25,30,35,40,55,65,70,90 exit

voice vlan ouitable add 0001e3 Siemens_AG_phone________

voice vlan ouitable add 00036b Cisco_phone_____________

voice vlan ouitable add 00096e Avaya___________________

voice vlan ouitable add 000fe2 H3C_Aolynk______________

voice vlan ouitable add 0060b9 Philips_and_NEC_AG_phone voice vlan ouitable add 00d01e Pingtel_phone___________

voice vlan ouitable add 00e075 Polycom/Veritel_phone___

voice vlan ouitable add 00e0bb 3Com_phone______________

ip dhcp relay address 192.168.90.101 ip dhcp relay enable

bonjour interface range vlan 1 hostname Core

username happynet password encrypted 903ef1bc0ded2cd65583bb7d7bc6983ee22214c4 privilege 15

ip ssh server

!

interface vlan 1 no ip address dhcp

!

interface vlan 5

ip address 85.235.28.62 255.255.255.192 ip dhcp relay enable

!

interface vlan 10

(44)

!

interface vlan 15

!

interface vlan 20

!

interface vlan 25

!

interface vlan 30

!

interface vlan 35

!

interface vlan 40

!

interface vlan 55 ip dhcp relay enable

!

interface vlan 65

!

interface vlan 70

!

interface vlan 90

!

interface gigabitethernet1/1/1 shutdown

switchport mode access switchport access vlan 70

!

interface gigabitethernet1/1/5

(45)

switchport trunk native vlan 90

!

interface gigabitethernet1/1/9 description MOT_CREW_SWITCH switchport trunk allowed vlan add 65,70 switchport trunk native vlan 90

!

interface gigabitethernet1/1/10 switchport mode access switchport access vlan 90

!

interface gigabitethernet1/1/12 description TRUNK_DIST_1

switchport trunk allowed vlan add 5,10,15,20,25,30,35,40,55,65,70 switchport trunk native vlan 90

!

interface gigabitethernet1/1/15

ip address 185.52.183.126 255.255.255.252

!

interface gigabitethernet1/1/24 description TRUNK_DIST_2

switchport trunk allowed vlan add 5,10,15,20,25,30,35,40,55,65,70 switchport trunk native vlan 90

! exit

ip defaultgateway 185.52.183.125 router rip

exit

(46)

GRUNDCONF SWITCHAR

no ip domainlookup

enable secret hadouk3n123

username happynet password 0 hadouk3n123

ip domainname network.nordsken.se

spanningtree mode rapidpvst

spanningtree extend systemid

banner

***********************

Authorized access only!

***********************

ip accesslist standard SSH_ACCESS permit 192.168.90.0 0.0.0.255

ip ssh version 2

crypto key generate rsa generalkeys modulus 1024

line con 0

logging synchronous password hadouk3n line vty 0 15

logging synchronous transport input ssh password hadouk3n123

accessclass SSH_ACCESS in

snmpserver community private RW snmpserver community public RO

snmpserver host 192.168.90.100 version 2c public

snmpserver contact Helpdesk of awesomeness snmpserver enable traps portsecurity

snmpserver enable traps snmp linkup linkdown

aaa newmodel

aaa authentication login DEFAULT group Network_Engineering line aaa authentication enable default group Network_Engineering enable

(47)

aaa authorization configcommands

aaa authorization exec DEFAULT group Network_Engineering none

aaa authorization commands 0 DEFAULT group Network_Engineering none aaa authorization commands 1 DEFAULT group Network_Engineering none aaa authorization commands 15 DEFAULT group Network_Engineering none aaa accounting commands 0 default startstop group Network_Engineering aaa accounting commands 1 default startstop group Network_Engineering aaa accounting commands 15 default startstop group Network_Engineering tacacsserver host 192.168.70.102

tacacsserver key hadouk3n123

(48)

SWITCH A1

snmpserver location A1 hostname A1

Vlan 5

name Bord_A

Vlan 90

name Management

interface range Fastethernet 0/124 switchport access vlan 5

switcport mode access switchport portsecurity

switchport portsecurity violation restrict spanningtree portfast

no ip dhcp snooping trust ip dhcp snooping limit rate 20

interface gigabitethernet 0/1 description TRUNK_MOT_DIST switchport trunk native vlan 90 switchport trunk allowed vlan 5,90 switchport mode trunk

ip dhcp snooping trust

interface vlan 1 shutdown

interface vlan 90

ip address 192.168.90.1 255.255.255.0

exit

(49)

SWITCH A2

snmpserver location A2 hostname A2

Vlan 5

name Bord_A

Vlan 90

name Management

switchport mode access switchport portsecurity

interface vlan 90

ip address 192.168.90.2 255.255.255.0

exit

(50)

SWITCH B1

snmpserver location B1 hostname B1

Vlan 10 name Bord_B

Vlan 90

name Management

interface vlan 90

ip address 192.168.90.3 255.255.255.0

exit

(51)

SWITCH B2

snmpserver location B2 hostname B2

Vlan 10 name Bord_B

Vlan 90

name Management

interface vlan 90

ip address 192.168.90.4 255.255.255.0

exit

(52)

SWITCH C1

snmpserver location C1 hostname C1

Vlan 15 name Bord_C

Vlan 90

name Management

interface vlan 90

ip address 192.168.90.5 255.255.255.0

exit

(53)

SWITCH C2

Vlan 15 name Bord_C

Vlan 90

name Management

interface vlan 90

ip address 192.168.90.6 255.255.255.0

exit

(54)

SWITCH C3

Vlan 15 name Bord_C

Vlan 90

name Management

interface vlan 90

ip address 192.168.90.7 255.255.255.0

exit

(55)

SWITCH D1

snmpserver location D1 hostname D1

Vlan 20 name Bord_D

Vlan 90

name Management

interface vlan 90

ip address 192.168.90.8 255.255.255.0

exit

Nätverkslösning för Nordsken 2016 EXAMENSARBETE