Nu när ditt nätverk är kartlagt med hjälp av CDP eller LLDP och alla komponenter är synkroniserade via NTP, är det dags att se hur du kan hantera nätverket med hjälp av Simple Network Management Protocol (SNMP).

SNMP utvecklades för att ge administratörer möjlighet att hantera noder i ett IP-nätverk – såsom servrar, arbetsstationer, routrar, switchar, brandväggar och andra säkerhetsenheter. Protokollet gör det möjligt att övervaka och styra nätverksprestanda, identifiera och lösa problem samt planera för framtida tillväxt.

Ett SNMP-system består av tre grundläggande komponenter:

• SNMP-manager
• SNMP-agenter (hanterade noder)
• Management Information Base (MIB)

SNMP konfiguration

SNMP är ett applikationslagerprotokoll som tillhandahåller ett meddelande format för kommunikation mellan managers och agenter. För att konfigurera SNMP på en nätverksenhet måste man först definiera förhållandet mellan managern och agenten.

SNMP-managern är en del av ett nätverkshanteringssystem (NMS) och kör SNMP-hanterings programvara. Som illustreras i figuren kan SNMP-managern samla in information från en SNMP-agent med hjälp av åtgärden get, och även ändra konfigurationer på agenten med åtgärden set. Dessutom kan SNMP-agenter skicka information direkt till en nätverks manager med hjälp av traps.

SNMP-agenten och MIB finns på SNMP-klienten. Nätverksenheter som behöver hanteras – till exempel switchar, routrar, servrar, brandväggar och arbetsstationer – kör en SNMP-program modul. MIB:er lagrar data om enheten och dess driftstatistik, och är avsedda att vara tillgängliga för autentiserade fjärranvändare. Det är SNMP-agentens uppgift att tillhandahålla åtkomst till den lokala MIB.

SNMP definierar hur hanterings information utbyts mellan nätverkshanteringsapplikationer och hanterings agenter. SNMP-managern använder UDP-port 161 för att göra förfrågningar till agenterna och deras MIB:er. SNMP-agenter skickar traps till SNMP-managern via UDP-port 162.

Hur SNMP fungerar

SNMP-agenter som finns på hanterade enheter samlar in och lagrar information om enheten och dess funktion. Denna information sparas lokalt i MIB (Management Information Base). SNMP-managern använder sedan agenten för att komma åt informationen i MIB.

Det finns två primära typer av förfrågningar från SNMP-managern: get och set.

• En get-förfrågan används av NMS (Network Management System) för att hämta data från enheten.
• En set-förfrågan används för att ändra konfigurations variabler på agent enheten.

En set-förfrågan kan även initiera åtgärder på enheten. Till exempel kan den användas för att:

• starta om en router,
• skicka en konfigurationsfil, eller
• ta emot en konfigurationsfil.

SNMP-managern använder alltså get– och set-kommandon för att övervaka och styra nätverksenheter, enligt de funktioner som sammanfattas i tabellen.

Operation	Beskrivning
get-request	Hämtar ett värde från en specifik variabel
get-next-request	Hämtar ett värde från en variabel inom en tabell; SNMP-managern behöver inte känna till det exakta variabelnamnet. En sekventiell sökning utförs för att hitta den nödvändiga variabeln i tabellen.
get-bulk-request	Hämtar stora datamängder, såsom flera rader i en tabell, som annars skulle kräva överföring av många små datamängder. (Fungerar endast med SNMPv2 eller senare)
get-response	Svarar på en get-request, get-next-request och set-request som skickats av ett NMS
set-request	Lagrar ett värde i en specifik variabel

Hur SNMP-agenten svarar på förfrågningar

SNMP-agenten svarar på förfrågningar från SNMP-managern på följande sätt:

• Hämta (get) en MIB-variabel – När SNMP-managern skickar en GetRequest-PDU hämtar agenten värdet för den begärda MIB-variabeln och skickar tillbaka detta värde som svar.
• Ändra (set) en MIB-variabel – När SNMP-managern skickar en SetRequest-PDU ändrar agenten värdet på den aktuella MIB-variabeln till det värde som specificerats i förfrågan. Svaret från agenten innehåller då de nya inställningarna som har tillämpats på enheten.

Figuren visar hur en SNMP GetRequest används för att kontrollera om interfacet G0/0/0 har statusen up/up.

SNMP-agentens traps

Ett NMS (Network Management System) skickar regelbundet get-förfrågningar till SNMP-agenter på hanterade enheter för att hämta information. Genom dessa förfrågningar kan nätverkshanteringsapplikationen samla in data för att övervaka trafikbelastning och kontrollera att enheternas konfigurationer är korrekta. Informationen kan visas grafiskt i NMS, där man till exempel kan beräkna medelvärden, min- och maxvärden, rita grafer eller sätta tröskelvärden som vid överskridande utlöser en notifikation.

Ett exempel är övervakning av CPU-användning på en Cisco-router. SNMP-managern hämtar regelbundet dessa värden och presenterar dem i grafer som nätverksadministratören kan använda för att skapa ett grundvärde, generera rapporter eller följa aktuell status i realtid.

Men periodisk SNMP-pollning (engelska polling) har vissa nackdelar. Det finns en fördröjning mellan att en händelse inträffar och att NMS upptäcker den, eftersom den bara märks vid nästa förfrågan. Dessutom finns en balansgång mellan hur ofta pollning sker och hur mycket bandbredd som används.

För att hantera detta kan SNMP-agenter skicka så kallade traps – spontana meddelanden som omedelbart varnar SNMP-managern om att en specifik händelse har inträffat. Exempel på sådana händelser är felaktig autentisering, omstart av en enhet, förändringar i länkstatus (upp eller ner), spårning av MAC-adresser, stängning av en TCP-anslutning, eller förlust av anslutning till en grannnod. Eftersom traps inte kräver att NMS först ställer en fråga, minskar de belastningen på både nätverket och SNMP-agenterna.

I figuren visas ett exempel där en SNMP-trap används för att varna administratören om att gränssnittet G0/0/0 har gått ner. NMS-programvaran kan då exempelvis skicka ett SMS till administratören, visa ett popup-fönster eller markera routerns ikon i rött i det grafiska gränssnittet.

Utbytet av alla SNMP-meddelanden illustreras i figuren.

SNMP-versioner

Det finns flera versioner av SNMP:

• SNMPv1 – Detta är det ursprungliga Simple Network Management Protocol, en Full Internet Standard, som definieras i RFC 1157.
• SNMPv2c – Denna version definieras i RFC 1901 till 1908. Den använder ett administrativt ramverk baserat på community strings.
• SNMPv3 – Detta är ett interoperabelt, standard baserat protokoll som ursprungligen definierades i RFC 2273 till 2275. Det tillhandahåller säker åtkomst till enheter genom att autentisera och kryptera paket över nätverket. Det inkluderar följande säkerhetsfunktioner:
  • Meddelandes integritet för att säkerställa att ett paket inte har manipulerats under överföring,
  • Autentisering för att avgöra att meddelandet kommer från en giltig källa,
  • Kryptering för att hindra obehöriga från att läsa innehållet i ett meddelande.

SNMP-versioner och säkerhet

Alla versioner av SNMP använder samma grundläggande komponenter: SNMP-managers, agenter och MIB:er. Cisco IOS-programvara stöder tre versioner av SNMP: version 1, 2c och 3. Eftersom SNMPv1 är en äldre lösning som numera sällan används i moderna nätverk, fokuserar denna kurs främst på SNMPv2c och SNMPv3.

Både SNMPv1 och SNMPv2c använder en community-baserad säkerhetsmodell. Det innebär att åtkomsten till en agents MIB styrs av en så kallad community string – en form av lösenord som definierar vilka managers som får läsa eller skriva data.

SNMPv2c skiljer sig från SNMPv1 genom att erbjuda två viktiga förbättringar:

• Bulk retrieval: en funktion som effektivt hämtar stora mängder data, till exempel hela tabeller, vilket minskar antalet meddelanden som behöver skickas.
• Förbättrad felhantering: felkoder i SNMPv2c kan ange vilken typ av fel som uppstått. I SNMPv1 rapporteras alla fel med en enda generell kod, vilket gör felsökning mer begränsad.

Observera: Både SNMPv1 och SNMPv2c har mycket begränsade säkerhetsfunktioner. De kan varken autentisera avsändaren av ett SNMP-meddelande eller kryptera innehållet.

SNMPv3 däremot, som är mest aktuellt beskriven i RFC 3410 och 3415, innehåller omfattande säkerhetsfunktioner för att skydda kritisk nätverksinformation. Det inkluderar autentisering, meddelande integritet och kryptering.

SNMPv3 introducerar även två viktiga säkerhetsbegrepp:

• Säkerhetsmodell – en autentiserings strategi kopplad till en användare och dess tillhörande grupp.
• Säkerhetsnivå – den tillåtna säkerhetsgraden inom en viss säkerhetsmodell.

Kombinationen av säkerhetsmodell och säkerhetsnivå avgör vilken säkerhetsmekanism som används när ett SNMP-paket hanteras. De tillgängliga säkerhetsmodellerna i SNMP är: SNMPv1, SNMPv2c och SNMPv3.

I följande tabell presenteras egenskaperna för olika kombinationer av säkerhetsmodeller och säkerhetsnivåer.

En nätverksadministratör måste konfigurera SNMP-agenten att använda den SNMP-version som stöds av den aktuella hanterings stationen. Eftersom en SNMP-agent kan kommunicera med flera olika SNMP-managers är det möjligt att konfigurera programvaran så att den samtidigt kan hantera kommunikation enligt SNMPv1, SNMPv2c och SNMPv3. Detta gör det flexibelt att anpassa lösningen efter olika behov och säkerhetsnivåer i nätverket.

Community Strings

För att SNMP ska fungera måste NMS (Network Management Station) ha åtkomst till MIB (Management Information Base). Åtkomsten måste autentiseras för att säkerställa att förfrågningarna är giltiga.

I SNMPv1 och SNMPv2c sker denna autentisering med hjälp av community strings – alltså lösenord i klartext som styr åtkomsten till MIB. Community strings används för att autentisera och kontrollera om användaren har rätt att läsa eller ändra objekt i MIB.

Det finns två typer av community strings:

• Read-only (ro): Ger endast läsbehörighet till MIB-variabler. Användaren kan se information men inte ändra något. På grund av den låga säkerhetsnivån i SNMPv2c väljer många organisationer att enbart använda read-only-läge.
• Read-write (rw): Ger både läs- och skrivbehörighet, vilket innebär att användaren kan både hämta och ändra information i MIB.

För att visa eller ändra MIB-variabler måste rätt community string anges, beroende på om det gäller läs- eller skriv åtkomst.

I följande exempel visas hur SNMP fungerar i praktiken med hjälp av en community string.

MIB Object ID

MIB (Management Information Base) organiserar sina variabler i en hierarkisk struktur. Dessa MIB-variabler gör det möjligt för administrationsprogramvara att övervaka och styra nätverksenheter. Varje variabel i MIB definieras formellt som ett Object ID (OID), vilket är ett unikt identifieringsnummer för varje hanterat objekt i hierarkin.

Strukturen följer standarder som definieras i olika RFC, och visualiseras ofta som ett träd där varje gren representerar ett specifikt område. Vissa grenar innehåller variabler som är gemensamma för de flesta nätverksenheter, medan andra är specifika för en viss tillverkare eller enhetstyp.

Dessa RFC definierar ett antal publika och gemensamma MIB-variabler, som stöds av de flesta enheter. Utöver detta kan tillverkare som Cisco skapa egna privata grenar i MIB-trädet för att lägga till nya variabler som är unika för deras produkter.

Figuren visar exempel på delar av MIB-strukturen som är definierade av Cisco. Lägg märke till hur en OID kan anges antingen i textform eller som en sekvens av siffror, vilket hjälper till att hitta en specifik variabel i trädet. Cisco-tillhörande OID numreras till exempel enligt följande:
.iso (1).org (3).dod (6).internet (1).private (4).enterprises (1).cisco (9)
Detta ger Cisco:s OID-prefix: 1.3.6.1.4.1.9

SNMP Polling-scenario

SNMP kan användas för att övervaka CPU-användning över tid genom att nätverksenheter regelbundet pollas – det vill säga att NMS (Network Management Station) skickar återkommande förfrågningar för att hämta aktuell information. Ett vanligt exempel är insamling av statistik över CPU-belastning, som sedan kan presenteras i form av grafer. Detta skapar en baseline, alltså en normalnivå som nätverksadministratören kan använda som referensvärde vid felsökning och larm hantering.

När en baseline är etablerad kan tröskelvärden definieras. Om CPU-användningen överskrider dessa gränsvärden skickas notifieringar eller larm till administratören. I figuren visas ett exempel på 5-minutersintervaller av CPU-användning från en router, insamlade under flera veckor.

Den aktuella datan hämtas med hjälp av kommando snmpget, som körs från NMS. Med snmpget kan du antingen hämta realtidsdata manuellt eller automatisera rapportering under en viss tidsperiod för att beräkna medelvärden.

För att använda snmpget krävs följande parametrar:

• SNMP-version (t.ex. v1, v2c eller v3)
• Rätt Community string (lösenordet för åtkomst)
• IP-adressen till den enhet som ska frågas
• Den specifika OID (Object Identifier) för den MIB-variabeln som ska läsas

Figuren visar ett exempel på hur det kostnadsfria verktyget snmpget används för att snabbt hämta information från MIB-strukturen.

snmpget kommandot har flera parametrar, bland annat:

• -v2c – Anger versionen av SNMP.
• -c community – Community string, alltså SNMP-lösenordet.
• 10.250.250.14 – IP-adressen till den övervakade enheten.
• 1.3.6.1.4.1.9.2.1.58.0 – OID till MIB-variabeln.

Den andra raden visar en förkortad version av MIB-variabeln, följt av det aktuella värdet på den platsen i MIB:en. I detta fall är värdet 11, vilket motsvarar en CPU-belastning på 11 procent i snitt under de senaste 5 minuterna.

Tidsintervallet på 5 minuter framgår inte direkt av själva värdet eller utskriften, utan måste tolkas genom att förstå vad värdet på OID representerar. I detta fall är 1.3.6.1.4.1.9.2.1.58.0, som tillhör Cisco:s privata MIB och motsvarar objektet avgBusy5 – ett MIB-objekt som Cisco definierar för att visa ett rullande 5-minutersgenomsnitt av CPU-användningen.

SNMP Object Navigator

Verktyget snmpget ger en grundläggande inblick i hur SNMP fungerar i praktiken. Det visar hur enskilda MIB-variabler kan hämtas från nätverksenheter. Att arbeta med långa och kryptiska OID:er, som till exempel 1.3.6.1.4.1.9.2.1.58.0, kan dock vara opraktiskt och svårt för många nätverkstekniker.

I verkligheten använder nätverks driftspersonal oftast ett nätverks övervakningsprogram med ett användarvänligt grafiskt gränssnitt (GUI), där MIB-variabler och OID:er hanteras automatiskt i bakgrunden. Det gör att nätverkstekniker slipper hantera de långa numren direkt, vilket förenklar arbetet.

För att slå upp detaljer om en specifik OID kan man använda Cisco SNMP Object Navigator, ett webbaserat verktyg som hjälper nätverksadministratörer att identifiera och förstå vad olika OID:er representerar.

Figuren visar ett exempel där verktyget används för att undersöka OID-informationen för objektet whyReload.