I ett större nätverk är det i synnerhet önskvärt att övervaka kritiska objekt. Dessa objekt kan vara gränssnitt på routrar och switchar, fysiska enheter och servrar eller sådant som begränsar nätverkets funktionalitet som hög bandbreddsanvändning. En annan viktig detalj att övervaka är förändringar i nätet så som konfigurationskorrigeringar samt förändringar genererade av routingprotokoll eller Spanning Tree Protocol. Att ha en nätverksomspännande och strikt övervakning är en av stöttepelarna i att konstruera driftsäkra nätverksmiljöer.
2.2.1 Syslog
Nätverksenheten som har övervakning aktiverad genererar någon form av varning eller meddelande varvid detta meddelande måste sparas för att uppfylla någon egentlig nytta i ett övervakningssystem. Ett alternativ är att spara meddelandet på den fysiska enheten, men en mer effektiv och överskådlig lösning skulle vara att centralisera alla övervakningsmeddelanden från samtliga enheter till en gemensam databas. Det underlättar för den person som tvingas gå tillbaka bland alla sparade meddelanden för att tydliggöra vad som orsakade ett eventuellt fel i nätverket. Denna centraliserade lösning för felmeddelanden kan mycket väl vara en implementation av en syslogserver till vilken alla övervakande enheter skickar sina varningar eller meddelanden.
Figur 2-11: Signaleringsprincip för övervakning
En syslogserver är en enhet som har en mjukvara installerad ämnad för att ta emot syslogmeddelanden och spara dem i en databas. En vanlig mjukvara är Kiwi Syslog som är Microsoft Windows-baserad och mycket marknadsfrekvent förekommande variant av syslogserver men som också stödjer andra typer av övervakningsprotokoll förutom syslog. Kiwi Syslog finns dels i en licenserad och en gratisversion som är lätt konfigurerad varpå det finns mycket material på Internet om hur Kiwi Syslog integreras i ett nätverk men att detta inte tas upp inom denna rapports omfattning [KIWI].
Syslog är en standardiserad [RFC3164] form för att skicka meddelanden till en enhet som sedan sparar och analyserar dess innehåll. Dessutom stöds syslogmeddelanden av en bred enhetsvariation som inte är tillverkarspecifik. Den övervakande enheten skickar ett datapaket på 1024 Bytes till den mottagande syslogservern över UDP-port 514 och/eller TCP-port 5000, vilket är standardportarna för syslogkommunikation. I och med att meddelanden primärt skickas via UDP kommer inte syslogservern svara med ett TCP-ACK som bekräftar att den mottog meddelandet. Detta medför att flödeskontroll i form av QoS bör implementeras för syslogmeddelanden. Meddelandenas kritiska prioritet delas in i åtta nivåer representerade av åtta bitar i syslogmeddelandet enligt följande [CISCO7]: Kritisk prioritet 0 - Emergency 1 - Alert 2 - Critical 3 - Error 4 - Warning 5 – Notice 6 – Information 7– Debug
Enheter skickar syslogmeddelanden som märkts med en viss prioritet vilket möjliggör att de lätt kan sorteras efter kritisk grad. Dessutom kan meddelandena innehålla tidsangivelse samt numrering för ökad sorteringsmöjlighet [CISCO7].
Att inkludera någon form av övervakning anses som obligatoriskt i en optimerad nätverksmiljö och därför ingår konfiguration för syslog på de enheter som anses vara i störst behov av detta. En optimering innebär inte enbart att införa övervakning utan också sätta upp regler för vilka enheter som är i behov av denna typ av övervakning. Om Ciscos Network Design Model tas i beaktning med dess uppdelning i corelager, distributionslager samt accesslager utgör core- och distributionslagren de som är direkt kritiska för nätverket i stort och bör därför prioriteras i en övervakningsmodell. Även accesswitcharna kan komma att behöva någon form av övervakning men är mindre kritiska för andra än nätverksanvändarna som är fysiskt inkopplade till just den accesswitchen. Därför begränsas syslogmeddelanden med låg kritisk prioritet till core- och distributionslagren medan accesswitcharna endast tillåts skicka syslog meddelanden med högre kritisk prioritet.
Syslogkonfigureras i den optimerade nätverksstrukturen enligt följande på coreswitchar och distributionsswitchar:
Switch(config)# service sequenze-numbers
Switch(config)# service timestamps log datetime localtime msec Switch(config)# logging source-interface loopback0
Switch(config)# logging host 10.1.1.24 Switch(config)# logging trap 5
I ovanstående konfiguration framgår att syslogmeddelanden kommer innehålla sekvensnummer och en tidsmarkering inkluderandes millisekunder. Dessutom specificeras avsändaradressen på meddelandet till switchens loopbackadress som också fungerar som ID för enheten. Alla meddelanden kommer senare skickas till den syslogserver som finns i nätverket och dess IP-adress 10.1.1.24/23. Här har meddelandenas kritiska prioritet specificerats till 5, vilket kommer aktivera en större mängd felkällor till att övervakas [CISCO7].
Syslogkonfigureras i den optimerade nätverksstrukturen enligt följande på accesswitchar:
Switch(config)# service timestamps log year datetime localtime msec Switch(config)# logging source-interface vlan 100
Switch(config)# logging host 10.1.1.24 Switch(config)# logging trap 3
Switch(config)# logging on
I ovanstående konfiguration framgår likt den för core- och distributionsswitchar att syslogmeddelanden kommer innehålla en tidsmarkering inkluderandes millisekunder och år. Här specificeras dock avsändaradressen på meddelandet till switchens administrativa VLAN 100. Alla meddelanden kommer senare skickas till den syslogserver som finns i nätverket och dess IP-adress 10.1.1.24/23. Här har meddelandenas kritiska prioritet specificerats till 3 som därmed kommer att övervaka felmeddelanden av mer allvarlig karaktär, just för att slippa de vardagliga meddelanden som normalt uppstår på accesswitchar i och med alla användare som dagligen kopplar till och från [CISCO7].
2.2.2 Bandbreddsövervakning med PRTG
Med dagens krav på tillgänglighet i datornätverk krävs att full förståelse finns för varför eventuella fel i nätet uppstår. Detta kan göras med hjälp av en syslogserver som föregående kapitel avhandlade. Dock genereras bara ett syslogmeddelande när något mer eller mindre kritiskt framtvingat måste meddelas, inte om nätverket dras med övriga fel och brister vilket får nätverksanvändarna att klaga över att funktionaliteten är dålig eller som man brukar säga, att nätverket går segt [CISCO8].
Detta leder nätverksövervakningen in i en annan fas där övervakning också krävs passivt och i realtid för att upptäcka flaskhalsar som bidrar till att datatrafik stockas på överanvända kommunikationsgränssnitt eller enheter. Denna typ av datatrafikstockning har störst riskmöjlighet att uppstå på länkar som sammanbinder större segment, då främst i distributionslagren.
I enlighet med Figur 2-12 kan antas att tre datorer inkopplade i varsin switch bildar segmentet A som skickar en stor mängd datatrafik till ett annat likadant segment kallat B. På samma sätt skickar segment B stora mängder data till segment A. Trafiken färdas över länk C som därmed blir tre gånger så belastad som länkarna från respektive dator. Därför bildar länk C en flaskhals där problem kan uppstå och de två segmenten kan uppleva att nätverket inte skickar datatrafik optimalt med trafikstockning som orsak. Ingen aktuell lösning finns för att övervaka liknande överbelastade länkar som den beskriven i början av detta avsnitt, utan på uppdragsgivarens önskan skall en sådan ingå i den optimerade nätverksversionen.
Eftersom länkarna mellan enheterna i nätet har en bestämd hastighet är övervakningen tämligen enkel och går ut på att bestämma hur många procent av den totala bandbredden som används. Logiskt kan sägas att ju närmre hundra procents bandbreddsanvändning som används ju mindre optimal är lösningen och ju fler problem med trafikstockning kommer uppstå. Vad som behövs är en implementation av något som kan övervaka hur mycket av bandbredden som används på ett givet gränssnitt.
I och med uppdragsgivarens behov och önskemål om en skarp implementering i VMKF:s nätverk togs först en marknadsundersökning fram som innefattade de två vanligaste varianterna för att övervaka bandbreddsanvändning på nätverksenheternas kommunikationsgränssnitt.
Netflow är ett Ciscoproprietärt protokoll som kan användas för att övervaka bandbredd, trafik som florerar i nätverket, säkerhet och anormal nätverksanvändning samt en rad andra detaljer. Ett mycket kraftfullt protokoll som använt på rätt sätt ger en nätverkstekniker all den nödvändig information som krävs för att skapa driftsäkra nätverksmiljöer. Dess huvudsakliga styrka är att Netflow inte bara exempelvis läser av hur mycket bandbredd som används utan delar in trafikflödena utifrån vilken klient som skickat trafiken samt mer specifikt vilken typ av trafik det är, detta genom att inspektera paketens TCP/IP-parametrar [CISCO9].
SNMP är ett protokoll som huvudsakligen hanterar övervakning och administration av enheter så som nätverksutrustning men också servrar eller andra liknande tjänster. SNMP förekommer i tre versioner, version 1, 2 och 3, där den senare är en vidareutveckling av den föregående och således innefattar fler funktioner. Idén bakom SNMP är att nätet består av så kallade agenter och en central NMS som därefter kommunicerar med agenterna och begär den information som krävs för att NMS- enheten ska göra det den är instruerad att göra. Agenterna är nätverksenheterna, medan NMS- enheten är en server med en mjukvara som hanterar den information som samlas in via SNMP, ofta till att skapa databaser eller rita grafer [CISCO8] [DADA].
De främsta tre grundkommandona som används av SNMP är läs, skriv och fånga (read, write, trap). Läs-kommandot används av NMS-enheten för att hämta information från agenter, medan skriv- kommandot också tillåter en NMS-enhet att korrigera inställningar på agenterna. Fånga-kommandot används dessutom för att agenterna själva ska meddela NMS-enheten om något av vikt skett på agenten [CISCO8] [DADA].
Den information som NMS-enheten önskar få åtkomst till finns på agenterna som variabler sorterade efter så kallad MIB. Det är genom att eftersöka värdet för en speciell MIB som NMS-enheten kan få information och den eftersökta enheten. Agenten lagrar exempelvis information om hur mycket minne som finns tillgängligt i en unik MIB medan värdet för hur många megabyte data som skickats på ett typiskt gränssnitt lagras i en annan MIB. Agenterna har således en mängd olika MIB varifrån NMS-enheten läser information genom en protokolloperation kallad Get. Exempel på hur en MIB ser ut är 1.3.6.1.4.1.9.3.3.1, vilket är hur många AppleTalk-paket som agenten mottagit [CISCO8] [DADA]. I och med principen att en NMS endast begär trafik från en specifik agent när NMS-enheten så kräver, fylls inte nätverket med onödigt mycket SNMP-trafik kontinuerligt genererade av agenterna vid ett visst intervall. Därför kan det sägas att SNMP är väldigt resursbesparande.
I realtidsövervakningssystemet avsett för att övervaka bandbredd på enheter inom VMKF:s nät valdes mjukvaran PRTG Traffic Grapher version 6.2.2.983/984 från datumet fjortonde maj år 2009 [PRTG1]. PRTG Traffic Grapher är en mjukvara för Microsoft Windows-plattformar vilket då lätt kunde integreras i VMKF:s befintliga Windows Server-miljö, och stödjer både SNMP samt Netflow. PRTG Traffic Grapher är framtaget av företaget Paessler som till stor del koncentrerat sig på nätverksövervakning och därmed är också mjukvaran PRTG Traffic Grapher exklusivt konstruerad för ändamålet. PRTG Traffic Grapher förekommer i en gratisversion som fritt får användas för privat och kommersiellt bruk trots vissa avgränsade funktioner. Den licenserade versionen finns i flera utföranden där varianten Enterprice 500 enligt Paesslers hemsida kostar €700 och är limiterad till femhundra sensorer. Den version som aktivt används i VMKF:s nätverk för övervakning är gratisversionen men efter konsultation med uppdragsgivaren planeras ett inköp av licensversionen i framtiden. Efter vidare undersökningar och diskussion med uppdragsgivaren konstaterades att en Netflow-licens till priset av €400 inte kunde konkurrera med den kostnadsfria SNMP-lösningen [PRTG2] [PRTG3].
Rapporten kommer inte att behandla hur mjukvaran PRTG Traffic Grapher skall implementeras utan i det avseendet hänvisas till Paesslers hemsida för vidare dokumentation. Hur SNMP aktiveras på nätverksenheterna följer enligt nedan:
Switch(config)# access-list 2 permit 10.1.1.25
Switch(config)# snmp-server community PRTG_M0NITOR RO 2
Vad ovanstående access-lista förtäljer är att den tillåter enbart en IP-adress, nämligen den som är konfigurerad på den server där PRTG Traffic Grapher är installerat, detta för att i nästa kommando använda samma access-lista för att endast tillåta nämnda server där PRTG Traffic Grapher är installerat till att läsa information från agenten. I samma kommando anges en så kallad community till PRTG_M0NITOR (där bokstaven O bytts ut mot siffran noll efter M:et i M0NITOR). Denna community kan sägas vara ett lösenord för kommunikationen [DADA] [WLCH].
Med konfigurationen för SNMP genomförd på samtliga enheter som önskas övervakas börjar sedermera PRTG Traffic Grapher att hämta hem nödvändig information och kan på så vis rita upp grafer över hur bandbredd används på agenternas kommunikationsgränssnitt. Därmed har de krav på ökad kontroll och nätverksförståelse uppfyllts i enlighet med uppdragsgivarens ursprungligt uppsatta mål.
Figur 2-13: Grafer från PRTG Traffic Grapher