PROJEKTRAPPORT O-RINGEN 2010

Transkript

1 PROJEKTRAPPORT O-RINGEN 2010 Författare: Martin Andersson JTH DD08 Erik Berggren JTH DD08 Henrik Hagstedt JTH DD08 Henrik Johansson JTH DD08 Björn Lindén JTH DD08 Björn Nygren JTH DD08 Tim Olsson JTH DD08 Henrik Pennannen JTH DD08 Niklas Strand JTH DD08 Examinator: Erik Gunnarsson Utskriftsdatum:

2 Sammanfattning Sammanfattning O-Ringen är världens största orienteringsevenemang och inträffar en gång per år under sommarperioden. Evenemanget äger rum på olika platser i Sverige varje år och år 2010 är det Örebros tur. Tävlingen består av fem etapper varav två går i Örebro och de tre andra i Mogetorp, Hallsberg och Fellingsbro. Målsättning för projektet var att tillhandahålla avbrottsfritt nätverk samt ett antal nätverkstjänster under hela O-Ringen. Nätverket behövde innefatta viktiga punkter i oringenstaden (kansliet, pressen, mässan, skyltverkstaden och SportIdent) och alla arenor där tävlingar ägde rum. Tävlingsadministrationen sker helt i systemet OLA som därför var det den viktigaste tjänsten. Hemsidan oringenonline var också viktig för att deltagare skulle kunna följa liveresultat. Det ingick i målsättningen att det skulle finnas ett internetcafe men det blev inte av på grund av platsbrist. Nätverket byggdes med målsättningen att ändringar skulle kunna göras utan större avbrott i funktion och tjänster. Detta innebar att gruppen fick hitta en balans mellan säkerhet, funktionalitet och enkelhet. Tjänster såsom DNS och DHCP var ett grundkrav i nätverket för att det skulle vara lätt och användbart för användarna. Redundanta lösningar och funktioner användes i ganska hög grad, t.ex. så användes redundanta AD, DNS och DHCP servrar samt alltid minst en redudant SQL och OLA-server. Arbetet har delats upp i de tre grupperna Core, Services och Access. Core-gruppen inriktade sig på VPN-tunnlar, Routing, och VLAN samt WANkopplingar. Service-gruppen jobbade med OLA, AD, DNS, DHCP samt förberedelser inför Ghostning utav Klient-PCs. Access-gruppen konfigurerade WLC s och laborerade med AP s samt konfigurerade Access-switchar. Core-gruppens största problem var att veta hur O-Ringen nätet skulle designas. Det planerades från början för att samtliga arenor skulle ha fiber. Verkligheten såg helt annorlunda ut då fiber inte gick att få på fyra utav fem arenor. (Se avsnitt Telia-lådan) De mer än 200 klientdatorerna som användes var med i en windowsdomän. Användare loggade in mot domänen där det centralt gick att ställa in rättigheter och loginscript. Tävlingssystemet var redundant på två lager. Dels genom flertalet OLA servrar men även genom flera datbasservrar i backupsyfte. De övriga nätverkstjänster som ansågs vara kritiska var också redundanta. Wlanet var uppdelat med fyra olika SSID n, varje SSID fanns bara tillgängligt på de accesspunkter där SSID t behövdes. Access-switcharna hade bara access-portar till det VLAN som krävdes på den fysiska plats som switchen var uppsatt, samt trunkar. En IP-telefon på varje arena samt två i NOC en var konfigurerade. Viktiga lärdomar som O-Ringengruppen tagit till sig från Närkekvartetten (mindre tävling som användes som genrep inför O-Ringen) är att UPS är ett måste vid skarp drift. Under O-Ringen 2010 var Core-nätverket i O-Ringenstaden och på Arenan utrustade med UPS-kraft som klarade av att driva respektive utrustning i minst 30 minuter. Sida 2

3 Innehållsförteckning Innehållsförteckning 1 Mål Bakgrund Bakgrund till projektet O-Ringen OLA och Sportident Etapper Teori Services Active Directory Nagios Cacti teori MySQL OLA och SPORTident DNS DHCP NTP Core Site-to-Site VPN Brandvägg Spanning-Tree Access Power over Ethernet WLAN VLAN Clonezilla Planering och genomförande Ansvarsområden Services Planering för servrar och dess användning under O-Ringen MySQL och OLA AD (Active Directory) DHCP Nagios NTP Core VLAN Routing Grundkonfiguration för Nätverksutrustning Core-nät Säkerhetslösningar Cisco CallManager Express Remote Access VPN Private VLANs Wan länkar Sida 3

4 Innehållsförteckning 4.4 Access Trådlöst nätverk IP-Telefoner Switchar Närkekvartetten Ghostning Resultat Services Ola och MySQL Ad resultat Övervakning OringenOnline Bandbreddsgrafer Invigningen/stafetten på Stortorget Core Nätverket VTP Site to Site VPN Duplex Mismatch hos Stadsnätet Omdesign av ip-nät Avsaknad av VLAN på switchar Telia-lådan Access Trådlöst nätverk IP-telefoni mellan Arena och O-Ringenstaden Switchar Ghostning Diskussion Services Övervakning NTP Kioskdatorer Core Team Sportia Sjukvård Bilagor Bilaga 1 - Grundkonfiguration för Nätverksutrustning Bilaga 2 Konfiguration för O-NOC-C Bilaga 3 Konfiguration för O-ARENA-D Bilaga 4 Konfiguration för O-STA-D-MASSA Bilaga 5 Konfiguration för O-STA-A-PRESS Bilaga 6 Konfiguration för O-ARENA-A-RESULTATUTSKR Bilaga 7 Nätverkskarta för Etapp Bilaga 8 - Nätverkskarta för Etapp 2 och Bilaga 9 - Nätverkskarta för Etapp Bilaga 10 - Nätverkskarta för Etapp Bilaga 12 Nätverkskarta för O-Ringenstaden Bilaga 13 - Detaljerade bandbreddsgrafer Bilaga 14 - Replikeringsmanual Bilaga 15 - Tidsplan Sida 4

5 Mål 1 Mål De största och viktigaste målen med projektet är att drifta tjänsten OLA (Svenska Orienteringsförbundet system för hantering av orienteringstävlingar.) och oringenonline. O-Ringen vill under perioden juli, ha ett fullt fungerande nätverk och ett antal tjänster (se nedan). Veckan innan skall ett förarbete äga rum så att allting är klart innan tävlingen börjar. Specifika krav från O-Ringens sida är: Drift av tävlingstjänsten OLA. Drift av hemsidan O-Ringen Online. Trådlöst nätverk med internet access på arenor och i oringenstaden. Internetcafé Internetaccess till utställare och butiker på plats efter deras egna specifikationer Under evenemanget kommer O-Ringen gruppen att övervaka nätverket och tjänsterna samt vara i beredskap för problemlösning. Sida 5

6 Bakgrund 2 Bakgrund 2.1 Bakgrund till projektet För projektgruppen är O-Ringen 2010 ett projekt med största vikt lagd på att få den tekniska nätverksbiten att fungera. Föregående projektgrupp utförde detta med lyckat resultat vilket innebar att O-Ringen sökte upp kontakten med JTH för att få nuvarande års projektgrupp att arbeta med O- Ringen under evenemanget Projektet är uppdelat på två praktikperioder och 2 veckor under själva tävlingen. 2.2 O-Ringen 2010 O-Ringen är världens största orienteringsevenemang med upp till deltagare per år. O-Ringen 2010 går av stapeln i Örebro mellan den 24 till den 28 juli. Evenemanget är enormt mediebevakat, omtalat och välbesökt. Såväl nordiska som internationella orienterare samlas på denna plats för att springa i olika etapper med skiftande terräng och miljö. Tävlingarna är uppdelade i åldersgrupper vilket innebär att banorna som finns på etapperna är uppdelade i olika svårighetsgrader. För kontrollregistrering används en löparbricka (SPORTident) som stoppas in i en enhet vid varje kontroll. 2.3 OLA och Sportident För att hålla reda vilka kontroller löparna har varit på vid vilka tider används Sportident, ett system som använder RFID chip. Varje löpare har en Sportident-sticka som fästs på valfritt finger och kan stämplas i enheter som sitter vid de kontroller orienterarna letar efter. Data sparas i stickan och kan sedan läsas in i en dator vid målgången. Sportident har ett eget system för att hantera tävlingsdata men det är relativt begränsat. Därför har svenska orienteringsförbundet utvecklat en egen mjukvara som heter OLA. Det hanterar tävlingsdata och används för i princip all administration av tävlingen. 2.4 Etapper De olika etapperna under nästa O-Ringen event där tävlingen kommer att äga rum. Etapp 1, söndag 25 juli. Arena Kilsbergen, Mogetorp Etapp 2 och 3, 26-27/7. Arena Dovra Sjöar, Hallsberg Etapp 3 Elit, 27/7, kväll. Arena Stadsparken, Örebro Etapp 4, 29/7. Arena Kägleborg, Fellingsbro Lindesberg Etapp 5, fredag 30 juli. Arena Örebro Universitet, Örebro Sida 6

7 Teori 3 Teori 3.1 Services Active Directory AD (Active Directory) är Microsofts domäntjänst för Windows Server 2000 och framåt. Tjänsten kräver att Microsofts DNS tjänst, som stödjer dynamiska uppdateringar, finns installerad för att fungera korrekt. Tanken bakom AD är, förutom att hantera användare och datorer, att fungera som en auktoritet där applikationer och tjänster kan autentiseras mot en central punkt. Det centraliserade sättet att administrera domäner förenklar hanteringen av information om användare då man bara behöver ändra användardata på en plats istället för i flera olika applikationer. AD använder sig av kerberos för att på ett säkert sätt identifiera objekt i domänen. Protokollet låter användare och datorer bevisa sin identitet för att få rättighet till resurser på nätverket. Alla användare, skrivare, datorer etc. delas upp i en trädstruktur i olika mappar, så kallade Organizational Units. Med hjälp av GPO (Group Policy Object) tilldelar man varje grupp olika rättigheter som användarna kommer att få när de loggar in på en dator, till exempel hur de får använda datorn, vilka program som installeras eller vilka skrivare de får använda. För att användare ska kunna använda valfri dator i domänen stöds roaming profiles och hemkatolger sparade på domänkontrollanten. Roaming profiles och hemmakataloger innebär att användare kan logga in på vilken dator som helst i domänen med samma personliga inställningar och sparade filer. Det går att trycka ut program, drivrutiner, script och liknande via AD för att på så sätt kunna administrera datorerna i domänen centralt Nagios Nagios, som är baserat på öppen källkod, används till övervakning av IT-system, applikationer, operativsystem, nätverksprotokoll och tjänster. Administratörer varnas via tactical overview, eller sms när problem uppstår. I tactical overview finns alla tjänster sorterade efter status (pending, ok, unknown, warning och critical) för att ge en effektiv överblick i eventuella fel som uppstår. Nagios bygger till stor del på plugins som användare kan skriva själva i perl eller liknande scriptspråk. Det går att ladda ner plugins för att övervaka nästan vad som helst. Switchar och liknande övervakas via SNMP (Simple Network Management Protocol) men för att övervaka datorer används klienten NRPE (Nagios Remote Plugin Executor) som, när servern skickar en poll, exekverar ett eller flera plugins och returnerar resultatet. Pollintervallen kan skilja mellan olika tjänster. Övervakningsobjekt sorteras i en struktur där hostgroups innehåller hosts, och hosts har ett visst antal tjänster. Inställningar propageras nedåt så man skulle till exempel kunna skapa en hostgroup med kritiska servrar och sätta pollintervallen på denna till ett lågt värde. Hosts och tjänster kan även ärva inställningar från templates. Hostgroup Host Host Service Service Service Service Service Service Sida 7

8 3.1.3 Cacti teori Teori RRDTool är en mjukvara som används för att logga performance data och för att generera grafer. Cacti är en övervakningstjänst med ett webbinterface som hämtar data, till exempel via snmp, och sparar den i en MySQL databas. RRDTool används föra att generera grafer på den data som finns sparad i databasen. Cacti använder sig utav templates för att lägga till nya sorters grafer. På cactis officiella forum lägger många användare upp scripts och templates dem gjort själva MySQL MySQL är en gratis databashanterare som fungerar i Windows och Linux. Det som skiljer MySQL från exempelvis Microsoft SQL Server är att det finns flera olika databasmotorer där de två vanligaste är MyISAM och InnoDB. MyISAM används som standard och är också den mest använda bland annat på grund av sina höga läshastigheter. InnoDB har fler funktioner varav den mest betydelsefulla är att den stödjer transaktioner. SQL (Structured Query Language) är det språk med vilket en applikation kommunicerar med databasmotorn. Man kan med akronymen CRUD (create, read, update and delete) beskriva vilka funktioner en databasmotor skall ha. Dessa funktioner motsvaras i SQL av följande syntax: Create Read Update Delete INSERT SELECT UPDATE DELETE Replikering i MySQL innebär att man låter en databas spegla en annan. En server som replikerar har en roll som master eller slave beroende på vilken typ av replikering som utförs. Den enklaste formen av replikering är av typen Master-Slave vilket betyder att alla ändringar på den server som är master propageras till slave. Om Master-Master används går det att ändra i båda databaserna. Dessa replikeringstyper går att variera till komplicerade hierarkier. Man skulle till exempel låta en databas replikera till en annan som i sin tur replikerar till en tredje OLA och SPORTident OLA är den mjukvara, utvecklad av svenska orienteringsförbundet, som hanterar orienteringstävlingar. Mjukvaran är skriven i java. I installationspaketet för OLA ingår en klientversion och en serverversion. I mindre tävlingar går det att köra enbart klientversionen kopplad mot den interna databasen. I större sammanhang kopplas serverversionen mot OLAs interna eller en extern databas och klienter ansluter sedan mot OLA-server. Det går att starta OLAklienten via webstart vilket förenklar då klienten inte behöver installeras utan går att köra direkt från webbläsaren. Ola släpps i form av ett msi paket som installerar JRE(Java Runtime Enviroment) och en samling jar filer. Uppdateringar av ola släpps i form av zip paket med nya jar filer. Dessa ersätter de gamla när paketet extraheras i olas programkatalog. Det är smidigt att uppdatera ola under drift då man kan extrahera de nya filerna och starta upp den nya versionen av ola server. Sedan stoppar man den gamla versionen och startar den nya direkt efter. På detta sätt kan man uppdatera ola med ett minimalt driftstopp. Sida 8

9 Teori All tävlingsdata sparas i en databas där Microsoft SQL Server eller MySQL används som databashanterare. OLA kan använda sig av sin interna databas eller en extern databasserver. För tidtagning används SPORTident vilket går ut på att varje löpare har ett RFID-chip. Chipet behöver inget batteri, det får sin ström från basenheten den stämplas i. Basenheterna är mikrodatorer som med en induktiv koppling kan skriva tiden tillsammans med en kodsiffra för mellantidsplatsen till RFID-chipet. Löparbrickan kan alltså spara data. Basenheten sparar också data om vilka löparbrickor som stämplats. Det finns vanliga basenheter och masterenheter. Den senare går att ansluta till en dator DNS DNS (Domain Name System) är ett protokoll för att översätta domännamn till IP-adresser. Varje dator, server etc. har en IP-adress som det går att koppla ett namn till. Det går till exempel att skriva domännamnet i webbläsaren, vilket är mycket lättare att komma ihåg istället för IPadressen Ett domännamn är uppbyggt av delarna host, domän och toppdomän. Ett exempel med delarna i ordning är i det här fallet pekar hosten www till IP-adressen. Toppdomänen visar oftast vilket land servern är tänkt att befinna sig i, som.se,.no,.uk med mera, men det finns även generella som.com,.org,.net. Det kan även finnas underdomäner, till exempel detta gör ingen direkt skillnad i namnuppslagsprocessen förutom ett upprepat steg. Om en DNS server ska göra ett uppslag mot en zon den inte känner till så kommer den att fråga de så kallade rootservrarna. Det finns 13 stycken runt om i världen, det är dem alla DNS servrar bygger sin struktur på. Rootservrarna har fasta IP-adresser som aldrig ändras, dessa 13 adresser vet alla DNS-klienter om från början. DNS strukturen är hierarkiskt uppbyggd. Med dess rootzoon, toppdomäner och domäner innebär detta att en administratör kan skapa underdomäner i sin egen domän. Dessa kan även delegeras till en egen DNS-server om det behövs. Sida 9

10 Teori Bilden ovan illustrerar ett DNS uppslag i förenklad form. 1. Klienten börjar med att fråga den lokala DNS servern om den vet IP-adressen till Om någon klient tidigare frågat efter adressen så finns svaret sparat en viss tid för senare bruk, då kan DNS servern skicka svaret direkt tillbaka till klienten utan vidare förfrågningar. 2. Om så inte är fallet kommer den lokala DNS servern att fråga en slumpvald root-server, till exempel F.ROOT-SERVERS.NET, om IP-adressen till DNS-servern för.se. F.ROOT- SERVERS.NET svarar med en lista med adresser till.se. 3. Den lokala DNS servern frågar en slumpvald.se -server, till exempel J.NS.SE, om IPadressen till DNS-servern för oringen.se. J.NS.SE svarar med en lista med adresser till oringen.se. 4. Den lokala DNS servern frågar en slumpvald oringen.se. -server, till exempel gudrun.destinator.se, om IP-adressen till gudrun.destinator.se svarar med IP-adressen till vilket lagras i serverns DNS cache. 5. Den lokala DNS-servern svarar klienten med IP-adressen , vilket lagras temporärt i klientens DNS cache DHCP Nätverksprotokollet DHCP (Dynamic Host Configuration Protocol) är en standardiserad metod som ger möjlighet att tilldela IP-adresser dynamiskt och ge datorer nätverksinformation om till exempel Sida 10

11 Teori DNS-servrar och Gateway. DHCP jobbar så att en klient frågar efter konfiguration av en server, såkallad klient-server-relation. Processen med adresstilldelning automatiseras tack vare protokollet och minskar risken för IP-konflikter i nätverket. Då en klient kopplas in till ett nätverk och begär att få en IP-adress via DHCP, så måste begäran genomgå fyra olika steg för att nå sitt slutliga mål att få en IP-adress. DHCP discovery IP-förfrågningen börjar med att man skickar ett discovery-meddelande till broadcastadressen. Detta medför att alla DHCP-servrar i subnätet får reda på att klienten söker efter en IP-adress. DHCP offer Servern/servrarna skickar ett offer-meddelande tillbaka till klienten, innehållande ett IPadresserbjudande, subnätmasken, utlåningstid, IP-adressen till DHCP-servern samt MAC-adressen som klienten använde första gången för att skicka paketet. DHCP request Klienten kan få DHCP-erbjudanden från flera servrar, men kommer bara acceptera ett. Därefter skickas ett request-meddelande till broadcastadressen. Baserat på transaktions-id är övriga servrar informerade om vilket erbjudande klienten har accepterat. Klienten brukar generellt ta den DHCPserver som svarat snabbast. DHCP acknowledgment När klienten har valt DHCP-server, är nästa steg att skicka en bekräftelse, DHCP aknowlegment, innehållande information på utlåningstid, DNS-servrar och Gateway mm. När utlåningstiden tar slut så skickas på nytt ett request-meddelande till DHCP-servern och inte som innan till broadcastadressen. Efter det svarar DHCP-servern med att skicka en Acknowledgment innehållande ny utlåningstid. Om inte DHCP-servern svarar eller inte godtar den nya utlåningstiden eller dylikt, så testar den med att skicka ett nytt discovery-meddelande till broadcastadressen NTP Protokollet NTP (Network Time Protocol) arbetar på port 123/UDP och används för tidsynkronisering. NTP servrar använder en hierarki baserad på stratum. De allra pålitligaste enheterna har stratum 0 och består av atomklockor, GPS-klockor och radioklockor. Dessa är inte nätverksanslutna utan kopplas istället lokalt till servrar. De servar som är anslutna till en stratum 0 enhet blir stratum 1 i hierarkin. En NTP server som hämtar tid från en annan server som är stratum 1 blir stratum 2 och så vidare. En NTP tjänst konfigureras ofta för att arbeta mot flera andra servrar. Den hämtar tid från dessa i intervaller och sorterar dem i grupper efter vilka som anger samma tid. Ur den grupp som är tillförlitligast väljs en system peer med vilken tiden synkroniseras. 3.2 Core Site-to-Site VPN Site-to-Site VPN (Virtual Private Network) är en av flera VPN typer som finns att välja på. Just denna typ används ofta mellan till exempel två stycken geografiskt åtskilda kontor i ett företag som vill hålla en permanent kontakt mellan varandra som om de satt i samma LAN. Tekniken bygger på att två stycken enheter konfigureras på de olika platserna med exakt likadana autentiserings villkor. Detta eftersom att de måste kunna enas om vilka algoritmer som skall användas så att inget går fel under upprättandet av VPN-tunneln. Sida 11

12 Teori Fördelen med denna typ av VPN jämfört med en Mobile-VPN lösning är att tunneln alltid är uppkopplad även om den inte alltid är i aktivt läge. Efter en viss tids inaktivitet går tunneln i vila men återgår till aktivt läge när dataöverföring till fjärrnätverket initieras. Detta jämfört med att Mobile-VPN lösningen kräver att varje klient kopplar upp sig mot en VPN server för att komma åt fjärrnätverket. Med Site-to-Site VPN så får alla parter tillgång till fjärrnätverket om de ligger i det lokala nät som får gå igenom tunneln, det krävs alltså ingen interaktion från klienterna för att nå destinationsnätverket Brandvägg En brandvägg kan arbeta på olika lager i OSI (Open Systems Interconnection)-modellen. Den kan antingen arbeta tillståndslöst eller tillståndsfullt. Det senare är att föredra då brandväggen kan blockera allt förutom det som definieras utav regler. Detta gör att man får en bra överblick på vad som är tillåtet och inte tillåtet. Den tillståndsfulla brandväggen tittar på sessioner för att övervaka all trafik som passerar in och ut, paket skickar bara in till de klienter som uttryckligen har krävt svar från sitt mål. En tillståndslös brandvägg arbetar på det sättet att alla well-known-ports (dvs. port ) alltid är öppna för trafikflöde, detta innebär att onödigt mycket tillåts och man får inte en säkerhetsstruktur som är värd att sträva efter, vilket man uppnår med en tillståndsfull brandvägg Spanning-Tree Spanning-Tree är ett protokoll som återfinns i switchar, routrar och viss övrig nätverksutrustning. Protokollet är främst framtaget för att undvika lager 2 loopar. Detta medför även att man kan skapa redundans i nätet. Kopplar man upp flera redundanta länkar utan spanning-tree kommer det att bildas kraftiga lager 2 loopar som kommer att sänka berörda nätverksenheter. Alla nätverksenheter som är sammankopplade vid en uppstart tror att de själva är root-bryggan för Spanning-Tree domänen och börjar sedan skicka ut BPDU-paket till de andra parterna där de jämför sina MACaddresser och IP-addresser för att ta reda på vilken enhet som verkligen är root-bryggan för domänen. När root-bryggan har valts börjar alla enheter beräkna vilka portar som skall vara öppna för att inte orsaka loopar. De portar som är närmast root-bryggan kallas för root-portar. De portar som är aktiva är i ett s.k. Forwarding state och de portar som är inaktiva på grund utav Spanning-Tree är Blocked. De portar som är Blocked blir endast aktiva om en annan länk i nätverket går ned vilket orsakar att den enheten inte kan nås. Som standard på Cisco utrustning är Spanning-Tree påslaget för att förhindra lager 2 loopar vilket annars kan lamslå utrustning. Vad som uppstår vid en lager 2 loop är att nätverksenheten A inte förstår att det finns flera anslutningar till enhet B. Detta innebär att paket aviserade till enhet B går runt mellan enheterna A och B, efter varje runda tillkommer flera paket vilket tillslut gör att enheternas processorer går på max och tillslut fylls minnet så pass mycket att enheterna inte längre kan switcha trafik. Det finns olika typer av Spanning-Tree vilket både kan öka skyddet för länkbortfall såväl som att snabba upp initieringsprocessen av öppna länkar. Man bör för tillfället använda Rapid-PVST+ i en Spanning-Tree domän eftersom att den snabbare accepterar portar i ett Forwarding state vilket annars kan ta tid. Sida 12

13 3.3 Access Teori Power over Ethernet PoE (Power over Ethernet) är en teknik som används för att ge strömförsörjning till accessutrustning via nätverkskabeln. Normalt sett krävs att både switch och accessutrustning stöder PoE men det finns adaptrar både för att injicera ström på nätverkskabeln och för att dela upp en PoE anslutning i ström- och nätverkskablar. Fördelar med PoE är att kabeldragningen blir betydligt smidigare. Batteribackup för strömförsörjningen blir mer centraliserad och lättare att hantera WLAN WLAN (Wireless Local Area Network) är ett system för enheter att ansluta trådlöst till ett nätverk. Normalt sett ansluter enheterna till en accesspunkt som i sin tur är kopplad mot kabelnätverket. Det finns ett flertal tekniker man kan använda för att säkra en trådlös uppkoppling från åtkomst och insyn, så som WEP, WPA, WPA2 och VPN. Man kan även en Captive Portal, där användare på det trådlösa nätverket kan autentisera sig med individuella uppgifter via en webbläsare. Den absolut vanligaste standarden för trådlösa nätverk är IEEE med olika varianter VLAN VLAN (Virtual Local Area Network) är en teknik för att dela upp fysiska nätverk i flera virtuella delar. Uppdelningen görs i switchen/switcharna. Detta gör att trafiken skiljs mellan de virtuella nätverken och därmed minskar broadcasttrafiken och möjligheten att användare inte kommer åt nät de inte har behörighet till. De virtuella nätverken fungerar som fysiska nätverk och trafik mellan olika VLAN måste därför routas med en router eller lager 3 switch. När trafik kommer in på en viss port så taggas paketet med det VLAN-ID för det VLAN som porten tillhör. Mellan switchar har man vanligtvis en trunk. Flera VLAN kan gå i trunken, däribland flera taggade och endast ett otaggat. När den taggade trafiken ska ut till destinationen avtaggas den i den sista enheten som är VLAN medveten. Eftersom VLAN endast kan nå varandra genom routing kan man styra vilka nät som ska nå varandra. Vissa nät behöver man inte routa till alls, vilket gör att man endast når dem genom att koppla in sig på en fysisk port. VLAN hjälper till i det allmänna säkerhetsarbetet men räknas idag inte som 100 % säkert, det bör därför kompletteras med andra säkerhetslösningar Clonezilla Clonezilla är ett opensource program som konkurrerar med Norton Ghost men även Symantecs Ghost Corporate Edition med multicast. Imagefiler kan skapas antingen via nätverksboot eller genom att lokalt boota från tex ett USB-minne. Dessa kan senare återställas till en eller flera datorer. Clonezilla har stöd för både unicast och multicast vilket gör att många datorer kan ghostas sammtidigt utan speciellt stor ansträngning på utrustning. Sida 13

14 Planering och genomförande 4 Planering och genomförande 4.1 Ansvarsområden Ansvaret har delats upp på tre grupper: Coregruppren, vilken består av: Erik Berggren (JTH) Tim Olsson (JTH) Martin Andersson (JTH) Coregruppens uppgift är att designa, bygga och underhålla stamnätet för O-Ringen. Vidare ansvarar Coregruppen för att föra en dialog med berörda nätoperatörer om WAN-kopplingar och internetaccess. Accessgruppen, vilken består av: Henrik Johansson (JTH) Björn Lindén (även koordinator) (JTH) Henrik Hagstedt (JTH) Accessgruppens ansvarar för all kontakt med slutanvändare, samt alla switchar utanför core. Exempel på utrustning som accessgruppen ansvarar för är IP-Telefoni och WLAN. I nuvarande skede är dock accessgruppens tillgång till nödvändig information begränsad och större delen av deras uppgifter utförs i period 2. Servicegruppen, vilken består av: Niklas Strand (JTH) Björn Nygren (JTH) Henrik Pennanen (JTH) Servicegruppen ansvar är att tillhandahålla alla nätverkstjänster under evenemanget. De viktigaste tjänsterna under evenemanget är OLA och MySQL. Sida 14

15 4.2 Services Planering och genomförande Planering för servrar och dess användning under O-Ringen 2010 Oringenstaden Arena Primergy RX100 (Marge) Domänkontrollant DNS DHCP PRIMERGY RX100 (Easton) TFTP TACACS NAGIOS PRIMERGY RX300 (Booth) OLA MySQL backup Dell poweredge (Calles) ESXI COMPAQ DL380 (Moris) Domänkontrollant DNS DHCP Primergy RX 300 (Ward) MySQL OLA Dell poweredge (Butler) ESXI BROWER (MySQL) OLAORINGENSTADEN OLATAVLING BOUFF (MySQL) ORINGENONLINE Förklaring Tanken med planen är att skapa redundans till alla viktiga tjänster. Redundansen har spridits mellan oringenstaden och arena. Detta för att en minska påverkningen på drift om WAN länken bryts. Servrarna Calles(står i oringenstaden) och Butler(står på arena) kör ESXI, alltså körs servrar virtuellt på dessa. De blåa fälten visar vilka virtuella maskiner som körs på respektive fysisk maskin. De två MySQL servrarna som finns på arenan är tänkt att använda master-master replikering. Det är dock viktigt att vi bara tillåter skrivningar till den som är primär databasserver, med andra ord Bouff. Datan kommer replikeras till en server i oringenstaden, denna kommer replikera vidare till en backupserver och till oringenonline på jth. OLA finns utspritt på två fysiska maskiner på arenan. Då vi virtualiserar är det inga större problem med att kopiera maskiner om fler ola servrar skulle behövas. Sida 15

16 4.2.2 MySQL och OLA Planering och genomförande Tvåvägsreplikering Envägsreplikering Envägsreplikering Envägsreplikering MySQL MySQL MySQL MySQL MySQL OLA OLA OLA OLA O-Ringen Online Arena NOC JTH Replikering Koppling mot MySQL Failover Fyra databasservrar kommer att användas under O-Ringen Ute på vardera arena kommer två servrarna finnas. Ola jobbar mot den ena och den andra används som hot-standby, tvåvägsreplikering sker mellan dessa. Då MySQL inte kan låsa rader i databaser på en annan host finns risk för kollisioner och korrupt data om man tillåter skrivningar till två sevrar som replikerar till varandra. För att undvika risker kommer skrivningar bara tillåtas på den primära servern. För att undvika att någon råkar skriva till databasen som står i hot-standby (till exempel genom att peka om OLA till den) läggs raden 'read_only = 1' till i konfigurationsfilen. Det går att replikera till den server som är i read only läge men det går inte att skriva till den på annat sätt. Det kommer finnas två databasservrar i O-Ringenstaden för att ha redundans även där. Innan replikering startas skall följande finnas i konfigurationen: server-id = 1 #Alla MySQL instanser måste ha ett unikt id binlog-do-db=ola2010 #Namnet på den databas som skrivs till binärloggen. En databas måste vara med i binärloggen för att man ska kunna replikera. log-slave-updates=1 #Gör så att data en server får genom replikering skrivs till den lokala binärloggen så att slaven kan replikera till en annan server. Replikeringen startas med kommandot: CHANGE MASTER TO MASTER_HOST='', MASTER_USER='', MASTER_PASSWORD='', MASTER_PORT=3306, MASTER_LOG_FILE='', MASTER_LOG_POS='', MASTER_CONNECT_RETRY=10; 'MASTER_LOG_FILE' och 'MASTER_LOG_POS' ställs in till de värden man får genom att köra kommandot 'show master status' på masterservern. Innan man påbörjar replikeringen synkroniserar man databaserna genom att göra en databasdump på mastern och återställa den på slaven. Sida 16

17 Planering och genomförande För att automatisera backuper skrivs ett script som gör databasdumpar och sparar dem i komprimerat format. Samma script kan användas för att återställa dumpar. Den linuxbaserade schemaläggaren cron används för att göra backuper i 15 minuters intervaller. På eftermiddagarna under evenemanget kommer man vara tvungen att avlasta servrar på arena för att flytta dessa till en ny arena. För att växla aktiv server: 1. Stäng av olaservrar. 2. Kolla så att slav är synkroniserad med master 3. Sätt nuvarande aktiv server i read only (om inte MySQL tjänsten av någon anledning är ur bruk.) 4. Ta ut ny aktiv server ur read only läge. 5. Peka om OLA servrar till ny aktiv databasserver. 6. Starta OLA. Innan man börjar jobba mot en annan databasserver än den primära bör man kolla så att replikeringen är helt synkroniserad. Detta görs genom att köra kommandot "show master status" på master och "show slave status" på slaven. Replikeringen är fullt fungerande om Slave_IO_Running och Slave_SQL_Running står som yes. På slaven skall Relay_Master_Log_File och Exec_Master_Log_Pos stämma med den information man får ut av kommandot show master status på mastern AD (Active Directory) Då en fungerande domänkontrollant i oringen.local är nödvändig för att funktionärerna ska kunna logga in på datorer och använda OLA installeras två domänkontrollanter för redundans. Om båda servrarna står i oringenstaden kommer användare ute på arenan inte att kunna logga in om WANlänken slutar att fungera så för att minska beroendet av WAN-länken kommer den ena servern stå i oringenstaden och den andra på arenan. Båda domänkontrollanterna kör microsofts DNS tjänst. DNS Records, användare i AD och Group Policys replikas genom AD. Funktionärer ska använda skrivare som läggs till automatiskt via AD. Skrivarna delas ut till användare i domänen. Genom ett script läggs skrivaren till när användaren loggar in, den ställs sedan in som standardskrivare. När användaren loggar in skapas en genväg på skrivbordet, med hjälp utav ett script, till ett hostname som pekar på OLA server. Lastbalansering sker via round-robin i DNS servern. Alla funktionärer kommer, för enkelhetens skull, att logga in med samma konto. Det kommer att finnas en användare för varje organizatinal unit. De organzational units som finns är: Administrator OLA Administrator gruppen kommer att innehålla varsitt konto åt alla i O-Ringengruppen. Tävlande ska kunna kolla sina resultat på speciella ämnade datorer för detta. Internet Explorer startas automatiskt i kioskläge när användaren kiosk loggar in. Användaren stämplar sin Sida 17

18 Planering och genomförande löparbricka i en sportidentenhet och får upp sin personliga sida på O-Ringen Online. Man ska inte kunna göra något annat på dessa datorer än vad de är ämnade för. Gruppen OLA har policies satta som sluter ute funktioner som inte är relevanta för deras ändamål DHCP Windows DHCP tjänst används för dynamisk tilldelning av IP-adresser. Tjänsten körs på två olika servrar och delar ut olika scopes inom samma IP-nät. I VLANet "OLA-klient/skrivare arena" delar till exempel den ena servern ut adresserna och den andra För att det trådlösa nätverket skall kunna fungera måste DHCP servern dela ut speciella options på VLAN 120 (AP-management). Option 43 innehåller IP-adressen till WLC och option 60 innehåller modellnamn för accesspunkterna. Först lägger man till VCI (Vendor Class Indentifier) genom att, i mmc snap-in för DHCP, högerklicka på serverobjektet och välja Define Vendor Classes och trycka på add. Strängen som skall delas ut i option 43 är Cisco AP c1200. Sedan högerklickar man på serverobjektet och väljer Set Predefined Options. Man väljer option class Cisco AP och trycker på add. Option 43 läggs till i dialogen som öppnas. För att dela ut option 43 och option 60 väljer man rätt subnet, högerklickar på Scope Options och väljer Configure Options. Under fliken Advanced ställer man in VCI och IP-adress till WLC. Sida 18

19 4.2.5 Nagios Planering och genomförande I nagios har ett antal olika plugins testats för övervakning av nätverk och tjänster. På de flesta hosts övervakas belastning på processor, minne, uptime och diskutrymme (bara på servrar). På trunkar och wanlänk övervakas interfacestatus. Bandbreddsanvändning mot internet och ut till arenor övervakas och grafer genereras till dessa. På port 80 kommer http anrop att göras för att se om OLA server körs. På databaserna övervakas status för MySQL, om rätt databas finns tillgänglig, antal anslutna trådar och replikeringsstatus. På domänkontrollanterna körs ett plugin som genererar en varning om resultatet av DCDIAG visar några fel. Namnuppslag utförs regelbundet för att kolla status på DNS servrar. När något plugin genererar en varning syns detta i Nagios webinterface. En ljudsignal kommer att spelas och ett mail skickas ut om notifications är aktiverat för den tjänsten. Alla hosts är uppdelade i tre olika hostgroups: Windows Server, Linux Servers och Network. Det finns också service groups för all databasövervakning och för status/bandbredd på interface NTP De tidsresultat som sparas i OLA är inte beroende av att klienter eller OLA server är tidssynkroniserade. Dock är speakerstödet beroende av tidssynkronisering. Som tidsserver används linuxtjänsten NTPD. Tiden synkroniseras med NTP servrarna sunic.sunet.se, ntp1.chalmers.se, ntp1.uu.se. #Servrar att synkronisera med server sunic.sunet.se server ntp1.chalmers.se server ntp1.uu.se #Blockera all trafik som default restrict default ignore #Ge full access till localhost och de ntpservrar man synkroniserar med restrict restrict Sida 19

20 Planering och genomförande restrict restrict #Tillåt klienter att fråga om tid restrict mask nomodify notrap nopeer #Använd lokal tid om internetanslutningen tappas representerar den lokala klockan server fudge stratum 10 Den lokala klockan representeras av IP-adress Servern får stratum 10 vilket innebär att de andra servrarna kommer att prioriteras (då de har lägre stratum). Men på grund kommandot fudge används den servern ändå. 4.3 Core VLAN Denna tabell listar de VLAN som kommer att finnas i nätet. Flertalet är lokala VLAN som endast kommer att existera på utvalda enheter, medans vissa VLAN är End-to-End och kommer att existera över allt. T.ex. så är Management VLANet ett End-to-End VLAN. Vlan-ID Beskrivning IP-nät DHCP-scope 1 DHCP-scope 2 10 Management /16 20 Publik inet access / / /23 30 Press inet access / / /23 40 IP-telefoni / / /24 50 Sjukvård/Handlarn / / /24 60 Tech inet access / / /24 70 OLA-klient/skrivare arena / / /24 80 Servrar arena /16 90 OLA-klient/skrivare city / / / Servrar city / Mässa / / / AP-management / / / Externt WAN Från ISP 140 Internt länknät /16 De VLAN som inte har några DHCP-scopes är nät som inte ska DHCP-funktionalitet Routing Core-switchen i nätverket, O-NOC-C, kan routa mellan alla interna subnät, och är default gateway för flertalet av dem. Undantaget är VLAN 70 och 80 som routas, och har default gateway på O- ARENA-D. Anledningen att dessa routas på arenan är att trafiken mellan OLA-klienter och OLAservrar på arenan inte ska behöva gå igenom O-ringenstaden, då detta belastar WAN-länkarna i onödan. Routingprotokollet EIGRP körs mellan brandväggen O-NOC-FW och Core switchen O-NOC-C, detta för att se till så att alla IP-subnät är uppdaterade i realtid för att undvika routingproblem. Sida 20

21 Planering och genomförande Grundkonfiguration för Nätverksutrustning För att underlätta konfiguration utav ny nätverksutrustning så utvecklades en mall (Se Bilaga 1) som är tänkt att implementeras på all ny utrustning i den utsträckning som det behövs. T.ex. så definerar mallen vilken vtp domän som skall användas, vilka VLAN som DHCP Snooping skall vara aktivt för osv. Detta samt att tjänster som kan utgöra säkerhetsrisker stängs av, t.ex. den inbyggda http servern Core-nät De enheterna som utgör stamnätet är O-NOC-FW (brandvägg), O-NOC-C (Core-switch), O-NOC- D (Distibutrions-switch) och O-ARENA-D (Distibutrions-switch). De tre förstnämnda enheter kommer att vara placerade på Navets skola i Örebro där de kommer att sköta den slutgiltiga funktionaliteten i nätverket. ARENA-D kommer att vara placerad på Arenan under drift. Internet är tänkt att termineras in på Core-switchen i form utav en fiber anslutning. Logiskt sett så är Internet inkopplat till brandväggen men inte fysiskt därför att den inte har någon fiberanslutning. Core-switchen switchar all sin trafik uppemot brandväggen där sedan funktioner som paketinspektion och NAT sker. Allt detta sköts genom att olika VLAN termineras på de olika portarna för att skapa detta trafikflöde. Två stycken portar på O-NOC-C är i samma VLAN (VLAN 130), en utav portarna är inkommande för fiberanslutningen ifrån ISP och den andra porten går till brandväggens inkommande interface. VLAN140 knyts till brandväggens utgående interface som sedan switchas in till O-NOC-C. Routingtabell på O-NOC-C får tilldelad en default route mot brandväggen (VLAN 140). VLAN140 VLAN130 O-NOC-FW VLAN130 WAN O-NOC-C Säkerhetslösningar Coregruppen har funderat över olika säkerhetslösningar och vilken slags funktionalitet som ska finnas mellan de geografiskt åtskilda platserna. Bland annat vill Servicegruppen kunna replikera trafik till servrar på JTH. Därför togs beslutet att implementera en fast Site-to-Site VPN mellan NOC och JTH samt en tunnel mellan NOC och Arena, i det fall då Ice.Net modem används. Totalt så används tre stycken Cisco ASA 5510 brandväggsenheter under O-Ringen, två är alltid i drift och den tredje på arenan används endast om Ice.Net modemet behöver användas. Dessa enheter skall i första hand användas för att terminera Site-to-Site VPN tunnlar, men kommer också användas för paket inspektion/restriktion samt NAT. Sida 21

22 Planering och genomförande Tunnlarna använder sig utav IPSec protokollet med AES256 kryptering och MD5 som hash. Detta anses för närvarande som säkert för att kunna tunnla känslig information över internet med vetskapen om att trafiken är skyddad från insyn av en tredje part. Vid skarp drift så skall en extra Cisco ASA 5510 finnas att tillgås. Den ska i första hand användas i NOC eftersom att det är kritiskt att brandväggen alltid är uppe och aktiv på denna punkt. Detta eftersom att all trafik som skall ut på Internet i någon form kommer att passera genom den. Och om den skulle fallera så skulle nätverket i princip stanna upp externt. Brandväggarna kommer att övervakas genom Nagios VPN ARENA NOC VPN JTH Cisco CallManager Express O-Ringen gruppen hade lagt fram som önskemål att ha ett lätt och smidigt sätt att kontakta ansvariga på de olika Arenorna samt NOC, utan att använda sig utav mobiltelefoner och liknande. Lösningen var att implementera IP-telefoni. Cisco CallManager Express (CME) är en mjukvara som körs på en Cisco Router. Den fungerar som en databas för telefonerna vad det gäller grundinställningar och kontaktinformation, som en sambandscentral för telefonerna som är beroende av att CME Routern alltid är funktionell och tillgänglig. En Cisco 2811 Router monterades och en ny IOS (mjukvaran i ciscos routrar och switchar) som i huvudsak endast hanterar IP-telefoni installerades och konfigurerades. Telefonerna som används är Cisco Dessa telefoner är helt beroende av att CME Routern fungerar. I princip så vet telefonerna ingenting utan de hämtar all information från CMEn. Telefonerna är helt inkompetenta att ta sina egna beslut. När en användare t.ex. lyfter på telefonluren på telefonen så skickar telefonen en signal till CME routern om vad den ska göra när luren lyfts, den kommer då att få instruktioner om att skicka en tonsignal till luren. Detta gör den med alla funktioner och knappar som slås till. När ett samtal skall upprättas mellan två parter så knyter CMEn samman dessa två parter till dess att sessionen är upprättad och de båda parterna pratar. Sedan så går samtalen direkt mellan de switchar där telefonerna är inkopplade, utan att CME routern hanterar något. Sida 22

23 Planering och genomförande Telefonerna får sin strömmatning via en Ethernet kabel, denna kabel måste sedan anslutas till en switch som klarar av att mata ut ström på en Ethernet port, en såkallad PoE switch (Power over Ethernet). Telefonerna kan även få ström från en extern strömadapter, sådana adaptrar fanns dock inte tillgängliga Remote Access VPN En funktion som efterfrågades utav Core-gruppen var ett sätt att komma åt nätverket utifrån. Detta vid att man skulle vilja göra fjärrändringar från en annan fysisk plats, t.ex. hemma eller helt enkelt övervaka systemen. För denna lösning så monterades en Cisco 2621 router och konfigurerades för att uppnå resultatet som krävdes. I dagsläget så har alla operativsystem någon form utav en inbyggd VPN klient vilket innebar att ingen speciell mjukvara skulle behöva tillhandahållas för de som vill använda tunneln. Routern har inbyggt stöd för att agera som en Remote Access VPN (MobileVPN) server eftersom att detta är inbyggd i dess programvara. Ett virtuellt interface skapas på routern som sedan får en IP-address i subnätet som skall tunnlas. I det här fallet fick interfacet ip-addressen /16 vilket är en adress i vårat Tech-nät. När en användare sedan ansluter emot routerns WAN interface så skapas det virtuella mallar utav det virtuella interfacet. Varje virtuell mall som är upprättad får sedan en ip-address tilldelad från en lokal ip-scope som defineras på VPN-routern, det går även att dela ut ip-adresser genom en DHCP server. När tunneln är upprättad så får användaren en IP-address från scopet /16 utdelat från VPN-routern. Efter detta så kommer användaren åt hela /8 nätet vilket innebär att alla enheter kan nås tunnlat över internet. I dagsläget så räknas VPN som tillräckligt säkert för att knuta ihop flera lokala nätverk över internet eller för att i det här fallet tillåta fjärranvändare att komma åt ett lokalt nätverk över internet. VPN-Router Internet / / /8 User1 User2 User Private VLANs Team Sportia begärde direktåtkomst till internet och egen publik IP-adress. Core-gruppen ansåg då att det skulle vara bäst att placera dem utanför O-ringens nät och placerade dem därför i VLAN 130 som logiskt sett existerar utanför O-Ringennätet. Efter detta fanns tre hosts i VLAN 130: O-ringens front mot internet, i form av en Cisco ASA 5510 En Mobile VPN gateway, i form av en Cisco 2621 router Team Sportia Sida 23

24 Planering och genomförande Det ansågs onödigt att dessa parter hade lokal kontakt med varandra, därför beslutades det att införa Private VLANs. Alla tre parter placerades i isolerade portar och porten mot internet konfigurerades som promiscuous, detta resulterade i att inga parter kunde nå varandra, utan endast porten som konfigurerats som promiscuous. Det resulterar också i att Team Sportia kan kopplas in på valfritt ställe i O-ringens nät (dock endast i 3560, 2960 har inte stöd för private VLANs), och ändå vara (logiskt sett) utanför nätet Wan länkar Fiberoptik är den typen av WAN-länk som är snabbast och har bättre upphastighet än ADSL. Fiberkablar kan även vara många kilometrar långa. Ofta är fiberkablar indraget till en switch i källaren på hus och därifrån används vanliga tp-kablar. Fiber: Har i princip en ypperlig svarstid Väldigt bra hastighet upp och ner ADSL är en teknik som används för att skicka mycket datatrafik över telefonledningar av koppar. ADSL har asynkron hastighet vilket betyder att överföringshastigheten är olika beroende på vilken riktning datan skickas. ADSL har sämre upphastighet än nerhastighet, detta är ett problem om ADSL används till en server som skickar mycket data från sig. ADSL måste vara förhållandevis nära telestationer, även bra kvalitet på kopparkabeln behövs. ADSL: Har en dålig upphastighet men ganska bra nerhastighet Godkända svarstider NET 1/Ice.net hette tidigare Nordisk Mobiltelefon och använder samma frekvenser som gamla NMT mobiltelefonnätet till mobilt internet. Företagets affärside är att erbjuda mobilt bredband som fungerar även ute i ingenstans. NET 1/Ice.net: Har dålig stabilitet vid hög belastning Ger sämre svarstider än andra alternativ Går att koppla upp i princip vartsomhelst Sida 24

25 4.4 Access Planering och genomförande Trådlöst nätverk Det planerades för trådlös access i pressavdelning i oringenstaden samt på arenan, 1 accesspunkt per plats. Här kommer pressen kunna ansluta till ett WPA2 skyddat SSID, där ett och samma lösenord används för alla. Det beslutades att Captive Portal var onödigt då samtliga användare har samma rättigheter. På så sätt minskas komplexiteten, det blir lättare att felsöka och man får en punkt mindre som kan brista. På internetcafét planerades 2 accesspunkter ge gratis internettillgång till deltagare och besökare. Här tilläts endast vanlig webbtrafik så som port 80 och 443. En annan plats som krävde trådlös access var mässan, här placerades ytterligare 2 accesspunkter med ett SSID för personalen på mässan. Samtliga trådlösa accesspunkter har ett "tech SSID" för teknikerna. Alla accesspunkter konfigureras och administreras via en Cisco Wireless Lan Controller (WLC) IP-Telefoner IP-Telefoner behöver endast placeras i rätt vlan och får sedan alla inställningar via Call Managern (CME). Alla telefoner konfigureras med ett visst telefonnummer via CME. Telefonerna kommer endast användas av tekniker för att kommunicera mellan olika platser utan att behöva använda mobiltelefoner Switchar Switcharna i accesslagret hålls så standardiserade so möjligt, det vill säga att man försöker ha så få olika konfigurationer som möjligt. Port 23,24 samt båda gigabitportarna konfigureras för trunklänkar. På switchar med Power over Ethernet (PoE) konfigureras Port 21 och 22 för trådlösa accesspunkter. På dessa switchar konfigureras även en port för IP telefoner. Switchar utan PoE saknar IP telefonportar och accesspunktportar, här finns istället vanliga accessportar nu. Portar som inte för närvarande används men är konfigurerade för något annat än accessport pluggas med en tom RJ-45 kontakt för att undvika att någon kopplar in utrustning i fel port. På detta sätt uppnås ett för användarna mindre komplext och svåranvänt system. Detta är något som önskats från O-Ringen. Användaren kan helt enkelt enkelt plugga in datorn i en ledig accessport i den switch där han sitter och hamnar i det vlan han bör vara i, utan att behöva kontakta någon tekniker. Alla lediga, oblockerade portar skall gå att använda för användaren. Sida 25

26 4.5 Närkekvartetten Planering och genomförande För att testa utrustning och få bättre insyn i hur en orienteringstävling fungerar besökte O-Ringen-gruppen tävlingen Närkekvartetten. Där ansvarade gruppen för drift av nätverk och servrar i fyra dagar. Närkekvartetten är en förhållandevis stor tävling med ca 1500 deltagare per dag. O-Ringen är dock en mycket större tävling med deltagare. Tävlingsarenan var i Kinkhyttan, ca 20 minuter från örebro. Utrustningsmässigt hade gruppen med sig utrustning motsvarande utrustningen för en arena under O-Ringen. En Cisco 3560 switch stod i speakervagnen och hanterade all routing. En ASA 5510 användes som brandvägg samt endpoint för en site-to-site VPN-tunnel till JTH. För internet access användes ett icenetmodem. Under den första dagen testades replikering över VPN-tunneln felfritt. I speakervagnen satt även en wlc och en trådlös accesspunkt. Det trådlösa nätet användes enbart av O-Ringengruppen och tävlingsledare. Bredvid speakervagnen stod ett tält där all tävlingsadministrativ personal arbetade. I detta tält placerades två Cisco 2960 switchar och 7 bärbara datorer för OLA-administration. Nätverket fungerade utan problem förutom en kortvarigt incident under dag 3 då inga IP-adresser tilldelades dynamiskt då DHCP servern hade kopplats in i en port som inte var trusted i DHCP snooping. Under tävling användes 2 redundanta databaser samt 2 stycken OLA-servrar kopplade mot en av dessa. Den andra användes som backup. Driften av OLA gick i stor sett smidigt under hela tävlingen bortsett från en miss under dag två. I slutet av dagen innan exporterades databasen och importerade på en bärbar dator. Detta för att administrativ personal behövde utföra efterarbete under kvällen. Servicegruppen hade inte innan laborerat med att föra över en databas från MySQL till OLAs interna databas och sedan föra tillbaka den. Därför råkade man återställa en gammal databas till den externa databasservern. Man tog då beslutet att under dag 2 köra på OLAs interna databas för att kunna komma igång innan tävlingen startade. Strax efter detta så löstes problemet med att återställa dumpen till den externa databasen, dock så fortsattes den interna databasen att användas för att undvika nertid. De två sista dagarna blev det ett antal strömavbrott på arenan. Pågrund av bristande UPS-kapacitet ledde detta till driftstopp efter ungefär 5 minuter utan el. Driftstoppen varade omkring 10 minuter efter återställd elförsörjning. Under högtryck när många löpare går i mål innebär ett sådant driftstopp löpare i kö, vilket inte är acceptabelt. Under högtryck på O-Ringen innebär ett driftstopp på 10 minuter löpare i kö, vilket leder till stora administrativa problem. Detta medför att fungerande UPSer är en av de viktigaste punkterna för en avbrottsfri drift under O- Ringen. Generella lärdomar av Närkekvartetten är att det är viktigt att ha bra ordning på utrustning och märka upp den ordentligt. Det är även nödvändigt att ha bra rutiner så att tiden används effektivt. Konfiguration av nätverksutrustning bör standardiseras för att samma switch skall kunna användas i de flesta situationer. Kompetens inom vissa områden bör spridas jämnare inom gruppen. Sida 26

27 Planering och genomförande Ghostning Samtliga klientdatorer under O-Ringen lånades av Örebro kommun och de flesta var laptops. Det planerades för 3 olika modeller. Dessa installerades med XP, även den licensen lånad från Örebro Kommun. Samtliga drivrutiner och program som i fanns med på kravlistan från O-Ringen installerades och sedan skapades image-filer för ghostning med programmet Clonezilla. USBminnen med imagefiler och clonezilla förbereddes för att vara lätt till hands. Vissa skrivardrivrutiner var ej bestämda vid tiden för ghostningen och fick skjutas ut i ett senare skede. Samtliga datorer blev tilldelade ett nummer ur en nummerserie som angavs som hostname och markerades med ett klistermärke. Detta användes för att kvittera ut datorer till funktionärer etc. Lista över program och drivrutiner varje dator var utrustad med: Open Office Drivrutiner för USB-Serieportsadapter (möjligen flera olika) Drivrutiner för SportIdent USB-master Drivrutiner för skrivare Mozilla Firefox Foxit Reader F-Secure Internet Security Putty Java Runtime Environment Drivrutiner för modellen i fråga Sida 27

28 Resultat 5 Resultat 5.1 Services Ola och MySQL Under O-Ringen användes fyra databasservrar. En primär och en backup ute på arenan där tävlingen ägde rum och samma setup i O-Ringenstaden. Det fanns, från början, också två ola servrar på varje plats. På dagen när det var mest aktivitet kring ola ute på arenan jobbade olaservrar mot databasen där. När tävlingsdagen var slut flyttades driften av ola och MySQL till O-Ringenstaden där sekritäriatet började jobba med att, till exempel, skriva ut resultatlistor. En manual skrevs för att ompekning av replikering och ola servrar skulle ske så säkert och med så lite nertid som möjligt. Manualen finns som en bilaga till rapporten. Ett shellscript kördes var femte minut på en linuxserver för att ta backup på databasen. Den första dagen uppstod en del problem med att ola gick ganska långsamt för användarna. Då databasserver var ganska hårt belastad antogs det vara problemet. Databasservern var virtuell och hade en tilldelad kärna. Till dag 2 tilldelades servern 3 kärnor men problemen fanns kvar. Man märkte då att det bara gick segt för klienter som jobbade mot den ena ola servern. I loggen för den servern fann det felmeddelanden som hade att göra med hur ola jobbar mot MySQL. Efter en diskussion med Henrik Bengtsson (programmerare som fanns på plats under hela tävlingen) släpptes en ny version av ola som installerades. Under resten av dagen och under hela etappen flöt ola på bra. Resterande två etapper uppstod en del problem med att användare som jobbade mot den virtuella ola servern upplevde en seghet i systemet. Detta utan att servern på något sätt var överbelastad eller att ola genererade några felmeddelanden i loggen. De användare som tyckte det gick för segt fick hjälp med att starta klienten ifrån den andra servern som användes på arenan. En tredje ola server startades på ytterligare än virtuell maskin. Denna användes till grafiken som gick på storbildsmonitorn. Det var viktigt att grafiken fungerade bra eftersom tusentals människor skulle se på den Ad resultat I AD fanns det fyra användare: ola Kontot hade genvägar till alla ola-servrar på skrivbordet. Det var även tillagt som lokal administratör för att det skulle gå att installera skrivare och ola-klienten om det skulle behövas. funk Användes av funktionärer. Kontot hade inga administatörsrättigheter. kiosk Kontot användes för resultatdatorerna på arenan. Efter att ha loggat in med kontot kunde oringenonline startas i helskärmsläge. massa - Som kiosk fast för mässan i oringenstaden. Sida 28

29 5.1.3 Övervakning Resultat Under O-Ringen skapades tre nya hostsgroups för att övervaka nätverket: Core-Network, Arena- Access och City-Access. I Core-Network övervakades de viktigaste nätverksenheterna: O-NOC-C O-NOC-FW O-ARENA-D O-ARENA-FW O-ARENA-TELIA O-JTH-FW Utöver det fanns default gateway, en publik host (google) och en d-link som övervakades för att man skulle märka om strömmen försvann till adsl-modemen och O-ARENA-TELIA (läs stycke telia-lådan ). I accessgrupperna övervakades accesswitchar och WLCs. Totalt sett övervakades 44 hosts. För att generera grafer på bandbreddsanvändningen användes cacti. Det lades även till en template i cacti för övervakning av mysql tjänsten. Sida 29

30 Resultat En egentillverkad applikation användes för att dra uppmärksamhet till sig ifall något inträffade på nätverket. Blixtljus och varningsljud i kombination med blinkande varningsmeddelanden gjorde att man slapp övervaka statusen aktivt vid en dator. Sida 30

31 5.1.4 OringenOnline Resultat Under tävlingen presenterades resultaten med hemsidan OringenOnline. Erfarenheter från tidigare år har visat att OringenOnline är hårt belastad under tävlingen. På JTH finns kraftfulla servrar samt en bra internetkapacitet, därför stod webservern i JTH precis som under Oringen Tävlingsdatabasen replikerades till skolan genom en VPN tunnel från oringenstaden. Sida 31

32 Resultat Domännamnet pekade på servern på JTH medans pekade på oringens webbserver. Detta för att det inte gick att få tag på personen som skötte om webbhotellet där oringen har sin.se domän. Lösningen fick bli att peka om länkarna i filen default.htm på oringens server så att de pekade på JTH servern. Alltså drog servern på JTH all trafik förutom den som gick åt att ladda ner index sidan när användarna surfade till På sidan finns det en funktion för liveresultat(/ola/ajax.aspx) och en funktion där användaren kan skapa en egen personlig sida(/ola/mypage.aspx). Live-resultaten drog överlägset mest besökare. Sida 32

33 Resultat Bandbreddsgrafer I oringenstaden finns tyvär inga grafer på internetanvändning då snmp-övervakningen krånglade på just O-NOC-C. På arenan ses internetanvändningen i grafen O-ARENA-FW - Traffic - WAN. WLC'n på arenan hade inte snmp aktiverat, därför finns inga grafer från O-ARENA-WLC. I oringenstaden övervakades det interface på O-NOC-WLC som var kopplat till O-NOC-C. All trafik, både till och från de trådlösa näten, går in och ut på detta interface. Det finns bandbreddsgrafer för upplänkar på några viktiga access-switchar i staden: Sida 33

34 Resultat Över VPN tunnlar (O-JTH-FW Traffic wan och O-ARENA-FW Traffic - VPN) gick OLA trafik och replikeringar. Det gick också en liten mängd övervakningstrafik samt en del filöverföringar utförda av it-gruppen (kan synas som spikar i graferna). Sida 34

35 Resultat På etapp 5 användes stadsnät (eftersom vi då kunde få en trunk användes ingen brandvägg) så där mäts all trafik till/från arenan i grafen O-ARENA-D - Traffic - Gi0/2. Mer detaljerade grafer finns som bilaga till rapporten. Sida 35

36 Resultat Invigningen/stafetten på Stortorget Till stafetten på stortorget användes en windowsserver som körde OLA, MySQL och DHCP. Tävlingen var inte en etapp i oringen och hade därför en egen tävlingsdatabas. Som backup server användes en av kommunens bärbara datorer med mysql och OLA installerat. Servern och en switch var kopplade till en UPS. Strömmen tillhandahölls från ett elskåp vid kommunhuset. Från kommunhuset som låg tvärs över torget, drogs en 50-60m lång TP-kabel in i tältet. Jacket där kabeln var inkopplad var en trunk där vi kunde komma åt de vlan som fanns i nätet. Strömmen dog vid ett tillfälle, då själva invigningen var slut. Troligen var det någon som dragit isär elkablaget. Servern och switchen gick på UPS:en så i stort sett hände ingenting förutom att skrivarna dog, de bärbara datorerna vi hade hade redan tagits ned. 5.2 Core Nätverket I Navets skola där Core-utrustningen stod placerad så terminerades VLAN400 ifrån stadsnätet via en ett inkommande fiberpar. VLAN400 var internet access via ISPn Blixtvik, medans resterande VLAN var för O-Ringens nät. VLAN terminerades via ett annat inkommande fiberpar som fungerade som trunk. Alla VLANen gick genom två fiberkonverterare, dessa i sin tur kopplades in i en av skolans switchar som ägs av Örebro kommun. Från skolans switchar begärdes sedan trunkar med vlan ut till O-NOC-C, samt alla accesswitchar i Navets skola. För slutgiltig disposition av Arenorna samt O-Ringenstaden se bilaga VTP För lättare VLAN konfiguration av access-switchar så användes VTP, detta fungerade dock inte optimalt i Navets skola därför att skolans switchar inte var med i VTP-domänen ORINGEN. Eftersom VTP inte kunde användas över skolans trunkar ledde detta till att alla VLANen lades till lokalt på varje switch. Ett missöde skedde när switchen O-ARENA-D kopplades in genom en trunk till O-NOC-C för att simulera stadsnätet, O-ARENA-D skrev då över VLAN tabellen på O-NOC-C, detta gjorde att stora delar av nätet slutade fungera. Detta inträffade sent på kvällen vilket innebar att driftkritisk trafik inte påverkades märkbart. Denna incident gjorde att VTP avaktiverades på alla switchar för att undvika framtida missöden och eftersom det ändå inte fungerade tillfredställande Site to Site VPN Under uppbyggnaden på Etapp 2 så upptäckte Core-gruppen problem med VPN tunneln mellan Arenan och O-Ringenstaden. Site to Site tunneln gick upp, men ingenting gick att pinga över den. Problemet berodde på att brandväggsansvarige i Core-gruppen skapat VPN profiler för alla Arenor i förväg på ASAn i O-Ringenstaden där tunnlarna skulle termineras. Detta ledde till att ASAn försökte sätta upp VPN tunnlar mot alla profilerna, även fast medparten inte var aktiva. Detta resulterade i ett mystiskt felmeddelande, IKE Negotiator Mismatch. Problemet löstes genom att enbart ha profiler för aktiva tunnlar. På Etapp 4 så blandades IP-addresser ihop på de olika ASorna på grund av misstag från Coregruppen. Detta ledde till att tunneln aldrig gick upp, problemet löstes efter en stunds felsökning när Core-gruppen insett sitt misstag. Sida 36

37 Resultat Duplex Mismatch hos Stadsnätet Under de första dagarna så testades hastigheten på internetlänken, TCP-värdena var långt ifrån godkända. Det visade sig att någon port i stadsnätet hade hårdställda duplexinställningar. Detta gjorde så att duplex-förhandlingen misslyckades och länken ställdes i halv duplex. Under elitetappen i stadsparken uppkom samma problem, även här hade stadsnätet problem med sina duplexinställningar Omdesign av ip-nät Under planeringsstadiet var det meningen att alla arenor skulle vara i samma LAN (Stadsnät/Svartfiber). Problemen uppkom då fiber inte fanns tillgängligt på fyra av etapperna. På dessa arenor användes ADSL-modem, vilket innebar att VPN-tunnlar blev nödvändigt. Coregruppen trodde sig ha en fungerande lösning där /8 var både Local och Remote på tunneln. Vid slutgiltig testning i Örebro fungerade dock inte denna lösning, problemet ringades in till att ha samma ip-nät på båda sidor utav en tunnel. Detta ledde till en förändring av ip-näten, ip-näten i O- Ringenstaden förblev oförändrade medans nya ip-nät skapades för arenan. För att ha en viss logisk koppling till näten i O-Ringenstaden så användes följande uppdelning: Funktion O-ringenstaden Arena Management / /16 Tech / / Avsaknad av VLAN på switchar Flera gånger ute på arenorna orsakades problem av att VLAN saknades på switchar. Detta ledde till att klienter inkopplade på en specifik switch inte fick nätaccess, därför att VLANet inte fanns på en switch på väg till O-ARENA-D. När man lägger till ett VLAN på en switch så tillåts den per automatik på trunk-länkarna som går till andra switchar, det är detta som bestämmer om trafik med viss VLAN-taggning få gå över trunken. Om inte VLANet får gå över trunken så stannar trafiken på den switchen där VLANet saknas. Lösningen var således att lägga till alla VLAN på alla switchar ute på arenan. Detta var nödvändigt eftersom nätverks-strukturen såg olika ut från dag till dag. Eftersom VTP tidigare hade orsakat problem så var det avstängt på alla switchar Telia-lådan På Etapp 1 till 4 tillhandahölls dubbla ADSL anslutningar från Telia. En anslutning för Internetaccess och en för VPN till O-Ringenstaden. Då telestationen på flertalet av arenorna låg ett antal kilometer bort så placerades en försluten låda nära telestationen. Från denna så drogs fiber till arenan. Det klipptes ut ett underliggande hål där elkablar och fiber infördes och ett hål för ventilation. I lådan placerades 1st 3560 och 2st ADSL modem. Utrustningen behövde UPS, då strömförsörjningen kunde vara något bristfällig. Då ingen övervakningsbar UPS fanns att tillgå så placerades en D-Link 604 router i lådan, utan UPS strömförsörjning. Syftet med D-Linken var att pinga den och märka spänningsbortfall. Vid spänningsbortfall så kördes 3560n och ADSLmodemen på UPS kraft medans D-Linken slutade svara på ping. Pingen till D-Linken övervakades i Nagios. Sida 37

38 5.3 Access Resultat Trådlöst nätverk WLC problem Vid sista etappen associerade inte accesspunkten till den lokala WLC:n på arenan längre, utan gick så småningom över till WLC:n i O-Ringenstaden. Då stadsnätet användes som wanlänk på denna arena fanns ingen lokal internetuppkopling. Detta innebar att det inte var något större problem att accesspunkten var associerad med O-Ringenstaden, därför lades felsökningen ner. Under hela O- ringen har det varit problem att komma åt WLCn från vissa VLAN i trådbundna nät, ingen lösning till detta problem uppkom WLAN-problem i O-Ringenstaden Det var tänkt att personal i O-Ringenstadens Kanslidel skulle använda det trådlösa nätverket som sattes upp. Problem uppkom då flera trådlösa nätverk sattes upp i de närbelägna bostadsområdena. Då WLANet fungerade dåligt så användes trådbundet nät. Pressfolket som befann sig en våning ovanför Kansliet hade inga som helst problem med WLANet, även fast det var samma Accesspunkt. Förklaringen till detta kan vara att det var fri sikt till Accesspunkten i Pressrummet IP-telefoni mellan Arena och O-Ringenstaden För snabb och smidig kommunikation mellan O-Ringenstaden och Arenorna så användes IPtelefoni. Själva telefonin funkade utmärkt, samtalen var nästintill i realtid jämfört med mobiltelefoni. Samtalen var främst påpekanden när någonting i Nagios hade larmat samt upplysningar om när t.ex. en Arena stängdes för dagen Switchar Switcharna konfigurerades inte riktigt som planerat. Istället för att förkonfigurera portar för IPtelefoni och accesspunkter konfigurerades alla 100mb portar som access-portar och gigabitportarna till trunkar. Sedan konfigurerades portar på plats om det behövdes. Eftersom IP-telefoner och accesspunkter bara fanns på ett fåtal platser var det onödigt att det fanns portar för dessa på alla access-switchar, dessutom minskades risken för att användare skulle koppla in sig på fel port. På vissa platser hade det inte funnits plats för alla klientdatorer om switcharna konfigurerats som planerat Ghostning En grupp om 5 personer färdades till Navets skola i Örebro där samtliga datorer förvarades. Här ghostades alla datorer genom att multicasta image:en till ca 20 datorer åt gången. Servern kördes på Tim Olssons privata laptop, vilket fungerade alldeles utmärkt. Dock upptäcktes vid ankomst att det var flera modeller av datorer än tidigare indikerat, vilket krävde improvisering från gruppen. Totalt ghostades ca 220 datorer. Det fanns även 3 olika lösenord för BIOS som krävdes för att aktivera PXE-boot på datorerna. Dessa lösenord behövde gruppen forska fram genom samtal till olika vaktmästare och IT personal på skolor i Örebro. Sida 38

39 Diskussion 6 Diskussion 6.1 Services Övervakning Från början var tanken att skapa grafer direkt i nagios med pluginet NagiosGrapher. Det fungerade dock mindre bra. Alla inställningar gjordes i konfigurationsfiler och för varje nytt värde man lade till var man tvungen att använda regexp vilket ibland fungerade väldigt dåligt. Därför testades Cacti istället vilket fungerade väldigt bra samtidigt som det var enkelt att använda. Bortsett från att generera grafer så fungerade Nagios mycket bra för tjänsteövervakning. Det var väldigt smidigt att kunna sätta en tjänst som alarmerade i läget "acknowledged" när man visste vad som var fel. Samtidigt kunde man sätta en kommentar så att andra som tittade på övervakningen kunde läsa om varför tjänsten larmade. Nagios fungerade därför väldigt bra när flera personer satt på olika platser och övervakade NTP I början uppstod en del problem med att tiderna såg konstiga ut för speakern när man jämförde förvarningen med målgångstiden. Problemet troddes först vara att klienterna inte var tidsynkroniserade ordentligt. Det visade sig sedan att ola servrarna inte alls var inställda på att synkronisera mot NTP servern. Ett råd till nästa år är att lägga ner mer energi på att testa tidssynkroniseringen så att klienter och ola servrar på ett bra sätt kan hålla samma tid som fröken ur (alla andra klockor som är viktiga för tävlingen ställs mot fröken ur) Kioskdatorer I mässan och ute i resultattältet på arenan stod det kioskdatorer där orienterarna kunde kolla sina resultat på oringenonline. Det uppstod en del problem i nedlåsningen av datorerna. Från början var det tänkt att datorerna skulle vara inloggade med ett konto som genom group policys inte tilläts att starta firefox och som blockerades från all sidor utom oringenonline med content filtering i internet explorer (som startades i kioskläge med "-k" växeln). Det blev problem när content filtering blockerade något javascript på sidan, det fungerade som normalt men på grund av de meddelanden som kom upp när javascriptet blockerades trodde vissa användare att något var fel på sidan. I mässan stängde vissa användare ner internet explorer och gjorde saker de inte skulle. För att lösa båda problemen användes ett wrapperprogram till internet explorer som startade det i ett helt nedlåst fullskärmsläge där det bara gick att komma åt oringenonline. Sen var det bara att stänga av content filtering. 6.2 Core Team Sportia Team Sportia begärde internetaccess med publik IP-adress, vilket ordnades. Ganska snabbt så kom det klagomål från Team Sportias IT-ansvarige om att uppsättningen av nätverksutrustning och nätverkskabel inte var fackmannamässigt gjord. Switchen i fråga låg från början på ett ca 2 meter högt kylskåp i handlarns tält. Detta var inte tillräckligt högt och IT-chefen var övertygad om att folk Sida 39

40 Diskussion skulle riva ned den, det klagades även på strömförsörjningen trots att switchen var UPSad. Team Sportia ville inte att switchen skulle sitta på samma elcentral som kylar och dylikt utan på en helt egen elcentral. Det ansågs inte tillräckligt akut för att överväga omaket med att dra fram en ny elcentral. Switchen sattes dock upp i en metallbalk ca 5 meter upp i taket. Det är viktigt att lyssna på folks krav, men om de inte har begärt en sak från början är det inte säkert att man kan ta hänsyn till önskemålen Sjukvård Personalen i sjukvårdstältet orsakade en del problem under tävlingen. På morgonen på etapp 3 så placerades deras switch ut lite senare på morgonen på grund av tidsbrist. Detta resulterade i att de försökte bända upp kopplingsdosan till den tidigare utlagda fiberkabeln, lyckligtvis så skadades inget. Vid etappens slut så klippte personalen av fiberkabeln, orsaken till detta är oklart. På etapp 2 kopplade personalen in sig i consoleporten vilket inte fungerade så bra. Sjukvårdswitchen larmade ofta i Nagios för att den gick ned p.g.a. strömavbrott, orsaken till detta var för att sjukvårdstältet drog hutlösa mängder ström. Sida 40

41 Bilagor Bilagor Bilaga 1 - Grundkonfiguration för Nätverksutrustning service timestamps debug uptime service timestamps log uptime no service tcp-small-servers no service udp-small-servers no service finger no service pad service password-encryption service tcp-keepalives-in service tcp-keepalives-out no ip http server no ip http secure-server no ip source-route no ip directed-broadcast no ip bootp server no ip domain-lookup no ip gratuitous-arps no ip source-route no ip identd no cdp run ntp server clock timezone gmt 2 ip arp proxy disable ip dhcp snooping ip dhcp snooping vlan 10,20,30,40,50,60,70,80,90,100,110,120,130,140 enable secret 5 $1$GAF1$/GcncLfIxxtsP6hqH.y1w/ username admin password 7 151D19050A2D2E2A aaa new-model aaa authentication login telnet group tacacs+ local aaa authentication login console group tacacs+ local aaa authentication enable default group tacacs+ enable aaa authorization exec default if-authenticated none aaa accounting update newinfo ip subnet-zero no ip domain-lookup ip domain-name oringen.local crypto key generate rsa 1024 spanning-tree mode rapid-pvst line con 0 timeout login response 60 Sida 41

42 Bilagor logging synchronous login authentication console line vty 0 4 session-timeout 120 timeout login response 60 login authentication telnet transport input ssh line vty 5 15 session-timeout 120 timeout login response 60 login authentication telnet transport input ssh tacacs-server host tacacs-server key E1C0C090A7B7977 banner motd # O-RINGEN 2010 AUTHORIZED ACCESS ONLY # vtp domain ORINGEN vtp password oringenaeger end Sida 42

43 Bilagor Bilaga 2 Konfiguration för O-NOC-C version 12.2 no service pad service tcp-keepalives-in service tcp-keepalives-out service timestamps debug uptime service timestamps log uptime service password-encryption service unsupported-transceiver hostname O-NOC-C boot-start-marker boot-end-marker enable secret 5 $1$GAF1$/GcncLfIxxtsP6hqH.y1w/ username admin password 7 151D19050A2D2E2A aaa new-model aaa authentication login telnet group tacacs+ local aaa authentication login console group tacacs+ local aaa authentication enable default group tacacs+ enable aaa authorization exec default if-authenticated none aaa accounting update newinfo aaa accounting exec default start-stop group tacacs+ aaa session-id common clock timezone GMT 1 system mtu routing 1500 vtp domain ORINGEN vtp mode transparent ip subnet-zero no ip source-route ip routing ip arp proxy disable no ip gratuitous-arps no ip domain-lookup ip domain-name oringenonline.se ip dhcp snooping vlan 10,20,30,40,50,60,70,80,90,100,110,120,130,140 ip dhcp snooping crypto pki trustpoint TP-self-signed Sida 43

44 Bilagor enrollment selfsigned subject-name cn=ios-self-signed-certificate revocation-check none rsakeypair TP-self-signed crypto pki certificate chain TP-self-signed certificate self-signed B9 A D0609 2A F70D F30 2D F532D 53656C66 2D E65642D D E 170D A17 0D A F302D F532D53 656C662D E 65642D D F 300D0609 2A F70D D AC1D 0563B133 2D14CD2A B29C6B4E DB1CBA7C 25E1CFD4 AA65A372 E48D3CB3 76C598ED EA1A96FA 4F6D0D79 64B7DF4F C0943EAF 2F251F12 B7101D42 77B1694C A19A8FA4 3142BC7A 4413C DB7 7AB8EDE5 FE6CE38E 14A963F4 96A1200E B1427A0E FBABAA71 CCEFA801 1D9B39A1 E23C4C46 A063D946 AD3843A A F D FF FF D1104 1C301A82 184F2D4E 4F432D43 2E6F7269 6E67656E 6F6E6C69 6E652E F D F653 FACEB8B FC B0A 1F80301D D 0E F653FA CEB8B FC B0A1F 80300D06 092A F70D FFBA5 F8BE830E B9F CED7B7 0AA10FB6 BE3CD495 C7862E58 1F5A86FA A55AA0D0 867E882C 3F B6772F2C BFE63EEE 8C6146A1 81EC82B4 590C E8F9A A8786B82 EBAE C733BA 51CDEDCC 4518C7A6 A1007AB0 0B DF A2A69C89 FB0D2B92 2F6CA3F9 4AD06F96 9A9B7BB5 E932E23E DC523D85 quit archive path tftp:// /noc-c Sida 44

45 Bilagor write-memory spanning-tree mode rapid-pvst spanning-tree extend system-id spanning-tree vlan 1 priority 4096 spanning-tree vlan priority vlan internal allocation policy ascending vlan 10 name MGMT vlan 20 name PRESS_INET_ACC vlan 30 name PRESS_INTERNET vlan 40 name VOIP vlan 60 name TECH vlan 70 name OLA_ARENA vlan 80 name SERVRAR_ARENA vlan 90 name OLA_CITY vlan 99 name NATIVE vlan 100 name SERVRAR_CITY vlan 120 name AP_MGMT vlan 130 name EXTERNT_WAN vlan 140 name INTERNT_LANKNAT interface FastEthernet0/1 switchport access vlan 130 Sida 45

46 Bilagor spanning-tree bpdufilter enable spanning-tree bpduguard enable interface FastEthernet0/2 switchport access vlan 130 interface FastEthernet0/3 switchport access vlan 130 interface FastEthernet0/4 switchport access vlan 140 interface FastEthernet0/5 interface FastEthernet0/6 interface FastEthernet0/7 interface FastEthernet0/8 description O-NOC-WLC switchport trunk encapsulation dot1q switchport trunk native vlan 99 switchport mode trunk switchport nonegotiate ip dhcp snooping trust interface FastEthernet0/9 switchport access vlan 100 interface FastEthernet0/10 switchport access vlan 100 interface FastEthernet0/11 switchport access vlan 100 interface FastEthernet0/12 Sida 46

47 Bilagor switchport access vlan 100 ip dhcp snooping trust interface FastEthernet0/13 interface FastEthernet0/14 interface FastEthernet0/15 interface FastEthernet0/16 interface FastEthernet0/17 interface FastEthernet0/18 switchport access vlan 60 interface FastEthernet0/19 switchport access vlan 130 interface FastEthernet0/20 description O-VPN-SERVER switchport access vlan 60 interface FastEthernet0/21 interface FastEthernet0/22 switchport trunk encapsulation dot1q switchport trunk native vlan 99 switchport mode trunk switchport nonegotiate interface FastEthernet0/23 interface FastEthernet0/24 switchport trunk encapsulation dot1q switchport trunk native vlan 99 switchport mode trunk ip dhcp snooping trust Sida 47

48 Bilagor interface GigabitEthernet0/1 switchport trunk encapsulation dot1q switchport trunk native vlan 99 switchport mode trunk ip dhcp snooping trust interface GigabitEthernet0/2 switchport trunk encapsulation dot1q switchport trunk native vlan 99 switchport mode trunk interface Vlan1 no ip address shutdown interface Vlan10 ip address no ip proxy-arp interface Vlan20 ip address ip access-group PUBLIK_INET_ACCESS_IN in ip helper-address ip helper-address no ip proxy-arp interface Vlan30 ip address ip access-group PUBLIK_PRESS_ACCESS_IN in ip helper-address ip helper-address no ip proxy-arp interface Vlan40 ip address ip helper-address ip helper-address no ip proxy-arp interface Vlan60 ip address ip helper-address ip helper-address no ip proxy-arp interface Vlan70 ip address no ip proxy-arp interface Vlan80 ip address no ip proxy-arp Sida 48

49 Bilagor interface Vlan90 ip address ip helper-address ip helper-address no ip proxy-arp interface Vlan100 ip address no ip proxy-arp interface Vlan120 ip address ip helper-address ip helper-address no ip proxy-arp interface Vlan130 ip address no ip proxy-arp interface Vlan140 ip address no ip proxy-arp router eigrp 1 no auto-summary network network network network network network network network network network network network ip classless ip route no ip http server no ip http secure-server ip access-list extended PUBLIK_INET_ACCESS_IN permit icmp host permit udp any host eq bootps bootpc domain permit tcp any host eq domain permit ip permit udp any host eq bootps bootpc domain permit tcp any host eq domain Sida 49

50 Bilagor deny ip permit ip any any ip access-list extended PUBLIK_PRESS_ACCESS_IN permit icmp host permit udp any host eq bootps bootpc domain permit tcp any host eq domain permit ip permit udp any host eq bootps bootpc domain permit tcp any host eq domain deny ip permit ip any any kron occurrence backup in 2:0 recurring policy-list backup kron policy-list backup cli write access-list 60 permit snmp-server community snaelloringen RO 60 tacacs-server host tacacs-server directed-request tacacs-server key E1C0C090A7B7977 control-plane banner motd _ O-RINGEN 2010 AUTHORIZED ACCESS ONLY _ line con 0 timeout login response 60 password E1C0B16170C0916 logging synchronous login authentication console line vty 0 4 session-timeout 120 timeout login response 60 login authentication telnet transport input ssh line vty 5 15 session-timeout 120 timeout login response 60 login authentication telnet transport input ssh ntp server end Sida 50

51 Bilagor Bilaga 3 Konfiguration för O-ARENA-D version 12.2 no service pad service tcp-keepalives-in service tcp-keepalives-out service timestamps debug uptime service timestamps log uptime service password-encryption service unsupported-transceiver hostname O-ARENA-D boot-start-marker boot-end-marker enable secret 5 $1$ROj1$.cP12t5.Y4tiryzQgh4Ks1 username admin privilege 15 password F4B4B aaa new-model aaa authentication login telnet group tacacs+ local aaa authentication login console group tacacs+ local aaa authentication enable default group tacacs+ enable aaa authorization exec default if-authenticated none aaa accounting update newinfo aaa accounting exec default start-stop group tacacs+ aaa session-id common system mtu routing 1500 udld enable ip subnet-zero no ip source-route ip routing ip arp proxy disable no ip gratuitous-arps no ip domain-lookup ip domain-name oringenonline.se ip dhcp snooping vlan 10,20,30,40,50,60,70,80,90,100,110,120,130,140 ip dhcp snooping crypto pki trustpoint TP-self-signed Sida 51

52 Bilagor enrollment selfsigned subject-name cn=ios-self-signed-certificate revocation-check none rsakeypair TP-self-signed crypto pki certificate chain TP-self-signed certificate self-signed A9 A D0609 2A F70D F30 2D F532D 53656C66 2D E65642D D E 170D A17 0D A F302D F532D53 656C662D E 65642D D F 300D0609 2A F70D D ED99 542C19AA 58C59BD6 3109A62D 91D361CC A41DF292 5A6FD45A A D6706F3 2B9FB26D 9C3B31C4 87C8058E 7466C752 D8AA5D09 B AE6611DC CCD68D65 52EC1FB D4182E2 3D0B9A83 6D4DB443 31DF095D 4AF8A54E 176BA5F4 27E B4E8FBF 0F94E69A 0408ADA6 C441051F DF76BBDD D7068A6E A F D FF FF D1104 0C300A82 084F2D55 4E492D44 2E301F D C8659F1 099BAD28 723B4D7B 014AE021 7F25301D D 0E C 8659F109 9BAD2872 3B4D7B01 4AE0217F 25300D06 092A F70D F5C9CAF C51EE382 A09CC621 ED1FB953 57D89F84 AA1C9F81 3D6CEDAD 6063A7BC 9EEB1FFC 1D87A35C 3571D3BA 7F3A989C EF0FEECB C992C198 A5BF3752 EED5307D C89C334A FCA51876 FE0AB2CF 46315BAF FEC9AAD0 3C1D1B16 205E6389 EAB4CCDD 34CE663C 114A301D 607BDEC4 75F0AE6A 2C7F1D1F C69A3D4B 99FB9147 FF29E601 quit no errdisable detect cause gbic-invalid archive path tftp:// /arena-d Sida 52

53 Bilagor write-memory spanning-tree mode rapid-pvst spanning-tree extend system-id vlan internal allocation policy ascending interface FastEthernet0/1 interface FastEthernet0/2 interface FastEthernet0/3 interface FastEthernet0/4 interface FastEthernet0/5 interface FastEthernet0/6 interface FastEthernet0/7 switchport access vlan 60 interface FastEthernet0/8 switchport access vlan 60 interface FastEthernet0/9 switchport access vlan 60 interface FastEthernet0/10 switchport access vlan 60 interface FastEthernet0/11 interface FastEthernet0/12 interface FastEthernet0/13 interface FastEthernet0/14 interface FastEthernet0/15 interface FastEthernet0/16 Sida 53

54 Bilagor interface FastEthernet0/17 interface FastEthernet0/18 switchport access vlan 80 interface FastEthernet0/19 switchport access vlan 80 interface FastEthernet0/20 switchport access vlan 80 interface FastEthernet0/21 switchport access vlan 80 interface FastEthernet0/22 switchport access vlan 80 ip dhcp snooping trust interface FastEthernet0/23 interface FastEthernet0/24 switchport trunk encapsulation dot1q switchport trunk native vlan 99 switchport mode trunk ip dhcp snooping trust interface GigabitEthernet0/1 switchport trunk encapsulation dot1q switchport trunk native vlan 99 switchport mode trunk ip dhcp snooping trust interface GigabitEthernet0/2 interface Vlan1 no ip address shutdown interface Vlan10 ip address interface Vlan30 Sida 54

55 Bilagor ip address ip helper-address ip helper-address interface Vlan70 ip address ip helper-address ip helper-address interface Vlan80 ip address ip helper-address ip helper-address ip classless ip route ip route no ip http server no ip http secure-server kron occurrence backup in 2:0 recurring policy-list backup kron policy-list backup cli write cli write access-list 60 permit no cdp run snmp-server community snaelloringen RO 60 tacacs-server host tacacs-server directed-request tacacs-server key E1C0C090A7B7977 control-plane banner motd _ O-RINGEN 2010 AUTHORIZED ACCESS ONLY _ line con 0 password 7 130A051B050B01242A212F3627 logging synchronous login authentication console line vty 0 4 session-timeout 120 timeout login response 60 password 7 130A051B050B01242A212F3627 logging synchronous login authentication telnet transport input ssh line vty 5 15 Sida 55

56 Bilagor session-timeout 120 timeout login response 60 password F C logging synchronous login authentication telnet transport input ssh end Bilaga 4 Konfiguration för O-STA-D-MASSA version 12.2 no service pad service tcp-keepalives-in service tcp-keepalives-out service timestamps debug uptime service timestamps log uptime service password-encryption hostname O-STA-D-MASSA boot-start-marker boot-end-marker enable secret 5 $1$GAF1$/GcncLfIxxtsP6hqH.y1w/ username admin password 7 151D19050A2D2E2A aaa new-model aaa authentication login telnet group tacacs+ local aaa authentication login console group tacacs+ local aaa authentication enable default group tacacs+ enable aaa authorization exec default if-authenticated none aaa session-id common clock timezone gmt 2 system mtu routing 1500 ip subnet-zero no ip source-route ip routing ip arp proxy disable no ip gratuitous-arps no ip domain-lookup ip domain-name oringenonline.com ip dhcp snooping vlan 140, ip dhcp snooping Sida 56

57 Bilagor archive path tftp:// /o-sta-d-massa write-memory spanning-tree mode rapid-pvst spanning-tree extend system-id vlan internal allocation policy ascending interface FastEthernet0/1 switchport access vlan 409 interface FastEthernet0/2 interface FastEthernet0/3 interface FastEthernet0/4 interface FastEthernet0/5 interface FastEthernet0/6 interface FastEthernet0/7 interface FastEthernet0/8 Sida 57

58 Bilagor interface FastEthernet0/9 interface FastEthernet0/10 interface FastEthernet0/11 interface FastEthernet0/12 interface FastEthernet0/13 switchport trunk encapsulation dot1q switchport mode trunk switchport nonegotiate ip dhcp snooping trust interface FastEthernet0/14 switchport trunk encapsulation dot1q switchport mode trunk switchport nonegotiate ip dhcp snooping trust interface FastEthernet0/15 switchport trunk encapsulation dot1q switchport mode trunk switchport nonegotiate ip dhcp snooping trust interface FastEthernet0/16 interface FastEthernet0/17 interface FastEthernet0/18 interface FastEthernet0/19 Sida 58

59 Bilagor interface FastEthernet0/20 interface FastEthernet0/21 interface FastEthernet0/22 switchport access vlan 400 interface FastEthernet0/23 switchport access vlan 412 interface FastEthernet0/24 switchport trunk encapsulation dot1q switchport mode trunk switchport nonegotiate ip dhcp snooping trust interface GigabitEthernet0/1 shutdown interface GigabitEthernet0/2 shutdown interface Vlan1 no ip address shutdown interface Vlan401 ip address ip default-gateway ip classless ip route no ip http server no ip http secure-server access-list 60 permit snmp-server community snaelloringen RO 60 tacacs-server host tacacs-server directed-request tacacs-server key E1C0C090A7B7977 control-plane banner motd _ Sida 59

60 Bilagor O-RINGEN 2010 AUTHORIZED ACCESS ONLY _ line con 0 timeout login response 60 logging synchronous login authentication console line vty 0 4 session-timeout 120 timeout login response 60 login authentication telnet transport input ssh line vty 5 15 session-timeout 120 timeout login response 60 login authentication telnet transport input ssh ntp clock-period ntp server end Bilaga 5 Konfiguration för O-STA-A-PRESS version 12.2 no service pad service tcp-keepalives-in service tcp-keepalives-out service timestamps debug uptime service timestamps log uptime service password-encryption hostname O-STA-A-PRESS boot-start-marker boot-end-marker enable secret 5 $1$GAF1$/GcncLfIxxtsP6hqH.y1w/ username admin password 7 151D19050A2D2E2A aaa new-model aaa authentication login telnet group tacacs+ local aaa authentication login console group tacacs+ local aaa authentication enable default group tacacs+ enable aaa authorization exec default if-authenticated none Sida 60

61 Bilagor aaa accounting update newinfo aaa session-id common clock timezone gmt 2 system mtu routing 1500 ip subnet-zero no ip source-route ip routing ip arp proxy disable no ip gratuitous-arps no ip domain-lookup ip domain-name oringenonline.com ip dhcp snooping vlan 140, ip dhcp snooping archive path tftp:// /o-sta-a-press write-memory spanning-tree mode rapid-pvst spanning-tree extend system-id vlan internal allocation policy ascending ip ssh version 1 interface FastEthernet0/1 switchport access vlan 403 interface FastEthernet0/2 switchport access vlan 403 interface FastEthernet0/3 switchport access vlan 403 Sida 61

62 interface FastEthernet0/4 description Ola-Skrivare switchport access vlan 409 interface FastEthernet0/5 switchport access vlan 403 interface FastEthernet0/6 switchport access vlan 403 interface FastEthernet0/7 switchport access vlan 403 interface FastEthernet0/8 switchport access vlan 403 interface FastEthernet0/9 switchport access vlan 403 interface FastEthernet0/10 switchport access vlan 403 interface FastEthernet0/11 switchport access vlan 403 interface FastEthernet0/12 switchport access vlan 403 interface FastEthernet0/13 switchport access vlan 403 interface FastEthernet0/14 Bilagor Sida 62

63 Bilagor switchport access vlan 403 interface FastEthernet0/15 switchport access vlan 403 interface FastEthernet0/16 switchport access vlan 403 interface FastEthernet0/17 switchport access vlan 403 interface FastEthernet0/18 switchport access vlan 403 interface FastEthernet0/19 switchport access vlan 403 interface FastEthernet0/20 switchport access vlan 403 interface FastEthernet0/21 switchport access vlan 403 interface FastEthernet0/22 switchport access vlan 403 interface FastEthernet0/23 switchport access vlan 412 interface FastEthernet0/24 switchport trunk encapsulation dot1q switchport trunk allowed vlan switchport mode trunk Sida 63

64 Bilagor switchport nonegotiate ip dhcp snooping trust interface GigabitEthernet0/1 interface GigabitEthernet0/2 interface Vlan1 no ip address shutdown interface Vlan401 ip address ip default-gateway ip classless ip route no ip http server no ip http secure-server access-list 60 permit snmp-server community snaelloringen RO 60 tacacs-server host tacacs-server directed-request tacacs-server key E1C0C090A7B7977 control-plane banner motd _ O-RINGEN 2010 AUTHORIZED ACCESS ONLY _ line con 0 timeout login response 60 logging synchronous login authentication console line vty 0 4 session-timeout 120 timeout login response 60 login authentication telnet transport input ssh line vty 5 15 session-timeout 120 timeout login response 60 login authentication telnet transport input ssh ntp clock-period ntp server end Sida 64

65 Bilagor Bilaga 6 Konfiguration för O-ARENA-A-RESULTATUTSKR version 12.2 no service pad service tcp-keepalives-in service tcp-keepalives-out service timestamps debug uptime service timestamps log uptime service password-encryption hostname O-ARENA-A-RESULTATUTSKR boot-start-marker boot-end-marker enable secret 5 $1$GAF1$/GcncLfIxxtsP6hqH.y1w/ username admin password 7 151D19050A2D2E2A aaa new-model aaa authentication login telnet group tacacs+ local aaa authentication login console group tacacs+ local aaa authentication enable default group tacacs+ enable aaa authorization exec default if-authenticated none aaa session-id common clock timezone gmt 2 system mtu routing 1500 vtp domain ORINGEN vtp mode transparent ip subnet-zero no ip source-route ip arp proxy disable no ip gratuitous-arps ip dhcp snooping vlan , ip dhcp snooping no ip domain-lookup ip domain-name oringenonline.com Sida 65

66 Bilagor archive path tftp:// /o-arena-a-resultatutskr write-memory spanning-tree mode rapid-pvst spanning-tree extend system-id vlan internal allocation policy ascending vlan 15 name mgmt vlan 35,45,55,65 vlan 70 name ola vlan 80,125 interface FastEthernet0/1 switchport access vlan 70 interface FastEthernet0/2 switchport access vlan 70 interface FastEthernet0/3 switchport access vlan 70 interface FastEthernet0/4 switchport access vlan 70 interface FastEthernet0/5 switchport access vlan 70 interface FastEthernet0/6 switchport access vlan 70 Sida 66

67 interface FastEthernet0/7 switchport access vlan 70 interface FastEthernet0/8 switchport access vlan 70 interface FastEthernet0/9 switchport access vlan 70 interface FastEthernet0/10 switchport access vlan 70 interface FastEthernet0/11 switchport access vlan 70 interface FastEthernet0/12 switchport access vlan 70 interface FastEthernet0/13 switchport access vlan 70 interface FastEthernet0/14 switchport access vlan 70 interface FastEthernet0/15 switchport access vlan 70 interface FastEthernet0/16 switchport access vlan 70 interface FastEthernet0/17 switchport access vlan 70 Bilagor Sida 67

68 interface FastEthernet0/18 switchport access vlan 70 interface FastEthernet0/19 switchport access vlan 70 interface FastEthernet0/20 switchport access vlan 70 interface FastEthernet0/21 switchport access vlan 70 interface FastEthernet0/22 switchport access vlan 70 interface FastEthernet0/23 switchport access vlan 70 interface FastEthernet0/24 switchport mode trunk switchport nonegotiate ip dhcp snooping trust interface GigabitEthernet0/1 switchport mode trunk switchport nonegotiate ip dhcp snooping trust interface GigabitEthernet0/2 switchport mode trunk switchport nonegotiate ip dhcp snooping trust interface Vlan1 no ip address no ip route-cache shutdown interface Vlan15 Bilagor Sida 68

69 Bilagor ip address no ip route-cache ip default-gateway no ip http server no ip http secure-server tacacs-server host tacacs-server directed-request tacacs-server key E1C0C090A7B7977 control-plane banner motd _ O-RINGEN 2010 AUTHORIZED ACCESS ONLY _ line con 0 timeout login response 60 logging synchronous login authentication console line vty 0 4 session-timeout 120 timeout login response 60 login authentication telnet transport input ssh line vty 5 15 session-timeout 120 timeout login response 60 login authentication telnet transport input ssh ntp clock-period ntp server end Sida 69

70 Bilagor Bilaga 7 Nätverkskarta för Etapp 1 Sida 70

71 Bilagor Bilaga 8 - Nätverkskarta för Etapp 2 och 3 Sida 71

72 Bilagor Bilaga 9 - Nätverkskarta för Etapp 4 Sida 72

73 Bilagor Bilaga 10 - Nätverkskarta för Etapp 5 Sida 73

74 Bilagor Bilaga 12 Nätverkskarta för O-Ringenstaden Sida 74

75 Bilagor Bilaga 13 - Detaljerade bandbreddsgrafer Etapp 1 Sida 75

76 Bilagor Sida 76

77 Bilagor Etapp 2 Sida 77

78 Bilagor Sida 78

79 Bilagor Etapp 3 Sida 79

80 Bilagor Sida 80

81 Bilagor Sida 81

82 Etapp 4 Bilagor Sida 82