SLUTRAPPORT FÖR IT - O-RINGEN BODEN 2013

SLUTRAPPORT FÖR IT - O-RINGEN BODEN 2013 Författare: Alexander Harsbo DD11 Core Christoffer Palm DD11 Core Emil Sarén DD11 Core Marcus Johansson DD11 Services Simon Skog DD11 Services Sebastian Svensson DD11 Services Sonny Johansson DD11 Projektledare, Services Marcus Johansson DD11 Access Jakob Schmidt DD11 Access Examinator: Erik Gunnarsson Utskriftsdatum: 2013-09-08

Sammanfattning Sammanfattning Sommaren 2013 anordnade O-Ringen världens största orienteringstävling. Uppdraget för O-Ringengruppen på JTH har varit att förbereda inför evenemanget när det gäller nätverk och IT. Svenska Orienteringsförbundets program för tävlingar och resultatsidan är det som har haft högsta prioritet. Målet med projektet har varit att tillhandahålla de tjänster som O-Ringen har efterfrågat. Under evenemanget har vi driftat alla tjänster och sett till att dessa har sköts på ett tillfredställande sätt. O-Ringengruppen har i sin tur delats upp i tre olika grupper med olika ansvarsområden. De olika grupperna är Access, Core och Services. Accessgruppen har fokuserat på WLAN, IP-telefoni och access-switchar. Coregruppen har jobbat med coreswitchar och brandväggar. Servicegruppen ansvarar för alla servertjänster inom nätverket. Resultatet visar hur strukturen har sett ut under evenemanget och vilka motgångar vi har stött på. Varje arena förklaras och en topologikarta visas för varje. Problem som vi stötte på var att databasen hade prestandaproblem under den första dagen på första arenan. Dock omarbetades strukturen för att ordna detta. Sammanfattningsvis kan man säga att evenemanget var mycket lyckat. Och i alla led har man varit nöjd med gruppens arbete. Problem har löst på ett snabbt sätt, och vårat arbete har genomsyrats av en flexibilitet. 1

Innehållsförteckning Innehållsförteckning 1 Mål... 4 2 Teori... 5 2.1 Access... 5 2.1.1 Wireless Local Area Network (WLAN)... 5 2.1.2 Virtual Local Area Network (VLAN)... 5 2.1.3 Power over Ethernet (PoE)... 6 2.1.4 Voice over IP (VoIP)... 7 2.2 Core... 7 2.2.1 Hot Standby Router Protocol (HSRP)... 7 2.2.2 Brandvägg... 7 2.2.3 Virtual Private Network (VPN)... 8 2.3 Services... 8 2.3.1 VMware ESXi... 8 2.3.2 Dynamic Host Configuration Protocol (DHCP)... 9 2.3.3 OLA och SPORTident... 9 2.3.4 Webb... 10 2.3.5 Active Directory... 10 2.3.6 Domain Name System (DNS)... 10 2.3.7 Windows Depolyment Service (WDS)... 11 3 Planering och genomförande...12 3.1.1 Access... 12 3.1.2 Core... 12 3.1.3 Services... 12 3.2 Kontakter... 12 3.3 Projektplanering... 13 4 Resultat...14 4.1 Access... 14 4.1.1 Staden... 15 4.1.2 Arenorna... 15 4.1.3 Wireless... 20 4.2 Core... 22 4.2.1 Nätverkstopologi... 22 4.2.2 Arenorna... 22 4.2.3 Staden... 22 4.2.4 Belastningsgrafer... 23 4.3 Services... 25 4.3.1 Servertopologi... 25 4.3.2 O-Ringen Online... 25 4.3.3 Databas... 26 4.3.4 OLA... 27 4.3.5 WDS... 28 2

Innehållsförteckning 4.3.6 Shoutcast... 28 5 Diskussion... 29 6 Bilagor...31 Bilaga 1... 32 Bilaga 2... 33 Bilaga 3... 38 Bilaga 4... 42 Bilaga 5... 44 Bilaga 6... 46 3

Mål 1 Mål Sommaren 2013 anordnar O-Ringen världens största orienteringstävling. I flera års tid har studenter på programmet Datanätteknik vid Jönköpings Tekniska Högskola ansvarat för nätverket och drift av tjänster. Uppdraget för O-Ringengruppen på Jönköpings Tekniska Högskola I år är att innan evenemanget förbereda inför ett evenemang med hög driftsäkerhet. Under evenemanget ska vi se till att alla tjänster övervakas och sköts på ett tillfredställande sätt. Även arenorna ska flyttas och driftsättas. Det viktigaste är att drifta OLA och O-Ringenonline. Grundkrav från O-Ringen är: Drift av tävlingstjänsten OLA Drift av hemsidan O-Ringen Online Nätverk med Internetaccess på arenor och i O-Ringenstaden Internetaccess till utställare och butiker på plats efter deras specifikationer Målet med första praktikperioden var att förbereda arbetet och sätta upp och testa enheter och tjänster som kommer att behövas under själva tävlingen. Arbetet under första perioden fungerade som ett förslag som presenterades för O-Ringens IT-chef. Feedbacken som vi fick på första rapporten använde vi under vårens praktikperiod då vi även skrev ett examensarbete kopplat till O-Ringen. Målet under denna period har varit att sätta upp allt enligt kraven och sedan använda denna struktur under själva evenemanget. 4

Teori 2 Teori 2.1 Access 2.1.1 Wireless Local Area Network (WLAN) WLAN är ett samlingsnamn för flera olika sätt att ansluta till lokala trådlösa nätverk. Den standarden som är vanligast idag är IEEE 802.11. WLAN identifieras med hjälp av olika SSID (Service Set Identifier). Dessa SSID skickas ut med hjälp av broadcast så att enheter lätt kan hitta att det finns ett trådlöst nätverk i närheten. Det finns flera olika metoder att säkra WLAN. De vanligaste är WEP, WPA och WPA2 med utdelad nyckel. Det finns även säkerhetsmetoder som använder sig av olika certifikat för att identifiera vem som ansluter till nätverket. Trådlösa nätverk är smidiga för att man kan snabbt koppla upp användare utan att behöva dra kablar. En nackdel med trådlösa nätverk är att de delar mediet som de skickar data över. Trådlösa nätverk i Sverige sänder idag på två olika frekvensband, 2,4Ghzoch 5Ghz-bandet. Dessa frekvensband är öppna för allmänheten och kräver inte något tillstånd att sända på. Det finns mycket utrustning som sänder information på dessa frekvenser. Detta gör att det är lätt att få störningar i trådlösa nätverk. 2.1.2 Virtual Local Area Network (VLAN) Virtual Local Area Network eller VLAN är en teknik för att segmentera nätverkstrafik och skapa separata broadcast-domäner på lager 2 i OSImodellen. Det kan t.ex. vara användbart om flera avdelningar inom ett företag delar på en switch men varje avdelning vill hålla sin information inom sin egen avdelning. Det finns flera typer av VLAN standarder men den vanligaste är 802.1q (dot1q). Varje gång som ett paket kommer till switchen med VLANkonfiguration så taggas trafiken med ett VLAN-ID till dess att det lämnar switchen/switcharna som trafiket måste passera för att nå sin destination. En switchport kan i en Cisco-switch ligga i antingen access eller trunkläge. En accessport taggar endast trafiken när den kommer in i switchen och taggen plockas bort när trafik skickas ut på porten. Trunkar kan transportera taggad VLAN-trafik och placeras mellan switchar och routar som hanterar VLANtrafiken. Om trafik ska färdas från ett VLAN till ett annat så måste det routas på lager 3 precis som vanliga nätverk hade behövt routing för att få kontakt mellan varandra. 5

Teori Figur 2.1. Klienter i samma fysiska switch kan inte kontakta varandra om dessa är i olika VLAN. 2.1.3 Power over Ethernet (PoE) Power over Ethernet är en teknik som används för att skicka ström och data över en gemensam kabel. Denna teknik används ofta för att ge ström till accesspunkter, IP-telefoner och övervakningskameror som inte sitter i närheten av ett eluttag. För att få tillräckligt hög spänning till accessutrustningen så krävs minst kabelstandard category 5 eller högre. En fördel med PoE är att det blir lättare att placera accessutrustning på svåråtkomliga ställen eftersom man bara behöver dra en kabel. En annan fördel med PoE är att man även kan centralisera strömförsörjningen för sin accessutrustning. Figur 2.2. Olika enheter är får ström via switchen med tekniken Power over Ethernet. 6

2.1.4 Voice over IP (VoIP) Teori IP-telefoni (engelska Voice over IP) är en tjänst där man över ett vanligt IPnätverk kan ringa och ta emot samtal. Eftersom trafiken går via IP innebär det att trafiken hanteras precis som övrig trafik och inga extra kostnader tillkommer. Cisco CME (CallManager Express) kan användas för att koppla upp samtal mellan IP-telefoner i kontor över hela världen. CME fungerar på det sättet att den ger inställningar till telefonerna och håller sedan koll på vilka nummer som är tilldelade till vilken telefon som identifieras via MAC-adressen. Systemet kopplar upp samtalet men sedan går all trafik direkt mellan telefonerna utan att den går genom CME. 2.2 Core 2.2.1 Hot Standby Router Protocol (HSRP) HSRP (Hot Standby Router Protocol) är protokoll som används för att skapa redundans och feltolerans för standardgateway (default gateway). Varje router annonserar sin prioritet till närliggande routrar och den med högst prioritet blir primärroutern samt default gateway. Om primärroutern skulle gå ner så tar routern med näst högst prioritet över kommunikationen som default gateway. HSRP är ett Cisco proprietärt protkoll och används därför bara av utrustning från Cisco. Ett motsvarande protokoll som inte är Cisco proprietärt är VRRP (Virtual Router Redundancy Protocol). 2.2.2 Brandvägg En brandvägg är en dedikerad dator, eller programvara som kan installeras i en vanlig dator med uppgiften att avvärja dataintrång hos nätverksanslutna datorer. En nätverksbrandvägg är en brandvägg som installeras mellan två olika nätverk, vanligast mellan internet och ett privat nätverk. En personlig brandvägg är ett program som installeras på en individuell dator för att skydda just den datorn. En dator som är ansluten till internet utsätts varje dag för extremt många intrångsförsök, det är därför brandväggens uppgift att filtrera de paket som skickas så att bara de som datorn ska ha kommer fram. En brandvägg kan filtrera trafik enligt flera olika parametrar, exempelvis IPadress, portnummer eller fysiskt gränssnitt. Många modernare brandväggar kan även välja specifika program och hur de har tillåtelse att kommunicera. En brandvägg kan filtrera inkommande paket på två olika sätt, stateful-packet inspection och stateless-packet inspection. Stateful-filtrering analyserar hela paket och kan avgöra ifall inkommande paket ingår i en pågående överföring som initierats från insidan. Stateless-filtrering inspekterar alla paket, men endast paketens header och kan därför luras att ta mot paket som ger sken av att vara del av en pågående överföring. 7

Teori 2.2.3 Virtual Private Network (VPN) VPN står för Virtual Private Network och är en förlängning av ett privat nätverk och de resurser det nätverket innehåller över ett delat eller publikt nät, exempelvis internet. Det tillåter en dator att sända och ta emot data över publika eller delade nätverk så som serveråtkomst, fildelning och skrivare genom att emulera egenskaperna hos det privata nätverket samt att använda sig av samma säkerhets och konfigurationspolicys. Detta åstadkoms via en så kallad point-to-point anslutning, som upprättas via dedikerad anslutning, kryptering eller en kombination av de båda. För att detta ska fungera kapslas datan in och ges en ny header med den routinginformation som behövs för att leverera paketet dit det ska. För säkerhets skull krypteras även informationen så att inte paketet kan fångas upp och läsas. Denna process kallas tunneling. Det finns två typer av VPN anslutningar Site-to Site och Remote Access. Site-to-Site kopplar samman två nätverk så de fungerar precis som om de varit del av ett och samma privata nätverk, detta tillåter t.ex. två kontor inom samma företag att komma åt samma resurser samt att dela information med varandra. Remote Access tillåter en extern enskild dator att ansluta sig till nätverket och att ta del av de resurser som finns precis som om den varit del av det privata nätet. Detta är väldigt användbart då det tillåter t.ex. resande anställda att kunna ansluta till företagets nätverk var de än befinner sig. 2.3 Services 2.3.1 VMware ESXi VMware är ett företag som utvecklar program och mjukvara för att kunna virtualisera flera operativsystem på en och samma dator. De har en rad olika programvaror t.ex. Workstation som körs som ett program på en Windowseller Linuxmaskin. Det finns även ESXi som är ett helt eget operativsystem som körs direkt på en server och är riktat mot företag. Om man har flera ESXi-maskiner så kan man köra ett program som heter vcenter. Då räcker det att ansluta till vcenter och sedan genom vcenter så ansluter man till andra ESXi-maskiner så man kan administrera flera maskiner i samma fönster. Andra fördelar är mer säkerhet och bättre resurshantering. vcenter körs på en Linux eller Windows maskin som vanligtvis redan körs under en ESXi-maskin. 8

Teori Figur 2.4. Olika ESXi-enheter är kopplade till ett stort vcenter. 2.3.2 Dynamic Host Configuration Protocol (DHCP) Dynamic Host Configuration Protocol (DHCP) är en tjänst för att dynamiskt tilldela klienter de nätverksinställningarna som behövs för att fungera i nätverket. De vanligaste inställningarna är IP-adress, nätmask, DNS-server, default gateway samt lease-tiden för lånet. Vad en DHCP-server gör är att tilldela dessa uppgifter till klienter och binda det till datorns MAC-adress. Alla lånen sparas i en tabell för att undvika att två datorer får samma IPadress och för att servern ska kunna sköta det administrativa med lease-tider och övrigt. Utbytet mellan servern och klienten sköts via fyra steg. Först skickas en DHCP Discovery via broadcast för att alla DHCP-server ska veta att en klient är intresserad av nätverksinställningar. Servern i sin tur skickar iväg ett DHCP Offer via unicast till klienten med ett förslag på inställningar. Klienten svarar med ett DHCP Request via broadcast för att acceptera inställningarna. Servern svarar till slut med ett DHCP Acknowledgment via unicast för att bekräfta att klienten får de inställningar som den har accepterat. Eftersom paketen från klienten till servern skickas via broadcast är det viktigt att denna trafik tillåts mellan server och klient även om de är i olika lokala nätverk. Detta kan göras via en DHCP Relay, Cisco IP Helper fungerar till detta ändamål. 2.3.3 OLA och SPORTident OLA är Svenska Orienteringsförbundets program som används för att administrera och arrangera tävlingar. OLA bygger på Java och används till allt från anmälan, banor, registrering och annat. Tjänsten bygger på en 9

Teori server/klient-lösning där servern sköter all kontakt med databasen och klienterna kontaktar servern för information. Även om OLA har en inbyggd databas är det nödvändigt att använda en extern databasmotor, exempelvis MySQL, för större evenemang. Tidtagningen sköts via SPORTident som är ett system där alla löpare har ett RFID-chip. Chipen stämplas mot en basenhet och informationen stannar även i chipet. 2.3.4 Webb Webbserver är en tjänst som används för att kunna visa webbsidor. För att komma åt en webbsida så behövs en webbläsare t.ex. Firefox, Chrome eller Opera. Varje gång du surfar på nätet så används en webbserver som skickar tillbaka material till dig. Webbservern använder protokollet http som står för hypertext transfer protocol, det finns även ett protokoll som heter https som är samma som http fast den krypterar anslutningen mellan servern och din webbläsare. De två mest använda webbservrarna idag är Apache och IIS, Apache brukar köras på en Linux-maskin och är populärt tillsammans med server-side scriptet php, medans IIS körs på Windows maskiner oftast med server-side scriptet ASP.net. Portarna som används för http är port 80 och för https är det port 443. 2.3.5 Active Directory Active Directory är ett katalogsystem skapat av Microsoft som ingår i de flesta Windows server operativsystem. Servrar som har Active Directory tjänsten installerad kallas för domänkontrollanter. Mot en domänkontrollant så autentiseras användare som är anslutna till domänen. Domänkontrollanten har även möjlighet att lägga in policys och restriktioner som ska gälla för användarna. I Active Directory lägger man in länkar till alla resurser som finns tillgängliga i domänen så som användare, skrivare, servrar, hemkataloger, användargrupper samt MSI-pakter som skall installeras hos användaren. Active Directory använder sig av ett antal olika tjänster och protokoll, dessa är: LDAP(Lightweight Directory Access Protocol) version 2 och 3, Kerberos och DNS. LDAP är ett protokoll som används för att kommunicera och hämta information från en katalogtjänst. Kerberos är ett autentiseringssystem som tillåter användare att få tillgång till kataloger och tjänster de ska ha behörighet till. Kerberos kräver ett lösenord från användaren och undersöker sen om användaren har tillgång till den tjänsten som söktes. 2.3.6 Domain Name System (DNS) Domain Name System (DNS) är en tjänst för att lättare adressera datorer. Tjänsten fungerar på det sättet att den översätter domännamn och till IPadresser och vice versa. Istället för att skriva 91.189.45.187 använder man istället www.oringen.se. Det finns olika sorters uppslag en DNS-server kan använda. Den vanligaste är A, som innebär att man kopplar ett domännamn 10

Teori till en IP-adress. Det finns bland annat även CNAME för alias och MX som hanterar vilka adresser som är mailservrar i domänen. Systemet är helt hierarkisk och är indelat i zoner. Ett uppslag går till på det sättet att om man t.ex. vill slå upp www.oringen.se frågar man först en rootserver. Servern svarar då med namnservern för.se-domäner eftersom rootservern endast har information om toppdomäner. Man går vidare och frågar sedan namnservern för.se. Om den namnservern har information om hela domänen får man ett svar direkt, annars vidarebefordras man till namnservern för zonen oringen.se, och där kan man få reda på IP-adressen för domännamnet. root.com.org.dk.se oringen Figur 2.3. En förenkling av den hierarkiska strukturen för DNS. 2.3.7 Windows Depolyment Service (WDS) Windows Deployment Services är en tjänst som tillåter dig att distributera Windows operativsystem över nätverk. WDS gör det möjligt att distributera avbildningar av Windows 7, Vista, Server 2008, Server 2003 och Windows XP. WDS använder sig utav Preboot Execution Environment (PXE) och en Trivial File Transfer Protocoll server (TFTP-server) för att kunna starta en nätverksboot för att hämta ett operativssystem. För att därefter påbörja en installation genom nätverket använder sig WDS utav användargränssnittet Windows PE (Pre-installation environment) som kommunicerar med WDS servern för att kunna installera en vald avbild av ett Windows operativsystem. www 11

Planering och genomförande 3 Planering och genomförande Under planeringsfasen för första praktikperioden valde gruppen att dela in projektet i tre arbetsgrupper. I vissa fall har uppgifter gått över flera arbetsgrupper, till exempel uppsättning av schema för IP-adresser. De tre grupperna och deras arbetsområden är: 3.1.1 Access Ansvarat för planering av nätverksstrukturen och för kontakt med slutanvändare detta innebär att konfigurera access-switchar, trådlösa nätverk och IP-telefoni. Under evenemanget har de varit ansvariga för att utrustningen kommer på plats och fungerar. Gruppen består av: Marcus Johansson (JTH) Jakob Schmidt (JTH) 3.1.2 Core Ansvarade för stamnätet och anslutningen mot Internet. Detta innebar bland annat coreswitchar och brandväggar. Inkluderat i deras uppgift är även all sorts routing och VPN-länkar. Gruppen består av: Alexander Harsbo (JTH) Christoffer Palm (JTH) Emil Sarén (JTH) 3.1.3 Services Ansvarat för servrar och servertjänster. Allt från planering, uppsättning, slutgiltig konfiguration och övervakning. De mest vitala tjänster är de som är tävlingskritiska, främst handlar det då om att OLA med tillhörande databas fungerar tillfredsställande. Gruppen består av: Marcus Johansson (JTH) Simon Skog (JTH) Sebastian Svensson (JTH) Sonny Johansson (även projektledare) (JTH) 3.2 Kontakter Löpande under hela projektets gång har kontakt hållits med O-Ringens ledning, och då främst IT-chefen. På studenternas sida har en kontaktansvarig funnits som har skött all kontakt från och till O-Ringen. Kommunikationen har fungerat väldigt bra, och ledningen har sett till att svara på alla våra frågor. 12

Planering och genomförande Kontakt med Cisco har även hållits under sista praktikperioden. Kommunikationen har inte alltid fungerat eftersom Cisco har varit otydliga och varit dåliga på att svara. Leveransen inför evenemanget var försenad vilket gjorde att vi åkte upp en dag senare än vad vi hade tänkt. Utrustningen var dessutom inte det som vi hade beställt. Det största problemet var att switcharna hade SFP-platser som fungerar för LC-fiber. O- Ringen har dock bara SC-fiber. Detta löstes dock enkelt med fiberkonverters som IT-chefen hade ordnat innan som en backup-lösning. 3.3 Projektplanering Under första praktikperioden gjordes en stor planering för hur strukturen skulle se ut. Den strukturen omarbetades sedan under sista praktikperioden för att få en struktur som O-Ringens ledning ville ha. Mycket ändrades också de sista dagarna och under evenemanget. Därför har inte en detaljerad plan kunnat utarbetas, utan vi har varit förberedda på att vara flexibla i våra lösningar. 13

Resultat 4 Resultat 4.1 Access Under denna delen förklaras nätverksstrukturen under evenemanget. Följande tecken och figurer kommer att användas: Lager 3 Switch Lager 2 switch Dum switch Accesspunkt TP kabel Fiber kabel VPN tunnel

4.1.1 Staden Resultat Arena Core Internet Servernät Oringen 2014-16 Kiosk babs Ljud access WLC Staden Dist ute 1 Folksam access Jönköping Dist mässsa Dist ute 2 LKAB access Noc Expedition Team Sportia Mässa1 Mässa2 Mässa3 Press access 4.1.2 Arenorna Nätverksstrukturen skiljer sig lite mellan de olika arenorna eftersom att de inte såg likadana ut vid någon site. Vi har utgått ifrån en 3-lagers modell när vi har strukturerat nätverket men vi har anpassat oss efter situationerna som uppstod och ibland har vi fått göra undantag där det krävdes. Nätverket fick anpassas efter placering för tälten och även vilken kabellängd som fanns tillgänglig. Vid flera ställen har vi valt att seriekoppla switchar på accesslagret eftersom att kablarna mellan tälten var fördragna och vi fick jobba utifrån vad som fanns på site. Det var även så att vi hade bara ett begränsat antal långa kablar och vi fick då göra det bästa av situationen. Vi hade även olika typer av anslutningar till internet vid olika arenor. Vid de arenor som hade en långsam uppkoppling valde vi att endast placera ut trådlöst nätverk där det var absolut nödvändigt samt att vi körde med begränsad hastighet och annonserade bara ut de SSID som krävdes. Motorstadion Motorstation var första arenan som byggdes upp och här hade vi tillgång till en fiber-uppkoppling på 100Mbit/s. Vi byggde upp nätverket efter en 3- lagers modell men det slutade med att vi hade 2 stycken seriekopplingar på grund av att vi inte hade tillgång till så långa kablar som krävdes för att lyckas koppla in alla access-switchar direkt i distributionslagret. 15

Resultat Vi hade trådlösa accesspunkter kopplade till alla access-switchar utan Resultat 2 eftersom att den switchen låg väldigt nära Resultat 1 och Kiosk 3. Vi fick även dra en lång kabel från Resultat 1 till ett torn där vi placerade ut en accesspunkt för att täcka sjukvårdarnas behov av internet. Alla SSID var annonserade på accesspunkterna utan på just accesspunkten för sjukvård som endast annonserade Funktionär och Tech. Motorstadion WLC Arena Team Sportia Oringen-Open Kiosk 2 Sjukvård AP Resultat 1 Internet Dist 2 Core Resultat 2 Dist1 Oringen Staden Servernät Kiosk 3 Kiosk 1 Speaker Arena Noc Kiosk 4 16

Resultat Pagla Pagla var en liten arena där vi använde oss av existerade kablage som fanns tillgängligt. Det fanns 3 olika byggnader på siten och mellan varje byggnad fanns det kablar dragna med patch-paneler installerande i varje byggnad. Vi använde oss utav de existerande patch-panelerna för att koppla mellan vår egen utrustning. Därför blev nätverksstrukturen inte direkt optimal men vi ansåg att det var värt att spara tiden på kabeldragning och fokusera på att få allt i drift. Vi hade tillgång till en långsam ADSL-uppkoppling på 3-4Mbit/s som fanns i Stora huset. Därför fick vi göra en speciallösning där vi konfigurerade ett nytt Vlan som gick från switchen i Stora huset till Core. Pagla Internet WLC Arena Resultat TV Stora huset Sjukvårdsstugan Core Tornet Servernät 17

Resultat Stadssprinten Statssprinten var en liten arena där vi endast kopplade upp det som absolut behövdes. Vi hade tillgång till en fiber-uppkoppling på 100Mbit/s men vi använde oss endast av en access-switch och en accesspunkt för att ge uppkoppling till funktionärer. Stadsprinten Internet Oringenstaden Access Core WLC Arena 18

Resultat Storklinten Storklinten var den andra stora arenan som vi kopplade upp. Vi utgick ifrån en 3-lagers modell men vi var tvungna att seriekoppla vid två tillfällen där en koppling var mellan distributions-switcharna. Uppkopplingen som vi fick tillgång till var en ADSL-anslutning på 3-4Mbit/s. Vi satte endast upp två accesspunkter för att täcka behovet för sjukvård och press och båda dessa SSID gick med begränsad hastighet. Storklinten Jönköping Kiosk 1 Internet Dist 2 Servernät Kiosk 2 Core Kiosk 3 Oringen Staden WLC arena Dist 1 Oringen Open Kiosk 4 Arena Noc Resultat 1 Resultat 2 Expedition Speaker Press Accesspunkt Sjukvårds accesspunkt Åberget Åberget var den sista etappen och den tredje stora arenan som vi kopplade upp. Vi fick tillgång till en fiber-uppkoppling på 100Mbit/s och vi valde därför att koppla upp många accesspunkter som annonserade ut alla SSID. Vi jobbade utifrån en 3-lagers modell men den var väldigt svår att hålla på vid denna arena eftersom att tälten var långt ifrån varandra och vi fick jobba med den kabeldragningen som existerade. Det blev totalt 3st seriekopplingar varav en var mellan de båda distibutionsswitcharna. Vi fick placera en switch i Team-Sportias tält för att kunna nå ut till O-ringen Open. Switchen i Team-Sportias tält var en distibutions-switch och för att kunna koppla på deras utrustning var vi tvungna att sätta en av trunkportarna i accessläge. 19

Resultat Åberget Oringen Staden Jönköping Internet Expedition Arena Noc Servernät WLC Arena Core Dist Arena 1 Speaker Kiosk 4 Kiosk 1 Kiosk 3 Dist arena 2 Oringen Open Kiosk 2 Resultat 1 Resultat 2 Team Sportia 4.1.3 Wireless Utrustingen som vi fick tillgång till under eventet var 4 stycken Wireless Lan Controllers av modellen 5508. Vi fick även tillgång till 30 stycken accesspunkter av modellen 1142. Det som var tänkt från början var att placera ut 2 stycken WLC:er i Staden och 2 stycken i serverbussen för att ha redundans. När eventet drog igång stod det klart att en miss i beställningen hade skett och vi saknade SFP:er för alla controllers. Vi fick till slut tag i två stycken SFP:er och valde då att köra en WLC i staden och en i serverbussen. I staden använde vi oss utav 11 stycken accesspunkter för att täcka behovet under mässan. På de större arenorna kopplade vi upp 9 stycken accesspunkter förutom på storklinten där vi hade en klen uppkoppling till internet och valde därför att inte erbjuda trådlöst närverk för deltagare av eventet utan endast till press och sjukvård. Under de mindre eventen så som Pagla och Statssprinten så kopplade vi endast upp en accesspunkt per site eftersom att det inte fanns något stort behov för trådlös anslutning. Det trådlösa nätverket bestod utan fyra olika SSID och alla var säkrade med WPA2-PSK utom Oringen-Open som var helt öppet. 20

Resultat Oringen-Tech Fanns för oss i nätverksgruppen så vi kunde administrera våra tjänster ute på site samt lösa felsöka utrustning utan att behöva koppla in oss med TP-kabel. Detta SSID gick med högsta prioritering för trafik. Oringen-Funktionär Var till för alla funktionärer som jobbade under eventet och det hade den näst högsta prioriteringen för trafik. Oringen-Press Var för pressen under eventet och detta SSID gick med relativt låg prioritering. Oringen-Open Var ett öppet SSID som vem som helst kunde ansluta sig till. Det var begränsat i form av hastighet per anslutning där varje enhet fick tillgång till max 0,5 Mbit/s. 21

4.2 Core Resultat 4.2.1 Nätverkstopologi Efter den inledande planeringsfasen av praktiken kom vi fram till att köra End-to-End VLAN då routing först skedde i Core och en konstant L2 domän fram till dess, samt trafikrestriktion på L3 switcharna. 4.2.2 Arenorna För att tidsmässigt lyckas sätta upp fyra olika arenor med en tidsmarginal på 2-4 timmar vardera krävdes det att vi gjorde en likartad nätverks/serverlösning för varje arena. För att lyckas med detta så byggde vi en serverbuss två dagar innan första etappen där Core samt alla servrar sattes in. Detta gjorde att vi hade en likadan fysisk lösning för Core på samtliga arenor, medan distributionslagret samt accesslagret kunde skilja sig lite beroende på hur arenan geografiskt sett vart byggd men logiskt sätt så var allt detsamma på alla arenorna. De internetförbindelser vi fick varierade mellan att vara 100 Mbit/s fiber till fyra stycken ADSL-kablar på 4 Mbit/s vardera. När vi hade tillgång till 100 Mbits/s fiber terminerades förbindelsen i vår Core ASA5520 och allt fungerade som vanligt. När vi fick fyra ADSL kablar så fick vi lösa detta på annat sätt, vilket gjorde att vi tog en kabel själva för att kunna ge ut de tjänster till dem som behövde det medan t.ex. Team Sportia och Speakerbåset fick varsin egen ADSL-kabel då de var ytterst känsliga mot avbrott. Alla som jobbade under O-Ringen hade sitt egna nät inom sin grupp. För att minimera risken för angrepp såväl internt som externt placerades varje grupp i ett eget VLAN. Alla nödvändiga interna tjänster för varje grupp kunde nås inom sitt egna VLAN medan tillgång till andra VLAN samt servrarna var begränsad. De grupperna som behövde tillgång till någon tjänst i vårt servernät tilläts endast åtkomst till den specifika tjänsten. För att ge alla den felsäkerhet och tillgång till nätet som skall finnas använde vi oss av HSRP på våra coreswitchar där GUL agerade HSRP master men vid eventuellt avbrott hade BLÅ tagit över. För att radiotältets utrustning skulle fungera krävdes det speciell konfiguration från vår sida. En lapp gavs till oss med ett antal TCP/UDP portar som skulle öppnas samt forwardas till deras interna ip-adresser. Detta gjorde att vi satte upp en 1:1 NAT mellan en av våra publika adresser till en av deras interna samt en port forwarding till deras IP-telefon. De fick även tillgång till vår site-to-site vpn mellan arena och stad. 4.2.3 Staden Den slutgiltiga Core strukturen skiljde sig till viss del från det förslag som tagits fram under planeringsfasen inför eventet. VoIP användes flitigt för att upprätthålla snabb och smidig kommunikation mellan arenorna och nätverkscentralen i staden. Till detta använde vi oss av fyra stycken Cisco IP 22

Resultat phone 7940, där vi hade 3 stycken installerade i vår nätverkscentral samt en ute på arenan. Dessa använde sig av Power over Ethernet vilket besparade oss uppgiften att hitta separat strömförsörjning till dessa. För att skapa redundans och feltolerans för default gateway planerade vi att använda oss av HSRP. Detta blev dock inte fallet då vi under förberedelsedagarna innan eventet brände vi säkringar flertal gånger på grund av överbelastning. Detta medförde att vi fick vara väldigt återhållsamma med vår strömförbrukning i vår tilldelade serverhall. Ett resultat av detta vara att vi under eventets gång valde att endast ha en av de två 6500:orna i drift med den andra konfigurerad men ej driftsatt. Vi hade även bara möjlighet att använda oss av en ASA åt gången då vi bara fick en koppling mot internet indragen till serverrummet. Även där fick den andra stå bredvid fullt konfigurerad men ej driftsatt. Avsikten med detta var att om något gick fel skulle vi snabbt kunna flytta över anslutningarna till en färdigkonfigurerad maskin och endast ha ett kortare driftstopp utan att för den skull överbelasta strömförsörjningen. Ett annat problem som uppstod i vårt provisoriska serverrum var att de kylaggregat vi hade inte var effektiva nog. Därför fick vi även kompromissa med antalet påslagna maskiner för att hålla temperaturen nere. Dessa problem löstes dock innan eventet drog igång men då var det så pass kort tid kvar att vi valde att inte ändra i den lösning som fungerat bra fram till dess. Från staden satte vi upp en site-to-site vpn till vår utrustning på JTH. Den fungerade felfritt under hela eventet förutom ett mindre avbrott under en natt. Under eventet använde vi oss av 2 stycken publika IP-adresser i staden. Den första var en statisk 1:1 nat som användes till Ljud-Olas IP-telefoni, den andra var PAT konfigurerad och användes till allt förutom Ljud-Olas IPtelefoni. Vid ankomst fick vi en lista med 15 stycken publika IP adresser till vårt förfogande. Dessa skulle räcka till staden samt två arenor. Vi använde oss dock bara av tre adresser totalt, två till staden och en för arenabruk. All intern routing sköttes av L3-switchar via CEF routing. All trafik som skulle routas på Internet hanterades av vår ASA 4.2.4 Belastningsgrafer Grafen nedan visar skickad trafik från interfacet som har kopplingen mot Internet. Första delen visar Storklinten där det endast fanns ADSL-koppling. Andra delen visar Åberget där det fanns en 100 Mbit/s-uppkoppling. 23

Resultat Grafen nedan visar en mer detaljerad bild av skickad trafik under Storklintens andra dag. Grafen nedan visar trafik som togs emot under Åberget. Som mest var vi uppe i 30 Mbit/s. 24

4.3 Services Resultat 4.3.1 Servertopologi Vår servermiljö bestog av ett ESXi-kluster som var uppbyggt med fyra fysiska servrar som konfigurerats redundant med hjälp av en vcenter maskin och ett SAN. MySQL var också en egen fysisk maskin men fanns en backup på ESXi klustret. Alla servrar har fyra stycken 1 GB/s Ethernet-portar var. Två stycken av dem är kopplade till management för att vcenter ska kunna ansluta till dem. De två andra portarna är kopplade så att de virtuella maskinerna kommer ut i nätverket via trunkar. Varje port går till varsin separat core-switch i nätverket för att få redundans. Alla fyra maskiner delar på en och samma NFS-share där alla virtuella maskiner ligger. Maskinerna kommer åt denna via management-nätverket. Där på har vi delat ut fem stycken 1 TB-diskar som vi kör i RAID 5 för att få högre driftsäkerhet. Från SAN-servern går det två stycken Ethernet-kablar till varsin switch för att få redundans om ett kort skulle gå ner. Arenorna Till varje arena så körde vi ut vår serverbuss. Det enda vi behövde göra på arenorna var att koppla in ström, internet och en kabel från distributionsswitcharna till core-switcharna i bussen. Sedan var det bara att starta igång allt. Staden Såg likadant ut som i bussen fast det var en stationär lösning som aldrig flyttades. 4.3.2 O-Ringen Online O-Ringen Online kördes på en egen fysisk maskin på dnlab. För att sätta upp servern användes O-Ringens egna manual. Inga speciella inställningar 25

Resultat användes för detta. Vissa inställningsfiler fick vi av O-Ringens personal. Första dagen var det problem med O-Ringen Online eftersom databasen krånglade och vi då beslutade att stänga ner alla tjänster som inte var kritiska för att tävlingen skulle fungera. O-Ringen Online fungerade förutom det felfritt under hela evenemanget förutom en liten miss i en konfigurationsfil som vi hade fått. Nedan visas belastning på maskinen som körde O-Ringen Online under arenan Åberget när det var som mest folk på servern. 4.3.3 Databas Vi hade tre ställen som vi hade databaserna på under evenemanget. Dessa var i staden, bussen och Jönköping. I staden så hade vi en master och en slav, samt en extra slav som vi hade lagt i Jönköping, den slaven hade hand om resultaten till O-Ringen Online. I bussen så hade vi en liknande setup, vi hade en master och en slav. Bilden nedan visar vår databasstruktur. 26

Problem Resultat Under genrepet så fungerade databaserna helt okej. Men när vi sedan kom till första etappdagen insåg vi snabbt att vi hade en flaskhals någonstans i databaserna. Det tog tid för orienterarna att få ut sina etappkvitton vilket medförde att det blev kö in till måltältet. Vi provade att ändra alla värden vi kunde utan att starta om databaserna vilket skulle medföra att det blev ännu längre köer. Efter ett tag så kom vi fram till att det inte kunde vara databaserna som det var fel på utan det måster vara något med lagringssystemet som vi använde oss av. Tester När vi kom tillbaka till Staden från första etappdagen så började vi göra tester på databasen och dess SAN som vi använde oss av ute på arenan. Vi såg då att det var lagringssystemet som gjorde att det gick segt. Efter det så tog vi två fysiska servrar och installerade SQL-databaserna direkt på servrarna och behöll lagringen lokalt. Detta medförde att databaserna inte hade några problem överhuvud taget när vi gjorde tester på dem. Strukturen som vi slutligen använde oss av var att vi hade en master och en slav i staden samt en slav kopplad till staden i Jönköping. Sedan hade vi en master och en slav i bussen. När vi hade en arena igång så använde vi oss av databaserna i bussen och pekade då alla OLA-servrar till dessa två databaser. Och när vi tog ner arena för kvällen så gjorde vi en backup på databasen, flyttade över den till staden och startade upp den och pekade då om OLA servrarna till staden istället. Detta förlopp gjorde att vi slapp alla problem som kunde uppstå med High Availability samt att vi fick mycket snabbare diskar på våra databaser i bussen. Efter att vi hade gjort den här ändringen så hade vi inga fler problem under hela eventet. Figuren nedan visar belastningen på master-databasen mitt under tävlingen på Åberget. 4.3.4 OLA På varje plats (arenan och staden) fanns en fysisk maskin som körde OLA. På den fysiska maskinen på arenan kördes tre logiska OLA-servar; en för tävlingen, en för speaker och en för resultatskärmarna. I staden kördes två servrar; en för administrationen och en för att OLA-ansvariga för O-Ringen skulle komma åt servern direkt från Internet. OLA kördes alltid mot aktiv masterdatabas. När arenan var igång kördes alla OLA-servrar i både staden och arenan mot arenans databasserver. När bara 27

Resultat staden var igång kördes dessa mot stadens masterdatabas. Vid varje flytt fick vi därför efter flyttad databas stoppa OLA-servarna och starta dessa när replikeringen var färdig. 4.3.5 WDS Under evenemanget fanns det en Windows deployment-server uppe. O- ringen behövde en deployment server för att installera operativsystem på cirka 150 klientdatorer under O-ringen 2013. För att under tävlingen spara tid så valde vi självklart att göra installationen av operativsystemen som vi deployade ut helt och hållet unattended, detta gjorde vi genom att använda oss utav två stycken svarsfiler som vi skapade med hjälp av Windows System Image Manager och en operativsystemsinstallationsfil. Dessa två filer finns som Bilaga 4 respektive 5. Vi har valde att köra servern i IP multicastläge vilket betyder att klienter kunde komma in när som helst under en multicast-distribution och hämta data som behövdes för en fullständig installation, detta utan att behöva avbryta processen för andra klienter som var mitt uppe i en installation. För att nätverket under O-ringen inte skulle belastas av 150 klientdatorer som laddar ner program och uppdateringar till Windows valde vi att skapa en modifierad avbildning vilket betyder att vi modifierade en operativsystemsbild genom att uppdatera den fullt ut och installera programmen som behövdes på klientdatorerna. 4.3.6 Shoutcast Några dagar innan evenemanget fick vi information om att en radio-server skulle upp. En fysisk server på dnlab sattes upp med Windows Server 2008. Konfigurationen finns som bilaga 6. 28

Diskussion 5 Diskussion Under evenemanget har gruppen sett till att målen har nåtts. Alla vitala tjänster och andra krav har fungerat bra. Ledningen har varit väldigt nöjda med vår insats. En stor anledning till detta har varit att vi löpande har haft bra kontakt med ledningen, och gruppen har haft stora möjligheter att forma lösnigar själva. Förutom generalsekreteraren Thomas Lindell och IT-chefen Egon Palo har även varje arena haft en underchef inom IT. Dessa personer har gjort ett utomordentligt arbete med att förbereda och hjälpa oss under evenemanget. Även nästa års IT-ansvarig för O-Ringen har under hela evenemanget varit tillgänglig och hjälpt till med det mesta. Han har varit ett mycket bra tillskott och fungerat som en extra person i gruppen. Trots vissa problem har evenemanget i stort gått väldigt bra. I alla led har man varit nöjda och imponerade över IT-gruppen. Ansvarig för OLA på administrationen sa efter evenemanget att vi var den bästa IT-gruppen O- Ringen hade haft. Även generalsekreteraren och IT-chefen har varit väldigt nöjda, och detta har skapat mycket bra kontakter för framtiden. Vissa småproblem har funnits, och genom hela evenemanget var BABSterminalerna något som alltid krånglade på något sätt. Det började först när terminalerna levererades och de behövde kopplas på ett annat sätt än vad vi hade tänkt från början. Alla terminaler behövde termineras via en svart låda som sedan skötte kontakten mot servrarna på Internet. Detta gjorde att vi fick sätta alla terminaler i ett eget VLAN som var kopplade mot svarta lådan. Ett tips inför nästa år är att beställa in terminaler som inte behöver termineras i en viss låda. Dessa kan säkert fungera bra i permanenta lösningar, men när man flyttar runt mellan olika arenor måste man ha en mer mobil lösning. Ett utav de största problemen under evenemanget för gruppen var databasproblem under första arenan. Under generalrepetitionen fungerade allt felfritt, men när databasen sedan blev mer belastad under den riktiga tävlingen blev det köer I målfållorna eftersom databasen samlade på sig massa querys men det tog sedan flera sekunder innan dessa kördes igenom. Problemet med detta tros vara problem I vårt lagringssystem som databasserver var kopplad till. Trots köer fungerade dock tävlingen hela tiden, och inga tider försvann. Trots problemen var O-Ringens ledning aldrig kritiska mot oss, och de var nöjda med att tävlingen fungerade. Inför nästa dag på arenan gjordes en ny lösning av gruppen under kvällen och natten. Den nya lösningen kördes sedan på resten av evenemanget. Lösningen fungerade sedan felfritt utan prestandaproblem under resten av evenemanget. IT-chefen var mycket imponerad över vår förmåga att lösa detta problemet. Under tidigare O-Ringen har arenor satts upp mycket tidigt på morgonen för att sedan börja användas några timmar senare. Detta året sattes dock arenorna upp mycket tidigare, och vi behövde aldrig arbeta med arenorna på natten. Det hade dock behövs en till person i access-gruppen, de som främst arbetade med att sätta upp arenorna. Denna person hade man kunnat ta från core-gruppen, där det ofta var överflödigt med tre personer. Istället hade man kunnat ha två personer i core, och då haft fyra stycken i access.

Diskussion En sak som hade kunnat organiseras bättre var rivandet av staden. När vi hade rivit staden fick vi ärenden om att administrationen och kioskerna behövde Internet. Eftersom allt redan var rivet fick vi sätta upp en temporär lösning för dessa. Detta skapade onödigt arbete i några timmar som hade kunnat användas för att vila efter evenemanget. Dessutom fick vi veta att Team Sportia skulle ha Internet till en dag efter vi åkte hem, även de fick ta del av den temporära lösningen som sedan andra fick plocka ner. Nästa år kan det vara en idé att planera tidigare för den temporära lösning som ska vara uppe de sista dagarna. Även beställningen till Cisco hade kunnat gå smidigare. Beställningen var väldigt försenad, vilket gjorde att utrustningen kom upp väldigt sent och dessutom hann inget förkonfigureras. Som tur väl var hade ledningen bestämt att vi skulle upp till Boden några dagar tidigare än förgående år för att inte behöva stressa. All extra tid vi fick där uppe behövdes verkligen för att hinna konfigurera utrustningen. 30

Bilagor 6 Bilagor Bilaga 1 Bilaga 2 Bilaga 3 Bilaga 4 Bilaga 5 Bilaga 6 Konfiguration för WLC Konfiguration för access-switchar Konfiguration för distributions-switchar Konfiguration för WDS (Windows PE) Konfiguration för WDS 2 (OOBE) Konfiguration för Shoutcast 31

Bilaga 1 Bilagor Welcome to the Cisco Wizard Configuration Tool Use the '-' character to backup System Name [Cisco_49:43:c0]: Enter Administrative User Name (24 characters max): Admin Enter Administrative Password (24 characters max):******** Management Interface IP Address: 10.10.14.10 Management Interface Netmask: 255.255.255.0 Management Interface Default Router: 10.10.14.1 Management Interface VLAN Identifier (0 = untagged): 138 Management Interface Port Num [1 to 4]: 1 Management Interface DHCP Server IP Address: 10.10.11.21 AP Manager Interface IP Address: 10.10.14.5 AP-Manager is on Management subnet, using same values AP Manager Interface DHCP Server (10.10.11.21): Virtual Gateway IP Address: 1.1.1.1 Mobility/RF Group Name: Oringen Network Name (SSID): Oringen-Tech Allow Static IP Addresses [YES][no]: YES Configure a RADIUS Server now? [YES][no]: no Warning! The default WLAN security policy requires a RADIUS server. Please see documentation for more details. Enter Country Code (enter 'help' for a list of countries) [US]: SE Enable 802.11b Network [YES][no]: YES Enable 802.11a Network [YES][no]: YES Enable 802.11g Network [YES][no]: YES Enable Auto-RF [YES][no]: YES Configuration saved! Resetting system with new configuration... User: Admin Password: Pa$$w0rd (Cisco Controller) > config prompt WLC-Stad1 (WLC-Stad1) > (WLC-Stad1) > save config Are you sure you want to save? (y/n) y Configuration Saved! 32

Bilaga 2 Bilagor Arena Access: conf t service password-encryption! hostname Access-Switch-Arena enable secret Pa$$w0rd username admin password 7 username Tech password Pa$$w0rd ip domain-name Oringen.staden crypto key generate rsa 1024 ip ssh version 2 ip dhcp snooping vlan 15-160 no ip dhcp snooping information option ip dhcp snooping no ip domain-lookup spanning-tree mode rapid-pvst spanning-tree extend system-id vtp mode transparent vlan 10 Name SERVER vlan 12 Name VoIP vlan 14 Name WLC_AP vlan 15 Name Press vlan 16 Name Accesskiosk vlan 18 name OLA vlan 20 name BABS vlan 100 name WLANpress vlan 110 name WLANfunk vlan 128 name WLANopen vlan 138 name MGMT Interface Vlan1 no ip address shutdown interface FastEthernet0 no ip address shutdown 33

Bilagor interface range GigabitEthernet1/0/1 36 switchport mode access spanning-tree portfast interface range GigabitEthernet1/0/37-44 switchport mode access switchport access vlan 20 spanning-tree portfast shutdown interface range GigabitEthernet1/0/45 46 switchport mode access switchport access vlan 14 spanning-tree portfast interface range GigabitEthernet1/0/47 48 switchport mode trunk switchport nonegotiate ip dhcp snooping trust interface range GigabitEthernet1/0/49 52 shutdown interface Vlan1 no ip address shutdown interface vlan138 description SSH management ip http server ip http secure-server ip sla enable reaction-alerts snmp-server community ORINGEN2013 RO snmp-server enable traps cpu threshold snmp-server host 10.20.11.23 ORINGEN2013 cpu process cpu threshold type total rising 40 interval 5 process cpu statistics limit entry-percentage 40 size 300! line con 0 timeout login response 60 logging synchronous login password Pa$$w0rd line vty 0 4 session-timeout 120 timeout login response 60 login local transport input ssh logging synchronous line vty 5 15 session-timeout 120 timeout login response 60 login local transport input ssh logging synchronous 34

ntp server 10.20.11.254 end Bilagor 35

Bilagor Staden Access: conf t service password-encryption! hostname Access-Switch-Stad enable secret Pa$$w0rd username admin password 7 username Tech password Pa$$w0rd ip domain-name Oringen.staden crypto key generate rsa 1024 ip ssh version 2 ip dhcp snooping vlan 15-160 no ip dhcp snooping information option ip dhcp snooping no ip domain-lookup spanning-tree mode rapid-pvst spanning-tree extend system-id vtp mode transparent vlan 10 Name SERVER vlan 12 Name VoIP vlan 14 Name WLC_AP vlan 15 Name Press vlan 16 Name Accesskiosk vlan 18 name OLA vlan 20 name BABS vlan 100 name WLANpress vlan 110 name WLANfunk vlan 128 name WLANopen vlan 138 name MGMT Interface Vlan1 no ip address shutdown interface FastEthernet0 no ip address shutdown interface range GigabitEthernet1/0/1 36 switchport mode access spanning-tree portfast 36

Bilagor interface range GigabitEthernet1/0/ 37-44 switchport mode access swichport access vlan 20 spanning-tree portfast shutdown interface range GigabitEthernet1/0/45 46 switchport mode access switchport access vlan 14 spanning-tree portfast interface range GigabitEthernet1/0/47 48 switchport mode trunk switchport nonegotiate ip dhcp snooping trust interface range GigabitEthernet1/0/49 52 shutdown interface Vlan1 no ip address shutdown interface vlan138 description SSH management ip http server ip http secure-server ip sla enable reaction-alerts snmp-server community ORINGEN2013 RO snmp-server enable traps cpu threshold snmp-server host 10.10.11.23 ORINGEN2013 cpu process cpu threshold type total rising 40 interval 5 process cpu statistics limit entry-percentage 40 size 300! line con 0 timeout login response 60 logging synchronous login password Pa$$w0rd line vty 0 4 session-timeout 120 timeout login response 60 login local transport input ssh logging synchronous line vty 5 15 session-timeout 120 timeout login response 60 login local transport input ssh logging synchronous ntp server 10.10.11.254! end 37

Bilagor Bilaga 3 Arena Dist: Conf t service password-encryption hostname Dist-Switch-Arenan enable secret Pa$$w0rd username admin password 7 username Tech password Pa$$w0rd ip domain-name Oringen.staden crypto key generate rsa 1024 ip dhcp snooping vlan 15-160 no ip dhcp snooping information option ip dhcp snooping no ip domain-lookup spanning-tree mode rapid-pvst spanning-tree extend system-id vtp mode transparent vlan 10 Name SERVER vlan 12 Name VoIP vlan 14 Name WLC_AP vlan 15 Name Press vlan 16 Name Accesskiosk vlan 18 name OLA vlan 20 name BABS vlan 100 name WLANpress vlan 110 name WLANfunk vlan 128 name WLANopen vlan 138 name MGMT ip ssh version 2 interface range GigabitEthernet1/0/1 2 switchport trunk encapsulation dot1q switchport mode trunk switchport nonegotiate ip dhcp snooping trust 38