Automatisk kontroll av status för switch-portar

V

ÄSTERÅS

,

S

WEDEN

DVA333 – Examensarbete för Högskoleingenjör inom nätverksteknik,

15hp

AUTOMATISK KONTROLL AV STATUS

FÖR SWITCH

-

PORTAR

Dan Östergren

don13002@student.mdh.se

Examinator: Johan Åkerberg

Mälardalens Högskola, Västerås, Sweden

Handledare: Sara Lundahl

Mälardalens Högskola, Västerås, Sweden

Handledare: Thomas Trolin

Cygate, Solna, Sweden

1

Sammanfattning

I stora nätverksmiljöer kan det idag vara svårt att få en komplett sammanställning av hur många switch-portar som är i bruk. Den lösning som vanligtvis används är manuell inloggning till aktuell switch för kontroll, ett moment med tidsåtgång och som ofta utförs vid enstaka tillfällen. Information riskerar därför att upptäckas för sent med en åtgärd som blir reaktiv. Metoder för att tillgängliggöra informationen på ett sådant sätt att den till stor del kan bli proaktiv kan istället möjliggöra åtgärder i tid men även tillhandahålla aktuell information mer lättillgängligt och i slutändan spara både tid och utgifter för ett företag.

Arbetet inriktar sig på framtagandet av en lösning med specifika krav med en inriktning för att förenkla nuvarande moment; att på ett enkelt sätt kunna ta del av dagsaktuell information om status för switch-portar, att kunna få en övergripande bild av fördelningen av switch-portar för en anläggning och möjlighet för notifiering vid gränsöverskridelser. Inledande görs en undersökning av aktuella lösningar som finns att tillgå inom området idag, där flera visar sig ha brister men även saknar nödvändiga funktioner. Då de lösningar som finns tillgängliga idag inte stämmer överens med kraven finns en motivering till framtagandet av en lösning med egna funktioner. Den lösning som tas fram utvecklas med separata funktioner för att inhämta information, tolka, presentera och notifiera information för administratör. För att garantera en stabil lösning med kontinuerlig drift installerades en server i en extern datahall där en linuxdistribution användes. Två olika protokoll för inhämtning av information jämförs med praktiska tester, inloggning via SSH, samt SNMP-poll, där den valda lösningen bygger på SSH som metod på grund av säkerhetsaspekter, men där SNMP visar mer kompatibilitet mellan tillverkare och modeller av hårdvara. Vidare beskrivs tillvägagångssätt hos de funktioner som utvecklats för tolkning av inhämtad information samt de svårigheter som uppstått i samband med detta, för undvikandet av feltolkningar. Olika alternativ för presentation av information till administratör jämförs, där den valda lösningen blev åtkomst via webbsida, detta på grund av det grundläggande stöd oberoende av plattform. Något som exempelvis en applikation inte kan ge i samma omfattning. Bland de olika notifieringsmetoder som undersöktes föll valet även i detta fall på en plattformsoberoende metod, där notifiering via e-post ansågs både enkel att implementera och med ett brett stöd hos klienter. Varningar vid förangivna kriterier av antal lediga switch-portar kunde därmed tas emot av administratör. Samtliga funktioner fungerade vid utförandet som planerat och lösningen används av kunden. Det finns några förslag på förbättringsåtgärder där SNMP istället med fördel kan användas med bredare stöd hos andra tillverkare och modeller, samt även skyddsfunktioner vid tolkning av information.

2

Abstract

In large network environments today, it can be difficult to get a complete summary of how many switchports are in use. The solution that is usually used is manual login to the current switch for control, a step with time consumption and which is often performed on occasion. Information therefore risks being discovered too late with a measure that becomes reactive. Methods for making the

information available in such a way that it can largely become proactive can instead enable timely action but also provide up-to-date information more easily accessible and ultimately save both time and expenses for a company.

The work focuses on the development of a solution with specific requirements with a focus on simplifying current steps; to be able to easily access up-to-date information on the status of

switchports, to be able to get an overall picture of the distribution of switchports for a facility and the possibility of notification in the event of border crossings. Initially, an investigation is made of current solutions that are available in the area today, where several turn out to have shortcomings but also lack the necessary functions. As the solutions available today do not comply with the requirements, there is a motivation for developing a solution with its own functions. The solution that is put together is developed with separate functions for collecting information, interpreting, presenting and notifying information to the administrator. To ensure a stable solution with continuous operation, a server was installed in an external datacenter where a Linux distribution was used. Two different protocols for obtaining information are compared with practical tests, login via SSH, and SNMP-poll, where the chosen solution is based on SSH as a method due to security reasons, but where SNMP shows more compatibility between manufacturers and models of hardware. Furthermore, the procedures of the functions that have been developed for the interpretation of collected information and the difficulties that have arisen in connection with this, for the avoidance of misinterpretations are described. Different options for presenting information to the administrator are compared, where the chosen solution was accessed via a website, this is due to the basic support regardless of platform. Something that, for example, an application cannot provide to the same extent. Among the various notification methods examined, the choice also fell in this case on a platform-independent method, where notification via e-mail was considered both easy to implement and with broad support among clients. Warnings for the specified criteria of the number of available switchports could thus be received by the administrator. All functions worked during the execution as planned and the solution is used by the customer. There are some suggestions for improvement measures where SNMP can instead be used to advantage with broader support from other manufacturers and models, as well as protection functions when interpreting information.

3

Innehållsförteckning

Figurer ... 5

1.

Inledning ... 6

2.

Bakgrund ... 7

2.1.

Vanligt förekommande lösningar ... 9

2.1.1.

Existerande lösningar för status för switch-portar ... 9

2.1.2.

Alternativ av informationsinhämtning ... 11

3.

Tidigare arbeten... 13

4.

Frågeställning ... 13

5.

Metod ... 14

6.

Etik och samhälleliga aspekter ... 14

7.

Utförande ... 14

7.1.

Metod för kännedom om aktivitet ... 15

7.1.1.

Status för fysisk länk ... 16

7.1.2.

Senaste aktivitetsändring ... 16

7.1.3.

Senast mottagna paket ... 16

7.1.4.

Senast skickade paket ... 16

7.2.

Genererad trafik i controlplane av switch ... 17

7.2.1.

Keepalive ... 17

7.2.2.

Spanning Tree ... 18

7.2.3.

Dynamic Trunking Protocol (DTP) ... 18

7.2.4.

Cisco Discovery Protocol (CDP) ... 18

7.2.5.

Övriga protokoll med användning av controlplane ... 18

7.3.

Val av hårdvara vid testutförande ... 18

7.4.

Funktionstest av metod för indikation av aktivitet ... 18

7.4.1.

Status för fysisk länk ... 18

7.4.2.

Senaste Aktivitetsändring ... 18

7.4.3.

Senast mottagna paket ... 19

7.4.4.

Senast skickade paket ... 19

7.4.5.

Val av metod för indikation av aktivitet ... 19

7.5.

Metod för kommunikation mellan server och switch... 19

7.5.1.

SNMP-poll ... 19

7.6.

Framtagandet av lösning med SSH ... 20

7.6.1.

Åtkomst till data ... 20

7.6.2.

Tolkning av information ... 21

7.6.3.

Presentation av information ... 21

7.6.4.

Notifieringar via email ... 22

7.6.5.

Perioditet... 22

7.6.6.

Placering av server ... 22

7.6.7.

Säkerhetsåtgärder ... 23

4

8.

Resultat ... 24

8.1.

Funktion för inhämtning ... 24

8.2.

Funktion för tolkning av passerad tid ... 25

8.3.

Funktion för email-notifiering ... 25

9.

Diskussion ... 27

10.

Slutsatser ... 29

11.

Framtida arbete ... 29

12.

Författarens tack ... 30

Referenser ... 31

Bilagor ...i

Bilaga A – Utdrag från Catalyst 4500X för status om switch-portar ... ii

Bilaga B – Verifiering av funktion för aktivitet hos olika MIB ... iii

5

Figurer

Figur 1 – Scenario med två användare och två skrivare anslutna till en switch... 8

Figur 2 – Scenario med en enhet som tagits bort och en ny dator ansluts ... 9

Figur 3 – Cisco Prime Infrastructure – Port Capacity Report ...10

Figur 4 – Cisco Prime Infrastructure – Port Reclaim Report ...10

Figur 5 – SwitchWatch – Inställning för inloggning [18] ...11

Figur 6 – SwitchWatch – Inställning av kriterie [18] ...11

Figure 7 – Beskrivning av relevanta MIB i träd IF-MIB [20] ...17

Figure 8 – Beskrivning av relevanta MIB i träd OLD-CISCO-INTERFACES-MIB [24] ...17

Figur 9 – Beskrivning av relevanta MIB i träd CISCO-IF-EXTENSION-MIB [26] ...17

Figur 10 – Skiss över VM-maskin – VPN tunnel – kundnät – managementnät ...23

Figur 11 – Webbgränssnitt med översikt av switch-portar för enskild switch eller switchstack ...25

Figur 12 – Webbgränssnitt med översikt av fria switch-portar ...26

Figur 13 – E-mail som visar varning för låg andel fria switch-portar ...26

Figur 14 – Webbgränssnitt som visar varning för låg andel fria switch-portar ...27

6

1. Inledning

För nätverksmiljöer som vuxit till en större storlek uppstår ofta ett behov för övervakning och drift av nätverket. I stora topologier med många enheter riskerar administratörer och tekniker att tappa kontroll av information som funktionalitet och status. Detta kan lösas med verktyg som kontinuerligt samlar information från enheter och sammanställer denna på ett sätt som kan tolkas av en tekniker inom området. Tillvägagångssättet sker idag i regel för de flesta större miljöer där övervakning sker i form av enskild ansvarig eller en gruppering i form av Network Operations Center (NOC). Övervakningen omfattar oftast larmhantering i form av statusändringar som registreras som larm beroende på hur systemet är inställt. NOC har sedan möjlighet att agera på dessa larm. Denna form av övervakning sker till stor del reaktivt då statusändringen indikerar en incident som har inträffat. Något som oftast sker i mindre skala är proaktiv övervakning, där en tekniker får information i ett tidigt skede och sedan kan agera förebyggande i syfte att åtgärda eller göra en förändring i tid. Övervakning i proaktivt syfte kan exempelvis vara åtkomst till statistik över trafik för att kunna se regelbundna mönster över olika länkar i nätverket, oftast baserad på information som samlas in under en period över en längre tid.

Möjligheterna inom detta område är många och kan ge stor hjälp för exempelvis omstrukturering av flöden i trafik eller andra nödvändiga justeringar i nätverket som annars eventuellt inte noterats eller upptäcks för sent, med en akut förändring till följd. Enkel åtkomst till information kan ligga till grund för viktiga beslut. Näst intill alla nätverk förändras över tid och speciellt framtagna verktyg kan ge indikationer för dessa annars något dolda förändringar för en administratör.

Ett område där proaktiv information kan ligga till grund för användningen inom nätverket är samlad information om anslutna enheter. Hos ett företag med många anställda och flertalet switchar kan det vara svårt för en administratör att hålla uppdaterad och samlad dokumentation om status för switch-portar. Det kan vara svårt att veta hur många som är inkopplade och som fortfarande är aktiva av användare men även hur många lediga platser som finns tillgängliga hos en switch eller

sammankopplade switchar, även kallad switchstack. Information om status kan förvarna en

administratör i tid för att eventuellt kunna förbereda inköp av ny switch för utökning av antalet switch-portar medan platser fortfarande finns kvar. Väntetid kan i annat fall uppstå för nya användare vid tillfällen då samtliga platser blivit upptagna. Flera andra fördelar kan även ses med tillgång till information gällande detta. Det kan uppstå tillfällen då antagandet att en switch-port är upptagen då den tidigare varit inkopplad men att den i själva verket inte längre används aktivt. Platsen kan då fördelas om till en annan användare.

De lösningar som idag finns för tillgång till sådan information består ofta av arbetssätt baserat på manuell loggning på respektive enhet, utförda kommandon och sedan tolka information. Denna metod förutsätter viss kompetens hos användaren och blir snabbt tidskrävande och omständlig. En automatisk lösning kan istället fungera som ett alternativ för att ge användare information utan deras interaktion i en process med att samla och tolka den. Lösningen kan även ge information till tekniker som annars saknar den kompetens som i annat fall hade behövts för att kunna samla in informationen. Vid kontroll av redan existerande lösningar som Cisco Prime Infrastructure och SwitchWatch kan flera brister ses och ingen av lösningarna kan på enkelt sätt ge enkel information till en användare.

En kund till Cygate efterfrågade en sådan form av lösning då det var svårt för dem att få tag i denna information. På en site hade de en blandad uppsättning av ett 20-tal olika kopplingsrum med switchar och switchstackar. På siten fanns en administratör och en vaktmästare, där båda hanterade omkopplingar av switchportar. På grund av detta stora antal och arbeten fördelat på flera personer var det svårt för dem att få en helhetsbild över den verkliga användningen av switchportar för vardera plan i byggnaden. Detta fall kan ses som exempel där efterfrågan finns för en enkel lösning för information inom området. Artiklar med jämförelser mellan olika övervakningssystem och tidigare akademiska arbeten där optimering av Simple Network Management Protocol (SNMP) beskrivs, dock har tidigare akademiska arbeten inom området för information om senast använda tidpunkt för en switch-port ej kunnat hittats. Eftersom ett behov av någon form av automatiserad funktion för tillgång till aktuell information användes deras miljö därför som en fallstudie vid framtagandet av en komplett lösning.

7

Målet med arbetet är att undersöka, analysera och vidareutveckla mot mer avancerad nätverksdiagnostik. På grund av avsaknaden av funktioner för åtkomst till denna form av information togs en komplett lösning fram. Kundens nätverksmiljö användes som en fallstudie för genomförandet av en funktionell lösning. För framtagandet av en lämplig automatisk lösning krävdes en undersökning om tillvägagångsätt i metoder för inhämtning, tolkning och presentation av information. Flera olika metoder finns tillgängliga och undersöks, varav en lämplig metod väljs och används för ändamålet vid utförandet vid utvecklandet av den slutliga lösningen. Efter identifiering av två passande metoder för informationsinhämtning, SSH och SNMP-poll, kontrollerades sedan dessa efter eget laborativt testutförande då modeller och versioner kan skilja sig åt. Metoderna testades därför i ett första stadie på dedikerad hårdvara i experimentsyfte där sedan lösningen med SSH testades i produktionsmiljö på kundens utrustning för säkerställandet av funktionalitet och förväntat resultat. Vid utvecklandet av övriga funktioner för presentation av information och notifiering av information till administratör baserades de på beslut om att kunna visas på enhet oavsett plattform för att undvika inlåsning och göra funktionerna någorlunda framtidssäkra. Därav utvecklades presentation för åtkomst till information med webb-baserat gränssnitt och notifiering i form av varningar baserades på utskick med e-post.

Bakgrunden till arbetet presenterar ett scenario för att introducera läsaren för en situation som kan uppkomma hos ett företag. I scenariot visas vikten av tillgång till proaktiv information med dess påverkan för leverans av kontinuerlig drift för anställda på företaget. Ett behov kan ses finnas för enkel tillgång till informationen. Vanligt förekommande lösningar presenteras inom området. De metoder som sedan är intressanta för användning i funktioner i lösningen beskrivs, varav utveckling och testning av lösningen sedan gås igenom. Diskussion, förslag på framtida åtgärder beskrivs sedan till följt av slutsats.

2. Bakgrund

En situation som ofta uppstår är att enheter, som exempelvis anslutna datorer för anställda eller andra inventarier som skrivare och servrar flyttas runt inom ett företag eller avvecklas. Det medför att eventuellt tidigare inkopplingar mellan en switch-port och en patch-panel kan sitta kvar och bruka lediga platser. Vid en senare kontroll av tekniker kan det i det fallet misstolkas att tro att porten är i bruk (se fig. 2). I samband med avveckling eller flytt av anslutning för en enhet bör en rutin i form av en beställning av borttagning göras, där ansluten patch-kabel mellan switch och patch-panel avlägsnas. En korrekt avlägsnad kabel kan då ses vara påvisande vid frigjord port som vid framtida kontroll ger indikationen att den är ledig. Det är även positivt i säkerhetssyfte då den tidigare inkopplade switch-porten, utan vetskap hos administratör, ej riskeras att användas av en ny användare utan beställning om öppning. En fri switch-port kan då istället omfördelas till andra nätverksuttag där nya enheter behöver anslutas. Glöms en beställning om borttagning bort av någon anledning kan det vara svårt men även tidskrävande att i efterhand kontrollera status för eventuella portar som inte används. I fall som dessa kan en switch i onödan ha köpts in trots att lediga portar kan ha funnits tillgängliga i en närliggande switch som hade kunnat omplacerats i en switchstack där den behövts.

Ett scenario som kan uppkomma på ett företag demonstreras enligt figur 1 och 2. Figur 1 visar ett förenklat exempel där en switch med fyra switch-portar är anslutna till fyra patch-uttag (i verkligheten används ofta 8-48 portar per switch). Samtliga patch-uttag är kopplade med installerad Ethernet-kabel till nätverksuttag i ett kontor där användare vistas. De fyra anslutna uttagen är kopplade till två olika rum där de brukas av två användares datorer och två skrivare. Efter en tid har det bestämts att det endast finns behov av en skrivare för kontoret. Den ena skrivaren avvecklas och kopplas ur på plats med tillhörande patch-kabel till nätverksuttag. I det kopplingsrum där aktuell switch finns placerad undgås patch-kabel att tas bort mellan uttag och switch-porten av administratören. Det kan finnas en situation där det är ovisst om uttaget kommer användas av en ny enhet och lämnas därför kvar av den anledningen. Det finns även situationer där det glöms bort, eller där det är flera administratörer inblandade och av den anledningen undgås. I dessa situationer finns patch-kabel mellan patch-uttag och switch-port därmed kvar (se rödmarkerad kabel enligt fig. 2).

Vid ett senare tillfälle anställs en ny konsult som får en plats i ett annat rum. Det uttag som konsultens dator kopplas in i saknar förbindelse med switchen (se grönmarkerad kabel enligt fig. 2). Det kan ha gått

8

en tid sedan avvecklingen av den tidigare anslutna skrivaren, den tidigare patchningen glöms bort eller så kan den tidigare administratören ha blivit ersatt av en ny person. Administratören gör en kontroll på plats för lediga switch-portar och upptäcker att samtliga är upptagna. Administratören drar därför en felaktig slutsats om att inga nya anslutningar finns tillgängliga. Administratören ser att länk-indikatorn för en switch-port visar inaktiv länk men misstänker att det beror på att enheten som finns ansluten till den aktuella switch-porten inte är påslagen. Administratören bedömer då att en ny switch behöver köpas in till företaget då slutsatsen är att samtliga switch-portar är upptagna. Om administratören haft tillgång till information om hur lång tid som passerat då porten inte använts där den tidigare skrivaren varit ansluten hade det visat att den troligtvis kunnat frigöras och ersatts med ny anslutning till den nya användarens dator. Scenariot som beskrivs som exempel är en förenkling av verkligheten. I en verklig situation är det vanligt att flera switchar används inom samma företag med 24 switch-portar per switch eller mer, vilket gör det svårt för en administratör att kunna få kännedom av tidigare inkopplingar efter en viss tid passerat.

9 Figur 2 – Scenario med en enhet som tagits bort och en ny dator ansluts

2.1. Vanligt förekommande lösningar

Generellt sett kan automatiska funktioner som övervakning och konfigurationsinsamling redan förekomma på nätverksenheter men fungerar då ofta på sätt där historik för status av switch-portar inte finns representerad. För möjliggörande av dessa funktioner krävs oftast någon form av stöd av protokoll för insamling eller övervakning. Detta är något som Kao Ken beskriver i en artikel för att kunna möjliggöra bättre synbarhet via automatiska funktioner för tekniker [1]. I artikeln nämns bland annat protokollet SNMP men utöver detta finns även andra metoder tillgängliga. Med stöd av SNMP-protokollet kan statistik i form av detaljerad information som hastighet, räkning av olika typer av paket och error göras för vardera switch-port. Av kontinuerligt insamlad information kan sedan bevakning göras för en eller flera switch-portar och, eller switchar, som i sin tur kan användas för övervakning av ett team av tekniker. SNMP beskrivs mer ingående i ett kommande stycke.

2.1.1. Existerande lösningar för status för switch-portar

Det finns idag lösningar för att kunna få del av information om lediga switch-portar, men inte utan vissa begränsningar eller hinder. Manuell inhämtning från vardera switch där användaren själv loggar in och utför kommandon. Informationen som presenteras är obehandlad och svårtolkad och tillvägagångssättet är oftast väldigt begränsad då det tids- och resurs-mässigt inte är skalbart på ett företag med många nätverksenheter. Ett annat tillvägagångssätt är användning av program eller stödfunktioner för åtkomst, där användaren manuellt behöver använda funktioner och tolka information. Den mest aktuella lösningen enligt eget testutförande som bygger på denna metod är inte heller kostnadsfri. Två förekommande lösningar med funktion för kontroll av användning av switch-portar är Cisco Prime Infrastructure och SwitchWatch och beskrivs i följande stycke.

2.1.1.1. Cisco Prime Infrastructure

Ett av dessa program är Cisco Prime Infrastructure där generering av rapport kan visa data relaterat till området. Rapporter kan genereras direkt av användaren eller vid förinställda intervaller eller tidpunkter och datum. Informationen kan sedan presenteras i web-läsaren vid tillfället vid körning eller lagras som filer som sedan kan visas eller laddas hem av användaren. Informationen kan även skickas till användaren med en angiven mail-adress vid en förinställd tidpunkt för körning. De format som stöds är Comma-separated values (CSV) som baseras på ett format med en tabell-liknande struktur och Portable Document Format (PDF) som ger en rapport i ett format med stöd av text och grafik, formatet har stöd hos många plattformar. I samband med undersökningen vid arbetet fanns Cisco Prime Infrastructure version 3.4.0 tillgänglig som intern resurs hos Cygate. Därav gjordes praktisk undersökning kring de

10

rapporter som fanns att tillgå för den information som kunde användas i syftet för kontroll av lediga switch-portar. Följande rapporter kunde påträffas ha relevans inom området:

Wired Port Attribute – visar manuellt angivna inställningar på switch-portar som: access/trunk-port, admin status, operational status, VLAN ID, duplex, port-description och hastighet.

Port Capacity – visar antalet interface som använts vid tillfället för skapandet av rapporten. Både access- och trunk-portar räknas. Filtrering kan göras genom att välja andelen procent av lediga portar av det totala antalet som funnits tillgänglig. Figur 3 visar switchar med andelen lediga switch-portar under 30% (kan ses under Usage %). Port Capacity går att använda med två olika alternativ – ”Free up” som visar portar som är angivna med ”administrative up” och ”Free down” som visar portar som är angivna som ”administrative down” [13].

Figur 3 – Cisco Prime Infrastructure – Port Capacity Report

Port Reclaim Report – visar information om status för ”Last Used” – det vill säga senaste datum och tid för användning (se fig. 4). Valbara filter är antal dagar, senaste 2, 4, 8, 12 veckor, 6 månader eller ett år. Rapport kan väljas att inkludera ”Unused Up Ports” eller ”Unused Down Ports”. Det förstnämnda beskriver switch-portar som manuellt är aktiverade i switchens konfiguration och som inte varit anslutna till enhet på minst ett dygn. Det sistnämnda beskriver istället portar som är manuellt är avaktiverade och som inte varit anslutna till enhet på minst ett dygn [14].

Figur 4 – Cisco Prime Infrastructure – Port Reclaim Report

Flera av de rapporter som fanns tillgängliga i Cisco Prime Infrastrucure visade information om switch-portar, dock var det endast Port Reclaim Report som kunde presentera information om vilka portar som fanns enligt kriteriet för att senast ha varit använda. Rapporten kan därför användas för att filtrera ut portar som kan ses som oanvända och lediga för nya enheter att använda. Port Capacity Report visar andelen fria portar i en switch men detta baseras endast på information från aktuell status vid tidpunkten. Den saknar därmed funktion för att visa huruvida switch-portar använts tidigare samma dag eller föregående dagar eller veckor. För att kunna säkerställa andel fria portar behövs information som baseras med grund på historik över en längre tid för när de senast använts. Cisco Prime Infrastructure har tidigare haft problem med felaktiga datum som kunnat visats i Port Reclaim Report. Detta har påvisats i version 3.2.1 – 3.4.0 men har åtgärdats i version 3.5.0 enligt Cisco [15].

2.1.1.2. SwitchWatch

Ett annat alternativ är ett äldre program kallat SwitchWatch 2.1.0.0 som ska ha möjlighet att visa lediga portar som inte använts efter förinställt antal veckor. Enligt softpedia.com beskrivning av programmet: ”Switchwatch allows you to Find unused ports on Cisco Switches based on last used” [16]. Programmet

11

ser dock ut att ha slutat utvecklas och leverantörens domänregistrering för w3soft.com har i dagsläget löpt ut. Vi lyckades hitta programmet hos tredje part men fick det ej att fungera i Windows 10 miljö. Version 2.1.0.0 visas enligt softpedia.com [17] vara daterad till 27 november 2010 vilket troligtvis kan vara en rimlig orsak till kompatibilitetsproblemen med dagens operativsystem. En video finns presenterad där programmet körs i Windows XP SP2 miljö. Videon visar inställningsmöjligheter som IP-adress, inloggningsuppgifter (se fig. 5) och gruppering av switchar samt angivelse för antalet dagar (se fig. 6) som kriterier vid överstigande för klassning av lediga switch-portar.

Figur 5 – SwitchWatch – Inställning för inloggning [18]

Figur 6 – SwitchWatch – Inställning av kriterie [18]

2.1.2. Alternativ av informationsinhämtning

Vanligt förekommande metoder för informationshämtning gås igenom nedan.

2.1.2.1. Konfigurationsinsamling

Konfigurationsinsamling bygger på hämtning av en kopia av den aktuella konfigurationen som nätverksenheten använder för tillfället. Den innehåller information om en switch-port manuellt är aktiverad eller inte samt eventuellt en beskrivning av vad som finns anslutet. En konfigurationsfil innehåller statisk information då den endast visar angivna kommandon och inställda värden [2]. Den saknar därför information om aktuell status, då den, förutom vid manuella ändringar, inte förändras med tiden. Det finns vissa fall där en port har stängts av i samband med felhantering; där status för switch-porten är i angiven läget err-disable. Skyddsfunktioner likt dessa agerar på nuvarande status hos switch-porten, de kan därför klassas som dynamiska. Likaså påverkas status dynamiskt vid inkoppling och urkoppling eller påslag och avstängning av en enhet inkopplad till en switch-port. En konfigurationsfil saknar därför information om någon enhet finns ansluten eller hur lång tid som passerat sedan den sist användes aktivt av någon enhet.

2.1.2.2. ICMP övervakning

Övervakning av en enhet sker ofta via generering av ICMP Echo-request paket vars funktion är en kontroll om enheten svarar vid en förfrågan för att på så sätt kunna indikera om enheten är fungerade och har kontakt med nätverket. Vid nåbarhet genereras ett svar från destinationen i form av ICMP

Echo-12

reply till avsändaren av ICMP Echo-request [3]. Denna form av övervakning visar endast nåbarhet till en nätverksenhet och saknar därför information om individuella switch-portar för anslutna klienter.

2.1.2.3. SNMP

Övervakning av tjänster/interface hos en enhet sker ofta via SNMP-protokollet. Där en SNMP-agent är en enhet som skickar ett värde från ett lokalt objekt och SNMP-manager är en server som tar emot informationen [4]. När information har emottagits kan sedan en analys göras lokalt hos SNMP-manager. De lokala objekt som läses av SNMP-agent kallas Object Identifier (OID). OID är en variabel med en unik adress enligt en förutbestämd struktur. Variabeln innehåller information kopplad till en datatyp. OID kan vara både läs och skrivbara och definieras med hjälp av Request For Change (RFC) som kan ses som en definierad standard. OID är en benämning för unik lokalisering av objekt som utförs av International Telecommunications Union (ITU) och ISO/IEC. Eftersom IOD endast består av indelning i form av siffror kan det vara svårt att förstå varje enskild adress funktion. Management Information Base (MIB) är en beskrivning av vardera IOD, vilket gör det lättare för användaren att hitta och förstå olika typer av objekt. ISO/IEC hanterar namngivning av MIB som börjar med 1. , vilket endast är aktuellt för denna rapport [5].

Fortsättningsvis hänvisar vi till manager, agent, poll, trap och inform när vi i själva fallet menar SNMP-manager, SNMP-agent, SNMP-poll, SNMP-trap och SNMP-inform. Tre olika metoder för överföring av information som kan användas mellan manager och agent är poll, trap och inform. Poll består av manager som ställer en förfrågan till agent varav ett värde läses av från ett objekt lokalt på agent och skickas tillbaks som svar till manager [6]. Trap består av en agent som skickar värde till manager vid vissa valbara förhållanden, som när ett interface exempelvis går ned. Då SNMP-protokollet använder User Datagram Protocol (UDP) för kommunikation, vilket är en kommunikationsmetod utan verifiering från mottagaren, saknas en kontroll för trafik som skickas från agent till manager i det fallet trap används. Agent kan inte veta om paketet förlorats längs vägen och manager saknar kännedom om en trap skickats av agent men av någon anledning inte nått destinationen, därav sker ingen återsändning och informationen som skickats går förlorad. För att åtgärda detta problem finns möjligheten att skicka trap med förväntat svar från manager. Denna metod kallas SNMP-inform och fungerar på samma sätt som trap men där agent förväntar sig ett svar från manager. Med SNMP-inform kommer agent att skicka på nytt om inget svar har mottagits från manager [4]. Då verifiering saknas i UDP, används istället funktionen för verifiering i SNMP-protokollet i det fallet inform används. Poll och inform kan därför ses som mer tillförlitliga metoder än trap. För aktivering av notifiering med trap av exempelvis status hos en switch-port kan kommandot snmp trap link-status användas på interface-nivå [7]. Aktivering av metod anges med snmp-server host [manager IP-adress] [traps | informs] [4]. Ett något begränsat antal val av traps kan även aktiveras globalt för en enhet för övervakning av exempelvis tjänster [8].

En funktion som kan samverka med SNMP-trap är Remote Network Monitoring (RMON). RMON är en funktion som kan aktiveras på en enhet och kan användas för att bevaka MIB-värden lokalt på enheten. Den kan anges till att använda ett absolut värde som utlösare eller ett deltavärde där den istället agerar vid en angiven skillnad mot ursprungsvärdet. Vid ett nått angivet kriterie kan den sedan anges till att skicka en trap eller inform. Intervall för avläsning av MIB-värde och värde för kriterie är valbara [9]. För att kunna hämta information med hjälp av polling behöver agent först aktiveras på den enhet som är tänkt att förmedla information. SNMP finns i flera versioner och denna rapport inriktar sig endast på version 2c. SNMP v2c baseras på en community string som kan beskrivas som en delad pre-shared-key mellan agent och manager. För aktivering av SNMP v2c agent anges snmp-server community [delad

nyckel] ro på aktuell switch [10]. ”ro” står i detta fall för read only, vilket ger en tillräcklig behörighet

då läsning av information endast är nödvändig för användningsområdet. Med hjälp av snmp get kan sedan en poll göras från manager till agent för inhämtning av information. snmp get används vid informationshämtning av enskild MIB-adress och snmp walk kan användas för informationsinhämtning av flera MIB i ett träd.

2.1.2.4. Syslog

Syslog kan anges att generera information vid en specifik nivå på en åtta-gradig skala – från Emergency (nivå 0) till Debug (nivå 7). Information för samtliga nivåer upp till (och inkluderat) den valda nivån tas med då syslog är aktiverat [11]. Som standard i Ciscos switchar är syslog aktiverat till buffern i minnet

13

medan valbara alternativ som utskrift i konsollfönstret kan göras. Ett annat vanligt alternativ är att skicka meddelanden till en angiven syslog-server. Övervakning av tjänster/interface genom syslog som genereras från en nätverksenhet till server. Analys av lagrade data kan sedan göras på syslog-servern. För aktivering med loggning av status till syslog-server av en switch-port kan logging event

link-status användas på interface-nivå [12]. Syslog använder liksom SNMP UDP för

informationsöverföring.

3. Tidigare arbeten

En granskning av olika övervakningsverktyg görs i artikeln ”IT Infrastructure-Monitoring Tools” från 2015 [33]. I artikeln nämns ett flertal kända övervakningsverktyg som Nagios, Zabbix, Hyperic, Solarwinds, Manage-engine OpManager, HP Operations manager, IBM Tivoli och WhatsUp Gold. Vid beskrivningen av dessa nämns funktioner där flera har stöd för varningar via e-mail och SMS och att fler har en funktion som beskrivs som ”custom alerts”. Artikeln saknar dock mer ingående beskrivningar av vardera verktyg, det framgår därför inte om något stöd finns för information om senast använda tidpunkt hos en switch-port.

Arbetet ”Network monitoring: Present and future” går igenom protokoll som vanligen används inom området för övervakning [34]. Standarder som nämns är SNMP MIB, Common Information Model (CIM), IP Flow Information Export (IPFIX), Network Configuration Protocol (NETCONF) och Yet Another Next Generation (YANG). SNMP MIB beskrivs som de facto standard för övervakning av nätverksenheter. NETCONF och YANG beskrivs båda vara metoder för både styrning och övervakning av nätverksenheter baserade på XML. CIM anses vara en objektorienterad standard som används på servrar, datorer och olika operativsystem. IPFIX beskrivs vara en standard som används för att mäta flöden av trafik.

I ett annat arbete ”Software Defined Control of Tunable Optical Transceivers Using NETCONF and YANG” beskrivs hur en Dense Wavelength Division Multiplexing (DWDM) Small Form-Factor Pluggable (SFP+)-modul kan styras av en annan enhet genom nätverket [35]. För funktionen av den lösning som beskrivs används NETCONF och YANG för styrning av valda områden av våglängder. Arbetet visar funktioner för både styrning i form av utförda ändringar av värden men även funktion för avläsning av information för verifiering. Arbetet innehåller egna framtagna program för programmering och läsning för den SFP+-modul som användes men även egen framtagen YANG-modul för integrering av Software Defined Networking (SDN). Arbetet innehåller en egen framtagen lösning och är inte utvecklad för integration med en vanligt använd programvara framtagen av en känd tillverkare av access-switchar.

Arbetet ”Real-time network monitoring scheme based on SNMP for dynamic information” beskriver ett förslag om lösning för att dynamiskt kunna begränsa och optimera sändning av information mellan SNMP-agent och SNMP-manager [36]. Lösningen visar ett resultat med en positiv påverkan på minnehantering, CPU användning hos SNMP-agent och nyttjandet av tillgänglig bandbredd i nätverket vid sändning av information jämfört mot traditionell övervakning av nätverksenheter. Arbetet är inriktat på optimering av sändning av information och saknar specifik tolkning av aktiva switch-portar. Utöver ovan nämnda arbeten saknar författaren kännedom om tidigare akademiska arbeten inom direkt aktuellt område för rapporten. Det finns liknande funktioner hos program som nämns i kommande avsnitt om alternativa lösningar. Som en del av bakgrundskontrollen utfördes en sökning i Mälardalens högskolebiblioteks sökfunktion Primo som visar vetenskapliga artiklar från flera databaser. De sökord som användes var: ”SNMP monitoring”, ”SNMP automation”, ”network monitoring”, ”SNMP MIB”, ”switchport status”, ”switchport SNMP”, ”netconf”, ”yang”, ”switchport syslog” samt ”switch” och ”port” i kombination med föregående sökord.

4. Frågeställning

För att möjliggöra åtkomst till information om aktivitet hos switchportar behövs kännedom om historik över tidigare användning. Därav behövs lämpliga metoder undersökas och testas. För att utgå från en tidigare exemplarisk nätverksmiljö bestående av nätverksenheter med eventuellt tidigare

14

implementerade tjänster som nätverksövervakning men utan proaktiva tjänster för information om lediga switchportar, hur kan stöd för detta implementeras detta på ett optimalt sätt i en sådan rådande nätverksmiljö? Vid framtagande av en fungerande automatiserad funktion för kontroll av switch-portar kommer flera alternativ granskas och motiveras för val. Flera olika lösningar kommer undersökas för motivering av val till den bäst lämpade. Vilken anslutningsmetod är lämplig för användning att hämta in information om status hos switchar? Vilken information är intressant och hur kan denna tas emot? Med hjälp av exempelvis vilka kommandon eller anrop till vilka MIB-träd och adresser kan nödvändig information hämtas? I vilken miljö bör scriptet implementeras? En kontroll av passande miljö och operativsystem efter rimliga krav på säker och kontinuerlig drift behöver göras för att garantera driftsäker funktionalitet hos scriptet. Vilken nåbarhet kommer att behövas mellan enheter? Den maskin scriptet finns placerad på att ha åtkomst till nätverksenheter från den miljö där det körs? Nödvändig kommunikation mellan server och switchar kommer att behöva säkerställas vara tillåten. På vilket sätt kan tekniker få åtkomst till dagsaktuell information med enkel åtkomst, fungerande med stöd hos flera plattformar? Hur kan en administratör bli meddelad i form av varningar med stöd för flera plattformar? Utöver utveckling av lösningens själva funktioner behöver även säkerheten ses över. Val för lämpliga metoder att skydda information över WAN-länk mellan server och kundens miljö, begränsning av åtkomst till server från användarnätverk men även identifiering av server från klient.

5. Metod

En inledande litteraturstudie har gjorts på de lösningar som idag finns gällande inhämtning av relevant information från nätverksenheter. Den eget framtagna lösningen har baserats på metod för åtkomst till tjänsten, vilket inkluderar protokoll samt metod för tillgång till informationen lokalt på enheten samt svar från utfört kommando eller annat anrop. Den lämpligaste lösningen kom sedan att ligga som grund för framtagning av scripten. I de fall där det var möjligt, utfördes praktisk testning i simulerad miljö med lokala data som källa för att sedan implementeras i produktionsmiljö när de nått förväntat resultat efter angivna kriterier. Tillvägagångssättet för det förväntade resultatet bygger på jämförelser mellan antalet riktiga fall av switch-portar i olika stadier som faller innanför kriterierna med det utfallna resultatet från funktionen. I fallstudien gör scriptet informationshämtning från enheter istället för att läsa från lokala filer. Scriptens funktionalitet kommer sedan att användas i en empirisk test-fas med notifiering och först efter utvalda simulerade switch-portsändringar på plats samt att det förhållit sig stabilt kan det ses dugligt. Även här kommer jämförelser mellan status på antalet switch-portar som befinner sig innanför kriterierna att jämföras med resultatet från lösningen.

6. Etik och samhälleliga aspekter

Då informationen i rapporten som beskriver arbetet, anslutningar och säkerhet kan betraktas som till viss del känslig information har kundens namn därför utelämnats på grund av detta. Även information som IP-adresser, sub-nätverk och hostname har maskerats i syftet.

7. Utförande

Efter den granskning som gjorts för tidigare arbeten, dels från allmänt kända och vanligen använda protokoll inom området samt egen studie, återstod ett par protokoll som hade funktionalitet att kunna påvisa förändring i samband med switchportar. De metoder som återstod som intressanta alternativ för insamling av information kunde anses vara:

Informationsinhämtning via tredje part:

▪ Åtkomst till SNMP-manager för analys av historiska data. ▪ Åtkomst till syslog-server för analys av historiska data. Direkt informationsöverföring mellan switch och server:

▪ Anslutning till aktuell switch för inhämtning av data genom exekvering av kommandon via SSH/telnet för aktuell status eller analys av syslog lokalt på enheten för historik.

▪ Anrop genom SNMP-poll till switchen för aktuell status. ▪ SNMP-trap till server.

15 ▪ SNMP-inform till server.

▪ Syslog till server.

De switchar som fanns tillgängliga i kravställarens produktionsmiljö var sedan tidigare aktiverade för att skicka information med SNMP-trap till manager, SNMP-poll från manager, samt information till syslog-server. En enhet som använder syslog skickar informationen med transportsättet UDP, även samma protokoll används vanligtvis för SNMP. Då transportsättet skiljer sig från TCP saknas funktion för verifiering av paket och förluster kan ske mellan källa och destination. I fallet med SNMP-trap kan SNMP-inform istället användas med verifiering. Informationen behöver i detta fall skickas från enheten till SNMP-manager eller syslog-server. För informationsinhämtning för tolkning behöver då inhämtning av information göras från den server där tolkning är tänkt att göras. Server behöver då hämta information i andra hand från syslog-server eller SNMP-manager. Detta resulterar i att information behöver skickas och lagras till ytterligare en part från källan. Det finns därmed en högre risk för driftstörningar om fel inträffar på syslog-server eller SNMP-manager. Information kan riskeras gå förlorad både längs vägen från switch till syslog-server eller SNMP-manager eller vid problem hos dessa där informationen lagras. Därav kan dessa metoder ses som mindre tillförlitliga när det gäller överföring av information, både vad gäller information skickad från switch till syslog-server eller SNMP-manager. Direkt anslutning till switch bidrar troligtvis till en begränsning av flöde vid informationsutbyte mellan parter. Detta i sin tur medverkar till information som passerar direkt till destinationen med ett mindre antal överföringar över länkar som även bidrar till mindre belastning för ett nätverk. Även om dessa metoder kunde ses som mindre önskvärda, saknades även tillgång för författaren för både syslog-server och SNMP-manager. En alternativ möjlighet var att installera syslog-server eller SNMP-manager direkt på den server där scripten fanns placerade och sedan konfigurera vardera switch att skicka meddelande till denna. På samma sätt fungerar de två metoderna SNMP-poll eller SSH/telnet med utförda kommandon, då båda bygger på initiering från server med förväntat svar. Det kunde därmed ses om kommunikation fungerat som tänkt vid varje inhämtning. En lösning med ytterligare en uppsättning av SNMP-manager eller syslog-server lokalt på servern skulle troligtvis även medverka till ökat flöde av ej nödvändig information, då varningar och annan information som fanns aktiverad för tidigare syslog server, utöver status för switch-portar troligtvis skulle dupliceras.

Vid utförandet undersöktes SNMP-trap och SNMP-inform som metod, vilka saknade möjlighet till aktivering av någon form av generering vid kriteriet för passerad tid för en ej aktiv switch-port. Även funktionen hos RMON undersöktes, vilken visade sig sakna möjlighet till jämförelse mellan olika värden från två separata MIB, utan endast hade stöd för jämförelse av värde före och efter hos en och samma MIB. Teoretiskt skulle det därför inte fungera för bevakning av ett värde mellan två olika MIB. Det kan därför inte användas vid passering av gränsvärde för delta mellan MIB::ifLastChange förhållande till sysUpTimeInstance. Däremot kan det fungera för bevakning av ett absolut värde som gränsvärde (exempelvis 100*60*60*7*7 = 17640000 , sju veckor uttryckt i enheten hundradels sekund) för cieIfLastOutTime (1.3.6.1.4.1.9.9.276.1.1.1.1.2) [21] med ett passande intervall. En djupare kontroll av RMON gjordes inte i arbetet, detta på grund av att den implementering av lokal konfiguration som då skulle vara nödvändig för vardera switch och switchport, samt en osäkerhet om RMON kunde användas med kommunikationsmetoden inform. Beräkning av information hämtad via poll förklaras mer ingående under 7.5.1 – SNMP-Poll.

De två återstående metoderna SNMP-poll och SSH/telnet för direkt inhämtning av information kunde därav anses som mest intressanta och lämpliga för arbetet. Arbetet tog därför en riktning för undersökning av lämpliga alternativ för insamling av information som bygger på dessa anslutningsmetoder.

7.1. Metod för kännedom om aktivitet

För kontroll av status för en switch-port kan flera metoder användas. Detta stycke bearbetar endast metoder för direkt inhämtning av information från switch där fyra olika metoder beskrivs, då detta endast är aktuellt för området av rapporten. Protokollen för inhämtning av information har begränsats till endast SSH/telnet samt SNMP. Flera av dessa metoder bygger på den trafik som switchen själv genererar på länken för vardera enskild switch-port, beroende på vilka protokoll som finns aktiverade. Trafiken är indelad i något som kallas controlplane och skiljer sig från vanlig trafik som delas in i dataplane. Trafik

16

som genereras i controlplane använder switchen vid kontroller och som stöd för att exempelvis kunna göra beslut om vilken switch-port den ska välja vid kommunikation [18] och beskrivs mer ingående under 7.2 – Genererad trafik i controlplane av switch.

7.1.1. Status för fysisk länk

Indikering av en aktiv länk hos en switch-port kan påvisa om en enhet finns anslutet för en Ethernet-länk. Om ingen enhet finns ansluten visas indikation på inaktiv Ethernet-länk. Samma utslag ges även då en enhet finns ansluten men vid tillfället inte är aktiv eller strömmatad. Indikation på en aktiv länk kan därmed endast ses då en enhet finns ansluten, är påslagen och fungerar korrekt. Informationsinhämtning om status för aktiv länk kan göras med hjälp av SNMP-förfrågan till IF-MIB::ifOperStatus (1.3.6.1.2.1.2.2.1.8) (se fig. 7) [19], [20] eller genom anslutning via SSH/telnet med exekvering av kommandot show interface [aktuellt interface] | include protocol. Det resultat som visas är det tillstånd porten har vid tidpunkten för förfrågan. Svar för SNMP ges som up(1) eller down(2).

7.1.2. Senaste aktivitetsändring

En funktion som kan beskrivas som en räknare för senaste aktivitet vid ändring av länk-status finns som stöd hos flera av Ciscos olika modeller av switchar. Informationen finns tillgänglig via SNMP-förfrågan till IF-MIB::ifLastChange (1.3.6.1.2.1.2.2.1.9) (se fig. 7) [19], [20]. Informationen baseras på senaste ändring av status, som exempelvis när en switch-port går från inaktivt läge (down) till aktivt läge (up). Information hämtad via SNMP baseras på senaste registrerade ändring av status presenterat i antalet hundradels sekunder sedan enheten startades [21]. Liknande information finns även tillgänglig via SSH/telnet men endast hos Cisco Catalyst switchar av modellserie 4500. Kommandot show interfaces

link visar för dessa en summerad lista över switch-portar presenterat i Down time (tid som passerat) och

Down since (tidpunkt) (se även Bilaga A) [22].

7.1.3. Senast mottagna paket

Indikering för senast inkommande paket på en switch-port fungerar på liknande sätt som ovan nämnda ”senast aktivitetsändring” med den skillnad att tidsräkning baseras på senast mottagna paket för aktuell swtichport. Informationshämtning kan göras via SNMP eller SSH/telnet med kommandot show

interface [aktuellt interface] | include Last input. Kommandot kan ses ha ett brett stöd hos flera av

Ciscos switch-modeller. Åtkomst via SNMP kan ske genom två olika MIB-träd. Båda har visats innehålla information för status av interface som kan användas för anrop via SNMP, OLD-CISCO-INTERFACES-MIB – locIfLastIn, [23] eller även benämnt SNMPv2-SMI::enterprises.9.2.2.1.1.3.10007 (1.3.6.1.4.1.9.2.2.1.1.3) (se fig. 8) [24] och CISCO-IF-EXTENSION-MIB – cieIfLastInTime [25], även benämnt SNMPv2-SMI::enterprises.9.9.276.1.1.1.1.1 (1.3.6.1.4.1.9.9.276.1.1.1.1.1.10007) (se fig. 9) [26]. Enligt Cisco är det tänkt att det sistnämnda MIB-trädet ska ersätta det första på sikt [27].

7.1.4. Senast skickade paket

På samma sätt som mottagna paket finns även information för senast utgående paket för en switch-port. Information finns under MIB OLD-CISCO-INTERFACES-MIB – locIfLastOut [23] eller även benämnt SNMPv2-SMI::enterprises.9.2.2.1.1.4 (1.3.6.1.4.1.9.2.2.1.1.4) (se fig. 8) [24], och

CISCO-IF-EXTENSION-MIB – cieIfLastOutTime [25], även benämnt

17

Object Name Object Identifier

interfaces 1.3.6.1.2.1.2 ifNumber 1.3.6.1.2.1.2.1 ifTable 1.3.6.1.2.1.2.2 ifEntry 1.3.6.1.2.1.2.2.1 ifIndex 1.3.6.1.2.1.2.2.1.1 ifDescr 1.3.6.1.2.1.2.2.1.2 ifAdminStatus 1.3.6.1.2.1.2.2.1.7 ifOperStatus 1.3.6.1.2.1.2.2.1.8 ifLastChange 1.3.6.1.2.1.2.2.1.9

Figure 7 – Beskrivning av relevanta MIB i träd IF-MIB [20]

Object Name Object Identifier

linterfaces 1.3.6.1.4.1.9.2.2 lifTable 1.3.6.1.4.1.9.2.2.1 lifEntry 1.3.6.1.4.1.9.2.2.1.1 locIfDescr 1.3.6.1.4.1.9.2.2.1.1.28 locIfLastIn 1.3.6.1.4.1.9.2.2.1.1.3 locIfLastOut 1.3.6.1.4.1.9.2.2.1.1.4

Figure 8 – Beskrivning av relevanta MIB i träd OLD-CISCO-INTERFACES-MIB [24]

Object Name Object Identifier

ciscoIfExtensionMIB 1.3.6.1.4.1.9.9.276 ciscoIfExtensionMIBObjects 1.3.6.1.4.1.9.9.276.1 ciscoIfExtensionStats 1.3.6.1.4.1.9.9.276.1.1 cieIfPacketStatsTable 1.3.6.1.4.1.9.9.276.1.1.1 cieIfPacketStatsEntry 1.3.6.1.4.1.9.9.276.1.1.1.1 cieIfLastInTime 1.3.6.1.4.1.9.9.276.1.1.1.1.1 cieIfLastOutTime 1.3.6.1.4.1.9.9.276.1.1.1.1.2

Figur 9 – Beskrivning av relevanta MIB i träd CISCO-IF-EXTENSION-MIB [26]

7.2. Genererad trafik i controlplane av switch

Följande protokoll är aktiverade som standard i Cisco IOS. Protokollen nämns då de har betydelse för avsnittet ”7.1 – Metod för kännedom om aktivitet” för kontroll av aktivitet med metoderna ”7.1.3 – Senast mottagna paket” samt ”7.1.4 – Senast skickade paket” för de switchar som nämns i kravspecifikationen för arbetet samt de switchar som använts vid experiment. Båda metodernas lämplighet diskuteras vidare under avsnittet ”7.4 – Funktionstest av metod för indikation av aktivitet”.

7.2.1. Keepalive

Skickas som standard i ett intervall av tio sekunder. Kan justeras till ett värde av 0-32767 sekunder med

18

[28] som en funktion för en form av verifiering att systemet har rättighet att skicka och ta emot data på ett interface samt en kontroll av hårdvaran kopplad till ett interface. Frames skickas som Ethertype code 0x9000 med samma källa och destination MAC 00:24:51:86:51:05.

7.2.2. Spanning Tree

Spanning Tree är ett protokoll för att motverka loopar på lager två i OSI-modellen. Skickas som standard i intervall om två sekunder. Kan justeras till ett värde av 1-10 sekunder med spanning-tree vlan

[VLAN-ID] hello-time [antal sekunder] och kan avaktiveras med spanning-tree bpdufilter enable eller no spanning-tree vlan [VLAN-ID] för att stänga av spanning-tree för det VLAN aktuell switch-port är

aktiverad för [29].

7.2.3. Dynamic Trunking Protocol (DTP)

DTP är ett protokoll för framförhandling av status för en trunk på båda sidor av en länk. Skickas som standard i ett intervall av 30 sekunder och kan avaktiveras med switchport mode access eller switchport

mode trunk och switchport nonegotiate för aktuell switch-port [30].

7.2.4. Cisco Discovery Protocol (CDP)

CDP är ett protokoll vars funktion är notifiering av information om en enhet till direkt kopplade nätverksenheter. Protokollet är framtaget av Cisco och används mestadels av enheter tillverkade av dem. Skickas som standard i ett intervall av 60 sekunder. Kan justeras till ett värde av 5-254 sekunder med

cdp timer [sekunder] och kan avaktiveras med no cdp enable på interface-nivå eller no cdp run på

global nivå [31].

7.2.5. Övriga protokoll med användning av controlplane

Utöver dessa protokoll finns fler valbara protokoll som använder sig av controlplane, men som ej är aktiverade som standard på Cisco switchar. Exempel på några som går att aktivera är Link Layer Discover Protocol (LLDP) som är ett liknande protokoll som CDP men som bygger på en öppen standard. Ett annat är Virtual Trunking Protocol (VTP) som skickar information om vilka VLAN som ska användas för en trunk med central styrning [32].

7.3. Val av hårdvara vid testutförande

I fallstudien användes utrustning i kundens miljö som bestod av Cisco Catalyst WS-C2960X-24PS-L (med PoE funktion), WS-C2960X-24TS-L och WS-C2960X-48TS-L. Den firmware-image som användes på samtliga switchar var 15.2(2)E6 (c2960x-universalk9-mz.152-2.E6.bin). Licensnivå som användes var ”lanbase”, detta motsvarar Ciscos grundlicens för modellerna WS-C2960X-xxxS-L. [39] Ett fåtal switchar användes för experiment. De modeller som användes valdes dels på grund av lättillgänglighet men även på grund av dess motsvarighet i funktion för de C2960X-modeller som användes i kundens nätverksmiljö. Vid testutförandet användes modell WS-C3560-24TS-S med firmware 15.0(2)SE11 (c3560-ipservicesk9-mz.150-2.SE11.bin).

7.4. Funktionstest av metod för indikation av aktivitet

Ett flertal tester genomfördes för utvärdering av den mest lämpliga metoden för information om passerad tid sedan en switch-port senast använts. Följande stycke beskriver egenskaperna hos de olika tillvägagångssätten.

7.4.1. Status för fysisk länk

Bevakning av en switch-port kan ske för att indikera huruvida fysisk länk är aktiv eller inte. För en fungerande funktion behövs en kontinuerlig kontroll göras i intervaller då en användare i vissa fall kan använda datorn i kortare perioder för att därefter ha den avstängd. För att aktivitet ska identifieras behövs kontroll av status för porten inträffa minst en gång under den tidsperiod då användaren har datorn påslagen. Nackdelen med basering av aktivitet med denna metod är att inhämtning måste ske kontinuerligt med kontroll av status, då resultaten annars inte kan ses som tillförlitliga.

7.4.2. Senaste Aktivitetsändring

I en situation där en dator sätts på eller stängs av påverkas den fysiska status för länken, detta indikerar en ändring av status för den switch-port den är ansluten till. Testutförande visade att förutom en ändring av den fysiska länken även andra faktorer kunde bidra med en ändring av status för en switch-port. En påverkan kunde till exempel göras med en manuell avaktivering av porten genom att utföra kommandot

19

”admin shutdown”. På grund av detta kan information om aktivitet i vissa fall bli missvisande då en manuell ändring av konfiguration ger utslag om aktivitet på switch-porten.

7.4.3. Senast mottagna paket

Enligt testutförande kunde endast paket genererad av controlplane indikera aktivitet för en switch-port. Paket som i första hand används i kommunikation av switchar räknas till denna kategori och skiljer sig mot data- och managementplane som är vanlig data-trafik mellan klienter eller kommunikation för styrning av nätverksenheter som exempelvis switchar [32], [41]. Det betyder att kommunikation från en annan switch ger indikation för inkommande trafik då den finns ansluten till en switch-port medan annan utrustning som exempelvis en dator eller skrivare normalt inte genererar trafik på controlplane, därav ses ingen indikation på inkommande paket från dessa enheter. Aktivitet hos en switch-port i syftet lämpar sig därför mindre bra för basering på inkommande paket om den anslutna enheten är en annan en switch.

7.4.4. Senast skickade paket

Normalt är protokoll som Cisco Discovery Protocol (CDP), spanning-tree, Dynamic Trunking Protocol (DTP) och keepalive aktiverade som standard i flera av Ciscos programvaror för flera modeller av switchar. Paket genereras i olika intervall beroende på protokoll och skickas ut på switch-porten. Vid en aktiv länk, oberoende på vilken enhet som finns ansluten till switch-porten kommer dessa paket att genereras av switchen och därför indikeras på switch-porten. I det fallet en länk blivit aktiv, i form av att en enhet, som exempelvis en dator är ansluten kommer en indikation av utgående paket att kunna registreras på switch-porten. När datorn sedan stängs av eller avvecklas blir länken åter inaktiv och utgående controlplane trafik slutar genereras. Information om tidpunkten för den senaste aktiviteten för utgående trafik kan då ses i efterhand och användas i syfte för indikation om en eventuellt ledig switch-port. Vid testutförande avaktiverades samtliga protokoll i controlplane för en switch-port, det kunde därefter bekräftas att ingen indikation på utgående paket kunde ses för att bevisa hypotesen om endast trafik i controlplane registreras.

7.4.5. Val av metod för indikation av aktivitet

Flera av de metoder som beskrivs i stycke 7.1 – Metod för kännedom om aktivitet kunde efter kontroll användas som indikator för aktivitet med varierande resultat. Den som efter eget testutförande kunde ses som tillförlitlig var information från senast skickade paket hos en switch-port. Registrering av aktivitet görs inom 10 sekunder med standardinställning för en switch av modell som nämnts tidigare under sektionen 7.2 - Genererad trafik i controlplane hos en switch. Status baserat på paketräkning har vid eget testutförande visat sig ge en påvisande god avspegling om status för ansluten enhet. Det i syftet något bättre än IF-MIB::ifLastChange då information som baseras på senast skickade paket inte har samma möjlighet att manipuleras genom manuella ändringar av inställningar i switchen. Något som i det fallet kan riskera feltolkade resultat. Motivering till beslutet baserades därmed på tillförlitligheten i informationen i syfte att endast påvisa status för en ansluten och påslagen enhet. Metoden ”senast skickade paket” valdes därför som grund för informationshämtning av aktivitet hos en switch-port.

7.5. Metod för kommunikation mellan server och switch

Som tidigare nämnt enligt val av metod sågs de kommunikationsmodellerna där direkt kommunikation mellan server och switch som de mest aktuella i detta arbete. Metoderna som då kvarstod var anslutning via SSH eller telnet och SNMP-poll. SSH valdes framför telnet på grund av att protokollet bidrar till säkrare kommunikation mellan parter där exempelvis autentieringsuppgifter inte visas i clear text, något som kan observeras vid exempelvis en man-in-the-middle attack. I valet mellan SNMP-poll och SSH valdes SSH inledande som lösning, detta på grund av tidsaspekten för arbetet och för att författaren tidigare haft kunskaper inom området vilket underlättade att genomföra en automatisk lösning inom rimlig tid. Eftersom arbetet fortlöpte utan problem valdes det att fortsätta med denna metod. En undersökning för vilka metoder som fanns att tillgå via SNMP-poll gjordes sedan i efterhand, vilket har sammanställts i följande stycke.

7.5.1. SNMP-poll

Beroende på vilken information som efterfrågas kan olika MIB anropas som finns relaterat till syftet för kontroll av aktivitet eller annan information om aktuell switch-port. Exempelvis existerar flera MIB som visar paketräkning för in- och utgående paket för aktuellt interface och länk-status för interface. För information om en komplett lista av interface kan bland annat, som även nämns tidigare, OID IF-MIB::ifDescr (1.3.6.1.2.1.2.2.1.2) [20] (se även bilaga B) anropas med snmp walk. Interface kan då

20

identifieras och exempelvis kopplas till en nummerordning i en lista. Intressant information kan därefter inhämtas från övriga MIB-träd kopplat till vardera interface och presentation av en tabell med summerad information som kan genereras för en användare. Anrop till IF-MIB::ifDescr visar både virtuella interface (exempelvis VLAN) och fysiska interface (switch-portar). Som tidigare nämnt kan cieIfLastOutTime (1.3.6.1.4.1.9.9.276.1.1.1.1.2) [21], som finns placerat i trädet CISCO-IF-EXTENSION-MIB användas för relevant informationsinhämtning. Med hjälp av cieIfLastOutTime kan en exakt tid sedan beräknas sedan det senast använts. snmp walk kan sedan utföras för trädet CISCO-IF-EXTENSION-MIB för informationsinhämtning för samtliga interface. För informationsinhämtning för enskilda interface kan istället snmp get utföras mot aktuellt interface, interface nummer ett skulle då finnas lokaliserat på adress cieIfLastOutTime.10001 (1.3.6.1.4.1.9.9.276.1.1.1.1.2.10001). Då svar som ställs till aktuell cieIfLastOutTime presenteras i ”timeticks” och den enhet som används är fortlöpt tid i hundradels sekunder [21]. ”Timeticks” motsvarar det tillfälle då det senaste paketet som registreras för ett interface gjorts sedan enheten startats. Som nämns tidigare enligt eget testutförande registrerades endast paket som processerats i controlplane. Med standardinställningar för en switch-port registrerades aktivitet som lägst var tionde sekund vid det tillfälle en aktiv enhet funnits ansluten. För att se fortlöpt tid är det möjligt att subtrahera värdet med det totala antalet ”timeticks” sedan enheten startades och sedan dividera med hundra för att presentera värdet i sekunder. En MIB som kan användas i syftet för visning av total tid en enhet har varit påslagen presenterat i sekunder är: SNMP-FRAMEWORK-MIB::snmpEngineTime.0 (1.3.6.1.6.3.10.2.1.3) [37]. Bevakning sker för tjänsten SNMP-agent, men kan användas som indikator för hur länge en enhet har varit påslagen. Eftersom tjänsten för SNMP-agent väldigt sällan startas om kan den användas med generellt god trovärdhet användas i syftet. En unik MIB finns i syftet för uptime hos en enhet, sysUpTimeInstance (1.3.6.1.2.1.1.3.0) [38], dock finns en begränsning på 32-bitars värde hos MIB, vilket gör en begränsning på cirka 497 dagar (2^32/100/60/60/24 = 497). Passeras detta värde börjar den om från noll. snmpEngineTime.0 har en enhet som baseras på hela sekunder istället för hundradels sekunder, därför råder inte samma begränsning för samma antal bitar (2^32/60/60/24 = 49710 dagar) [40]. Problemet visade sig på en av de switchar i produktionsmiljön och verifieras i Bilaga C. Då det inte är ovanligt med tid på upp till flera år för en switch lämpar sig användning av snmpEngineTime.0 som informationskälla troligtvis bättre i syftet med detta arbete. Samma problem påverkar även samtliga tidigare nämnda OID som cieIfLastOutTime och locIfLastOut. Ingen funktionskontroll gjordes för en switch-port vars status varit inaktiv i mer än 497 dagar. Se bilaga B för utförliga tester beräkning och verifiering av funktion.

7.6. Framtagandet av lösning med SSH

Ett script utvecklades i syftet för en automatisk lösning. Det byggdes upp i olika funktioner, detta för att underlätta testning i olika faser, oberoende av varandra. På grund av detta kunde ändring göras i en funktion som kunde testas utan att initiera andra funktioner. Upprepad inhämtning av information kunde på detta sätt undvikas. Kommande stycke beskriver mer ingående de olika funktionerna hos scriptet samt val av server, kommunikation och placering.

7.6.1. Åtkomst till data

Vi inhämtning av relevant information exekverades flera kommandon i en följd. Följande kommandon angivna nedan användes på switch. Informationen från exekverade kommandon sparades sedan lokalt på servern i obehandlad form.

terminal length 0 – kommandot avaktiverar behovet av användarens interaktion vid utskrifter som är

längre än en helskärm med efterföljande paus. Det möjliggör istället konstant flöde utan pauser vilket är en förutsättning för funktionen av automatisk funktionalitet vid inhämtning av data utan mänsklig interaktion.

show clock – visar aktuellt datum för insamlingen av data från enheten, vilket är en förutsättning för

verifiering av att informationen är aktuell och tagits emot vid det tänkta datumet.

show interfaces – visar flera funktioner hos interfacet: ”status” där ett interface kan vara konfigurerade

att fungera i olika lägen. Exempel på detta kan vara ”monitoring” vilket är en status som visas om interfacet har konfigurerats till att duplicera data från annan switch-port eller VLAN, även kallat SPAN eller RSPAN. En annan kan vara ”disabled” som status vilket betyder att switch-porten manuellt är inställt till att vara avaktiverad. Annan information som visas är ”description” som