Att felsöka ett nätverk är en av de viktigaste färdigheterna för en nätverksadministratör. Oavsett om nätverket är stort eller litet, kommer problem förr eller senare att uppstå – och då gäller det att snabbt kunna identifiera vad som är fel och vidta rätt åtgärder. Det kan handla om allt från att en användare inte kommer ut på internet, till att en hel avdelning inte får någon IP-adress eller att en router plötsligt slutar skicka vidare trafik.

Att felsöka nätverket handlar därför om mer än att bara lösa problem – det handlar om att förstå hur nätverket fungerar i grunden. Ju bättre du känner till hur olika nätverkskomponenter samverkar, desto lättare blir det att hitta orsaken till ett fel.

I den här avsnitten lär vi oss hur man felsöker nätverk på ett strukturerat sätt. Vi tittar på:

• hur man samlar in och tolkar information från enheter i nätverket
• hur man använder kommandon och verktyg för felsökning
• hur man dokumenterar och analyserar nätverkets normala beteende (en så kallad baslinje)
• hur man stegvis angriper problem på olika lager i OSI-modellen

Översikt över dokumentation

När du felsöker ett nätverk – precis som vid andra komplexa uppgifter – är det viktigt att börja med bra dokumentation. För att kunna övervaka och felsöka nätverket på ett effektivt sätt krävs dokumentation som är både noggrann och fullständig.

Vanlig nätverksdokumentation omfattar:

• Diagram som visar nätverkets fysiska och logiska topologi
• Information om nätverksenheter, som modell, plats, konfiguration m.m.
• Dokumentation av nätverkets prestanda, t.ex. baslinjemätningar

All dokumentation bör samlas på ett gemensamt ställe – antingen som papperskopia eller lagrad på en skyddad server i nätverket. Det är också viktigt att ha en säkerhetskopia lagrad på en annan plats, ifall originalet inte går att nå.

Nätverkstopologidiagram

Topologidiagram används för att hålla reda på plats, funktion och status för enheter i nätverket. Det finns två typer av topologidiagram: fysisk topologi och logisk topologi.

Fysisk topologi

En fysisk nätverkstopologi visar den fysiska layouten av enheter som är anslutna till nätverket. För att felsöka problem på det fysiska lagret måste du veta hur enheterna är fysiskt kopplade. Information som brukar dokumenteras i en fysisk topologi är bland annat:

• Enhetsnamn
• Enhetens placering (adress, rumsnummer, rackplats)
• Använda gränssnitt och portar
• Kabeltyp

Figuren visar ett exempel på ett fysiskt nätverkstopologidiagram.

Logisk IPv4-topologi

Ett logiskt topologidiagram visar hur nätverksenheter kommunicerar med varandra – alltså hur data skickas genom nätverket, oavsett hur enheterna är fysiskt placerade.

I diagrammet används symboler för att representera olika nätverkskomponenter, som routrar, switchar, servrar och klientdatorer. Det kan också visa hur olika platser är kopplade till varandra, även om dessa kopplingar inte motsvarar verkliga fysiska kablar eller platser.

Information som ofta dokumenteras i en logisk topologi är:

• Identifierare för varje enhet
• IP-adresser och nätmasker (prefixlängder)
• Vilka gränssnitt (interfaces) som används
• Routingprotokoll eller statiska routar
• Lager 2-information som VLAN, trunkportar och EtherChannel

En logisk topologi ger en tydlig översikt över hur nätverkets datatrafik rör sig och är särskilt värdefull vid felsökning av IP-kommunikation eller routing-problem.

Figuren visar ett exempel på en logisk IPv4-topologi.

Logisk IPv6-topologi

Även om IPv6-adresser skulle kunna visas i samma logiska topologi som IPv4, har vi valt att separera dem i ett eget diagram. Det gör det lättare att läsa och förstå hur nätverket fungerar med IPv6, utan att blanda ihop adresser och protokoll från två olika versioner av IP.

Figuren visar ett exempel på en logisk IPv6-topologi.

Dokumentation av nätverkshanterare

När det gäller enheter som routrar, switchar och andra nätverkskomponenter är det viktigt att dokumentationen är både korrekt och uppdaterad. Den ska innehålla all relevant information om hårdvaran och mjukvaran som används i nätverket.

Sådan dokumentation hjälper dig att snabbt få en överblick över nätverkets struktur och konfiguration – särskilt vid felsökning, uppgraderingar eller förändringar i nätverket.

Dokumentation för routrar

Tabellen visar exempel på dokumentation av två sammankopplade routrar, Central och Branch-1.

Enhet	Modell	Beskrivning	Plats	IOS	Licens
Central	ISR 4321	Central Edge Router	Byggnad A, Rum 137	Cisco IOS XE Software, version 16.09.04 flash:isr4300-universalk9_ias.16.09.04.SPA.bin	ipbasek9 securityk9
Interface	Beskrivning	IPv4-adress	IPv6-adress	MAC-adress	Routing
G0/0/0	Ansluter till SVR-1	10.0.0.1/30	2001:db8:acad:1::1/64	a03d.6fe1.e180	OSPF
G0/0/1	Ansluter till Branch-1	10.1.1.1/30	2001:db8:acad:a001::1/64	a03d.6fe1.e181	OSPFv3
G0/1/0	Ansluter till ISP	209.165.200.226/30	2001:db8:feed:1::2/64	a03d.6fc3.a132	Default
S0/1/1	Ansluter till Branch-2	10.1.1.2/24	2001:db8:acad:2::1/64	n/a	OSPFv3
Enhet	Modell	Beskrivning	Plats	IOS	Licens
Branch-1	ISR 4221	Branch-2 Edge Router	Byggnad B, Rum 107	Cisco IOS XE Software, version 16.09.04 flash:isr4200-universalk9_ias.16.09.04.SPA.bin	ipbasek9 securityk9
Interface	Beskrivning	IPv4-adress	IPv6-adress	MAC-adress	Routing
G0/0/0	Ansluter till S1	Router-on-a-stick	Router-on-a-stick	a03d.6fe1.9d90	OSPF
G0/0/1	Ansluter till Central	10.1.1.2/30	2001:db8:acad:a001::2/64	a03d.6fe1.9d91	OSPFv3

Dokumentationen för nätverksenheter ska innehålla korrekta och uppdaterade uppgifter om nätverkets hårdvara och mjukvara. Den bör omfatta all relevant information om varje enhet i nätverket. Många organisationer använder tabeller eller kalkylblad för att samla in och strukturera denna information på ett tydligt sätt.

Dokumentering för switchar

Enhet	Modell	Beskrivning	Hanterings-IP	IOS	VTP
S1	Cisco Catalyst WS-C2960 24TC-L	Branch-1 LAN1 switch	192.168.77.2/24	IOS: 15.0(2)SE7 Image: C2960-LANBASEK9-M	Domän: CCNA Läge: Server
Port	Beskrivning	Access	VLAN	Trunk	EtherChannel	Native	Aktiverad
Fa0/1	Port Channel 1 trunk till S2 Fa0/1	–	–	Ja	PortChannel 1	99	Ja
Fa0/2	Port Channel 1 trunk till S2 Fa0/2	–	–	Ja	PortChannel 1	99	Ja
Fa0/3	*** Inte i bruk	Ja	999	–	–		Stängd
Fa0/4	*** Inte i bruk	Ja	999	–	–		Stängd
Fa0/5	*** Inte i bruk	Ja	10	–	–		Stängd
Fa0/23	Accessport till användare	Ja	20	–	–		Ja
Fa0/24	*** Inte i bruk	Ja	999	–	–		Stängd
G0/1	Trunklänk till Branch-1	–	–	Ja	–	99	Ja
G0/2	*** Inte i bruk	Ja	999	–	–

Dokumentation av slutenheter (inkluderas servrar)

Dokumentation av ändsystem fokuserar på hårdvara och mjukvara som används i servrar, nätverkshanteringskonsoler och användararbetsstationer. Ett fel-konfigurerat ändsystem kan ha en negativ inverkan på nätverkets totala prestanda. Av den anledningen kan tillgång till dokumentation över ändsystem vara mycket värdefull vid felsökning.

Tabellen nedan visar ett exempel på vilken information som kan dokumenteras för ett ändsystem.

Enhet	OS	Tjänster	MAC adress	IPv4/IPv6 adresser	Default Gateway	Default Gateway
SRV1	MS Server 2016	SMTP, POP3, File services, DHCP	5475.d08e.9ad8	10.0.0.2/30 2001:db8:acad:1::2/64	10.0.0.1 2001:db8:acad:1::1/64	10.0.0.1 2001:db8:acad:1::1/64
SRV2	MS Server 2016	HTTP, HTTPS	5475.d07a.5312	209.165.201.10 2001:db8:feed:1::1/64	209.165.201.1 2001:db8:feed:1::1/64	209.165.201.1 2001:db8:feed:1::1/64
PC1	MS Windows 10	HTTP, HTTPS	5475.d017.3133	192.168.10.10/24 2001:db8:feed:1::251/64	192.168.10.1 2001:db8:acad:1::1/64	192.168.10.1 2001:db8:acad:1::1/64
. . .

Etablera en prestanda baslinje för nätverket

Syftet med nätverksövervakning är att kunna jämföra nätverkets prestanda mot en förutbestämd referenspunkt – en så kallad baslinje. En baslinje beskriver hur nätverket normalt fungerar under vanliga förhållanden och används som utgångspunkt för att upptäcka avvikelser.

För att skapa en baslinje för nätverksprestanda behöver du samla in data från de enheter och portar som är mest kritiska för nätverkets funktion.

En nätverksbaslinje bör kunna besvara frågor som:

• Hur presterar nätverket under en vanlig arbetsdag?
• Var i nätverket uppstår flest fel?
• Vilka delar av nätverket är mest belastade?
• Vilka delar används minst?
• Vilka enheter bör övervakas, och vilka varningsnivåer ska ställas in?
• Uppfyller nätverket de krav och riktlinjer som verksamheten ställt upp?

Genom att mäta den inledande prestandan och tillgängligheten hos viktiga nätverkskomponenter, kan du som administratör skilja mellan normalt och onormalt beteende. Det blir särskilt värdefullt när nätverket växer eller trafikmönster förändras. En baslinje visar också om den nuvarande designen räcker för verksamhetens behov.

Analys av en första baslinje kan dessutom avslöja problem som annars är svåra att upptäcka. Den insamlade datan visar var det finns risk för överbelastning – eller var nätverket är underutnyttjat. Det kan leda till att du omvärderar och förbättrar nätverkets struktur utifrån kvalitet och kapacitet.

En korrekt genomförd baslinje blir ett verktyg för att mäta effekten av framtida förändringar och en viktig del av varje felsökningsarbete. Därför är det avgörande att planera den noggrant.

Steg 1 – Bestäm vilken typ av data som ska samlas in

När du påbörjar en baslinjemätning är det bäst att börja enkelt. Välj ut ett fåtal variabler som är kopplade till nätverkets riktlinjer och mål. Om du försöker samla in för mycket data från början blir det svårt att tolka och analysera informationen.

En bra utgångspunkt är att mäta:

• Interface-utnyttjande (hur mycket trafik som går genom ett interface)
• CPU-användning (hur hårt enheten arbetar)

Du kan alltid lägga till fler mätvärden senare när du får bättre kontroll på nätverkets beteende.

Steg 2 – Identifiera enheter och portar av intresse

Använd nätverkets topologi (t.ex. topologidiagram) för att avgöra vilka enheter och portar som är viktiga att mäta. Fokusera på de delar av nätverket som är kritiska för kommunikationen.

Exempel på intressanta mätpunkter:

• Portar på nätverksenheter (t.ex. switchar och routrar) som ansluter till andra nätverksenheter
• Servrar
• Nyckelanvändares arbetsstationer
• Andra enheter som är viktiga för driften

Genom att bara mäta de mest relevanta punkterna blir datan mer hanterbar och resultatet mer användbart.

En logisk nätverkstopologi är ett bra verktyg för att identifiera vilka enheter och portar som bör övervakas under en baslinjemätning. I figuren har nätverksadministratören markerat de enheter och gränssnitt som valts ut för övervakning under testet.

I det här exemplet ingår bland annat:

• PC1, som fungerar som administrationsterminal
• Srv1 och Svr2, två centrala servrar
• Routergränssnitt och viktiga switchportar, där mycket trafik passerar

Genom att fokusera på ett begränsat antal portar blir övervakningen både mer effektiv och lättare att analysera. Dessutom minskar belastningen på nätverkshanteringsverktygen.

Tänk också på att ett gränssnitt inte alltid behöver vara fysiskt – det kan även vara ett virtuellt gränssnitt, som till exempel ett SVI (Switch Virtual Interface).

Steg 3 – Bestäm baslinjens varaktighet

Tidsperioden för baslinjemätningen måste vara tillräckligt lång för att ge en rättvisande bild av hur nätverket normalt fungerar. Det räcker inte att bara titta på trafiken under en enskild dag – du behöver även fånga in mönster som återkommer över tid. Av denna anledning bör datainsamlingen pågå i minst sju dagar.

Det är viktigt att dokumentera:

• Dagliga trafikmönster – exempelvis hur nätverket används under kontorstid jämfört med kvällstid
• Veckovisa eller månatliga trender – som exempelvis schemalagda säkerhetskopieringar eller belastningstoppar under vissa dagar

Ju längre datainsamlingsperiod, desto mer tillförlitlig blir din baslinje. Men tänk också på att inte välja en period då nätverket har ovanlig trafik (t.ex. vid driftstörningar eller större uppgraderingar), eftersom det kan ge en felaktig bild av normal prestanda.

Figuren visar exempel på CPU-användning som samlats in över en dag, en vecka, en månad och ett år.

I det här exemplet är veckoöversikten för kort för att visa den återkommande belastning som sker varje lördag kväll, då en databasbackup kraftigt belastar nätverket. Det mönstret blir tydligt först i månadsvyn. En årstrend kan vara för lång för att ge detaljerad baslinjedata, men den kan däremot avslöja långsiktiga förändringar som är värda att analysera vidare.

En baslinjemätning behöver vanligtvis inte pågå längre än sex veckor, om du inte specifikt vill undersöka säsongsvariationer eller andra långsiktiga trender. I de flesta fall räcker det med en period på två till fyra veckor för att få en tillförlitlig bild av nätverkets normala beteende.

Undvik att samla in data under perioder med onormal trafik, till exempel vid driftstörningar, uppgraderingar eller specialevenemang. Resultatet riskerar annars att ge en felaktig bild av nätverkets vanliga prestanda.

Det är också en god idé att genomföra en årlig översyn av hela nätverket, eller att rotera baslinjemätningen mellan olika delar. Regelbunden analys är avgörande för att förstå hur nätverket påverkas av förändringar, tillväxt och nya behov.

Datainsamling

När du dokumenterar ett nätverk är det ofta nödvändigt att hämta information direkt från routrar och switchar. Det görs vanligtvis genom att använda kommandon som visar status, inställningar och prestanda.

Vanliga och användbara kommandon inkluderar:

• ping – för att testa om en annan enhet är nåbar
• traceroute – för att se vägen som paketen tar genom nätverket
• telnet – för att fjärransluta till andra enheter
• Olika show-kommandon – för att visa aktuell konfiguration, routingtabeller, gränssnittsinformation och mycket mer

Dessa kommandon är grunden för manuell datainsamling och används både vid felsökning och vid uppbyggnad av dokumentation.

Automatisering av datainsamling

Att manuellt samla in information med show-kommandon på varje enskild nätverksenhet är både tidskrävande och svårt att skala upp. Därför bör manuell datainsamling främst användas i mindre nätverk eller vid felsökning av verksamhetskritiska enheter.

I enklare nätverksmiljöer kombineras ofta manuell insamling med enklare protokollanalysverktyg för att skapa en grundläggande baslinje.

I större och mer komplexa nätverk krävs däremot mer avancerade lösningar. Här används ofta nätverkshanteringsmjukvara som kan:

• automatiskt samla in och spara prestandadata
• skapa rapporter och jämföra aktuell prestanda med historiska värden
• identifiera prestandaproblem utan manuell insats
• skicka varningar om applikationer inte uppfyller angivna servicenivåer

Att skapa en första baslinje eller analysera nätverksprestanda på ett tillförlitligt sätt kan ta flera timmar – ibland dagar – beroende på nätverkets storlek. Därför körs den här typen av programvara ofta kontinuerligt under hela datainsamlingsperioden, ibland tillsammans med verktyg som protokollanalysatorer (protocol analyzers) eller trafiksniffers.

Vanliga Cisco IOS-kommandon för datainsamling

Kommando	Beskrivning
show version	Visar driftstid samt version för mjukvara och hårdvara.
show ip interface [brief]	Visar alla konfigurationsinställningar för ett interface.
show ipv6 interface [brief]	Med brief-tillägget visas endast upp/ned-status och IP-adresser för varje interface.
show interfaces	Visar detaljerad information om varje interface. För att visa detaljer om ett specifikt interface, inkludera typ och nummer i kommandot (t.ex. GigabitEthernet 0/0/0).
show ip route	Visar innehållet i IPv4-routningstabellen, inklusive direktanslutna och inlärda nätverk.
show ipv6 route	Lägg till static, eigrp eller ospf för att endast visa dessa routar.
show cdp neighbors detail	Visar detaljerad information om direktanslutna Cisco-enheter.
show arp show ipv6 neighbors	Visar innehållet i ARP-tabellen (IPv4) och Neighbor-tabellen (IPv6).
show running-config	Visar aktuell konfiguration.
show vlan	Visar VLAN-status på en switch.
show port	Visar portstatus på en switch.
show tech-support	Samlar in omfattande information om enheten för felsökning. Utför flera show-kommandon och används vid kontakt med teknisk support.

Generella felsökningsmetoder

Felsökning kan vara tidskrävande eftersom nätverk ser olika ut, problem varierar, och felsökningserfarenhet skiljer sig från person till person. Men erfarna administratörer vet att en strukturerad metod minskar den totala felsökningstiden.

Därför bör felsökningsarbetet alltid styras av en tydlig och systematisk metod. Det kräver väldefinierade och dokumenterade rutiner som minimerar slöseri med tid på chansningar eller osystematiska försök. Samtidigt är dessa metoder inte statiska – felsökningsstegen är inte alltid desamma eller utförs i exakt samma ordning.

Sju-steg felsöknings process

Det finns flera metoder som kan användas för att lösa ett nätverksproblem. Figuren visar ett logiskt flöde för en förenklad felsöknings process i tre steg. I mer avancerade fall kan en mer detaljerad metod behövas.

1. Definiera problemet

Målet i det här steget är att bekräfta att ett problem faktiskt finns, och sedan tydligt definiera vad problemet är. Problem visar sig ofta genom ett symptom, till exempel att nätverket känns långsamt eller helt har slutat fungera. Symptom kan dyka upp som:

• Larm från nätverkshanteringssystemet
• Meddelanden i konsolen
• Klagomål från användare

När du samlar in symptom är det viktigt att ställa frågor och undersöka för att avgränsa problemet. Gäller det en enskild enhet? En grupp enheter? Ett helt nätverk eller delnät?

I organisationer hanteras problem ofta som supportärenden. Dessa skapas i ett ärendehanteringssystem som håller reda på status och historik. Systemet kan även innehålla:

• Självbetjäningsportal för användare
• Kunskapsbas med tidigare ärenden
• Möjlighet till fjärrstyrning
• Med mera

2. Samla in information

Identifiera vilka enheter (t.ex. datorer, routrar, switchar) som ska undersökas. Skaffa åtkomst till dessa och samla in relevant information. I det här steget kan du även hitta fler symptom som hjälper till att förtydliga problemet.

Om det visar sig att felet ligger utanför organisationens ansvar (t.ex. internetförbindelse hos extern leverantör), bör du kontakta rätt systemadministratör innan du fortsätter samla in fler nätverkssymptom.

3. Analysera informationen

Nu gäller det att identifiera möjliga orsaker. Den insamlade informationen analyseras med hjälp av:

• Dokumentation
• Tidigare baslinjevärden
• Interna kunskapsdatabaser
• Sökningar på internet
• Kollegor med erfarenhet

4. Uteslut möjliga orsaker

Om flera möjliga felkällor har identifierats behöver du smalna av listan genom att systematiskt utesluta alternativ – tills du hittar den mest troliga orsaken. Erfarenhet spelar stor roll här, eftersom det gör det lättare att snabbt fokusera på rätt felkälla.

5. Föreslå en hypotes

När du har en trolig orsak till problemet är det dags att formulera en möjlig lösning. Även här är erfarenhet viktigt, eftersom det hjälper dig att skapa en realistisk åtgärdsplan.

6. Testa hypotesen

Innan du testar en lösning, fundera på hur akut problemet är och vilken påverkan lösningen kan ha. Kan åtgärden påverka andra system negativt? Är det bättre att vänta till arbetsdagen är slut innan du genomför den?

Ibland kan det vara klokt att tillfälligt lösa problemet med en workaround, tills du har tid eller resurser att genomföra en permanent lösning.

Skapa alltid en återställningsplan, så att du snabbt kan backa tillbaka om något går fel.

När du genomför lösningen, kontrollera noga att den verkligen löste problemet – ibland skapas nya, oväntade fel. Om lösningen inte fungerar ska du dokumentera vad du testade, återställa eventuella ändringar, och återvända till steg 2 (insamling av information).

7. Lös problemet

När problemet är åtgärdat är det viktigt att informera användarna och alla som varit inblandade i felsökningen. Se också till att andra i IT-teamet känner till lösningen.

Dokumentera orsaken och åtgärden noggrant – det hjälper andra tekniker att undvika eller lösa liknande problem i framtiden.

Fråga slutanvändaren

Många nätverksproblem rapporteras först av en användare. Men det de säger är ofta vagt eller missvisande. Exempelvis:

• ”Nätverket är nere”
• ”Jag kommer inte åt min e-post”
• ”Min dator är långsam”

För att förstå problemet behöver du ofta ställa följdfrågor. Försök ta reda på:

• Vem har problemet?
• Vad fungerar inte?
• När började det?

Rekommendationer när du pratar med användaren:

• Prata på en teknisk nivå de förstår – undvik komplicerade termer
• Lyssna noggrant och ta anteckningar
• Var trevlig och visa förståelse – de kan vara stressade
• Styr samtalet och använd rätt sorts frågor:
• Öppna frågor för att få mer detaljer (ex: ”Vad händer när du försöker logga in?”)
• Stängda frågor för att bekräfta fakta (ex: ”Har det fungerat tidigare?”)
• När samtalet är klart, upprepa din tolkning av problemet så att du och användaren är överens om vad som faktiskt är fel.

Riktlinjer för att intervjua slutanvändare

När du pratar med en användare om ett nätverksproblem är det viktigt att ställa rätt typ av frågor. Nedan följer några riktlinjer med exempel på öppna frågor som hjälper dig att förstå problemet bättre.

Riktlinjer	Exempel på öppna frågor till användare
Ställ relevanta frågor	Vad är det som inte fungerar? Vad är exakt problemet? Vad försöker du göra?
Fastställ omfattningen av problemet	Vem påverkas av problemet? Är det bara du eller flera? På vilka enheter händer det här?
Ta reda på när problemet uppstod eller uppstår	När inträffar problemet exakt? När märkte du problemet första gången? Visades något felmeddelande?
Fastställ om problemet är konstant eller tillfälligt	Går det att återskapa problemet? Kan du skicka en skärmbild eller video på problemet?
Ta reda på om något har ändrats	Vad har ändrats sedan det fungerade senast?
Använd frågor för att utesluta eller upptäcka möjliga fel	Vad fungerar? Vad fungerar inte?

Samla in information

För att samla in information om symptom från en misstänkt nätverksenhet används ofta Cisco IOS-kommandon, kompletterat med verktyg som paketfångande (packet capture) och system loggar från enheten.

Tabellen nedan beskriver vanliga Cisco IOS-kommandon som används för att identifiera symptom på nätverksproblem:

Vanliga Cisco IOS-kommandon för felsökningssymptom

Kommando	Beskrivning
ping {host | ip-adress}	Skickar ett ”echo request”-paket till en adress och väntar på svar. Variabeln host eller ip-adress är målets IP-alias eller IP-adress.
traceroute destination	Visar vägen ett paket tar genom nätverket. Variabeln destination är värdnamnet eller IP-adressen för målenheten.
telnet {host | ip-adress}	Upprättar en Telnet-anslutning till en IP-adress. Använd om möjligt SSH istället för Telnet.
ssh -l användarnamn ip-adress	Ansluter till en IP-adress med SSH. SSH är ett säkrare alternativ än Telnet.
show ip interface brief show ipv6 interface brief	Visar en översiktlig status för alla gränssnitt på enheten. Användbart för att snabbt se IP-adressering och interface-status.
show ip route show ipv6 route	Visar den aktuella IPv4- och IPv6-routningstabellen, med rutter till alla kända nätverksdestinationer.
show protocols	Visar konfigurerade protokoll samt global och portspecifik status för Layer 3-protokoll.
debug	Visar en lista över alternativ för att aktivera eller inaktivera felsökningshändelser (debugging events).

Observera: Om debug-kommandot

Även om kommandot debug är ett viktigt verktyg för att samla in felsökningsinformation, genererar det stora mängder meddelanden i konsolen, vilket kan påverka prestandan på en nätverksenhet märkbart. Om du måste köra debug under ordinarie arbetstid, informera användarna om att felsökning pågår och att nätverkets prestanda kan påverkas. Kom också ihåg att stänga av debug när du är klar.

Felsökning med hjälp av lagerbaserade modeller

OSI- och TCP/IP-modellerna är användbara vid felsökning eftersom de hjälper till att avgränsa var i nätverket problemet finns. Om symtomen till exempel tyder på ett fysiskt fel, kan teknikern fokusera på att undersöka komponenter på det fysiska lagret.

Figuren visar vanliga enheter och vilka OSI-lager som bör granskas vid felsökning.

Observera att routrar och multilager-switchar visas på lager 4, Transport lagret. Även om dessa enheter vanligtvis fattar vidarebefordrings beslut på lager 3, kan ACL:er (åtkomstlistor) på dessa enheter användas för att fatta filtrerings beslut baserade på information från lager 4.

Strukturerade felsöknings metoder

Det finns flera strukturerade felsöknings strategier att välja mellan. Vilken metod du bör använda beror på situationen – varje metod har sina fördelar och nackdelar. Här beskrivs de vanligaste:

Bottom-Up (nerifrån och upp)

Vid bottom-up felsökning börjar du längst ner i OSI-modellen, med det fysiska lagret och dess komponenter, och arbetar dig uppåt tills problemet identifieras.

Fördelar:

• Bra vid fysiska problem
• Många fel i nätverk finns på de lägre lagren

Nackdelar:

Tidskrävande eftersom alla enheter och interface måste kontrolleras

• Kräver mycket dokumentation
• Svårt att veta var man ska börja felsöka

Top-Down (uppifrån och ner)

Top-down-felsökning börjar med användarens applikationer och går neråt genom OSI-lagren.

Fördelar:

• Effektivt vid mjukvarurelaterade problem
• Användbart vid enklare fel

Nackdelar:

• Alla nätverksapplikationer måste testas
• Kräver tydlig dokumentation
• Kan vara svårt att avgöra vilken applikation man ska börja med

Divide-and-Conquer (dela och härska)

I denna metod väljer teknikern ett OSI-lager att börja på, och testar både uppåt och nedåt i modellen.

• Samla in information och symtom från användarna
• Avgör vilket OSI-lager du ska börja undersöka
• Om lagret fungerar → gå uppåt
• Om lagret inte fungerar → gå nedåt

Exempel: Om användaren kan pinga webbservern men inte nå webbtjänsten, ligger problemet ovanför lager 3. Om ping misslyckas, ligger det troligen under lager 3.

Follow-the-Path (följ vägen)

Detta är en av de mest grundläggande felsöknings metoderna. Tillvägagångssättet går ut på att först kartlägga trafikvägen hela vägen från avsändaren till destinationen. Felsöknings området begränsas då till endast de länkar och enheter som faktiskt ingår i vidarebefordrings vägen. Målet är att utesluta de länkar och enheter som är irrelevanta för den aktuella felsöknings uppgiften. Denna metod används ofta som ett komplement till andra felsöknings metoder.

Substitution (byt ut komponent)

Detta tillvägagångssätt kallas också swap-komponenten metoden, eftersom man fysiskt byter ut den misstänkta enheten mot en annan som man vet fungerar. Om problemet försvinner berodde det på den utbytta enheten. Om problemet kvarstår, ligger orsaken troligen någon annanstans.

I vissa situationer kan detta vara en idealisk metod för snabb problemlösning, särskilt när det gäller en kritisk enhet utan redundans. Till exempel, om en gränsrouter går ner, kan det vara mer effektivt att helt enkelt ersätta enheten för att snabbt återställa tjänsten, istället för att felsöka den befintliga.

Om problemet är utspritt över flera enheter kan det däremot vara svårt att isolera felet med denna metod.

Comparison (jämför fungerande och icke-fungerande delar)

Denna metod kallas också spot-olikheterna metoden och bygger på att man försöker lösa problemet genom att göra de icke-fungerande elementen likadana som de fungerande. Du jämför konfigurationer, mjukvaruversioner, hårdvara eller andra egenskaper, länkar eller processer mellan fungerande och icke-fungerande situationer och letar efter tydliga skillnader.

Nackdelen med denna metod är att den kan leda till en fungerande lösning utan att den bakomliggande grundorsaken till problemet faktiskt identifieras.

Educated Guess (välgrundad gissning)

Detta tillvägagångssätt kallas också gissa-sig-fram metoden. Det är en mindre strukturerad felsöknings metod som bygger på kvalificerade gissningar baserade på symtomen. Framgången med denna metod varierar beroende på felsökarens erfarenhet och kompetens. Erfarna tekniker lyckas oftare eftersom de kan använda sin kunskap och tidigare erfarenheter för att snabbt isolera och lösa nätverksproblem. För en mindre erfaren nätverksadministratör kan denna metod däremot bli för slumpmässig för att vara effektiv.

Riktlinjer för att välja felsöknings metod

För att snabbt lösa nätverksproblem är det viktigt att ta sig tid att välja den mest effektiva felsöknings metoden.

Figuren visar vilken metod som kan användas beroende på vilken typ av problem som upptäcks.

Felsökning är en praktisk färdighet som utvecklas genom erfarenhet. Varje problem du identifierar och löser bygger på din kunskapsbas och gör dig bättre inför nästa gång.

Felsökningsverktyg

Mjukvarubaserade felsökningsverktyg

Som du vet består nätverk av både mjukvara och hårdvara. Därför finns det felsökningsverktyg för båda delarna. Detta avsnitt behandlar de verktyg som finns tillgängliga för respektive område.

Ett brett utbud av mjukvaru- och hårdvaruverktyg finns tillgängliga för att underlätta felsökning. Dessa verktyg används ofta för att samla in och analysera symptom på nätverksproblem. De innehåller ofta funktioner för övervakning och rapportering, vilket är användbart för att etablera en dokumentation på nätverkets funktionalitet (baseline).

Verktyg för nätverkshantering (NMS)

Nätverkshanteringssystem (Network Management System Tools, NMS) omfattar verktyg för övervakning på enhetsnivå, konfiguration och felhantering. Dessa kan användas för att undersöka och åtgärda nätverksproblem. Nätverksövervakningsmjukvara visar ofta en grafisk vy över nätverksenheterna och gör det möjligt för administratörer att övervaka fjärrenheter kontinuerligt och automatiskt. Hanteringsmjukvaran visar dynamisk status, statistik och konfigurationsinformation för centrala nätverksenheter. Sök på nätet efter ”NMS Tools” för mer information.

Kunskaps databaser

Tillverkarens kunskaps databaser för nätverksenheter har blivit ovärderliga informationskällor. När de kombineras med sökmotorer får nätverksadministratörer tillgång till en omfattande erfarenhetsbank.

Exempel: Cisco Tools & Resources finns på http://www.cisco.com under menyn Support. Där finns verktyg för både Cisco-hårdvara och mjukvara.

Baslinje verktyg

Det finns många verktyg som automatiserar dokumentation och etablering av nätverks baslinjer. Sådana verktyg hjälper till med vanliga dokumentations uppgifter, som att rita diagram, hålla dokumentation uppdaterad samt mäta bandbredds användning kostnadseffektivt. Sök på ”Network Performance Monitoring Tools” för mer information.

Protokoll analysatorer

Protokoll analysatorer används för att undersöka innehållet i datapaket som färdas genom nätverket. De avkodar protokollagren i varje ram och visar informationen i ett användarvänligt format. Figuren visar ett exempel från Wireshark.

Protokollanalysatorn visar information från det fysiska lagret, datalänklagret, olika protokoll och beskrivningar för varje ram. De flesta analysatorer kan filtrera trafik enligt angivna kriterier, så att endast relevant trafik fångas. Verktyg som Wireshark är mycket användbara för att felsöka prestandaproblem. För att använda dessa verktyg effektivt krävs god förståelse för TCP/IP och hur man inspekterar information på varje lager.

Hårdvarubaserade felsöknings verktyg

Det finns flera typer av verktyg för att felsöka nätverkets hårdvara.

Digitala multimeters

Digitala multimeters (DMM) är mätinstrument som används för att mäta elektriska värden som spänning, ström och resistans.

Vid nätverksfelsökning används digitala multimeter oftast för att kontrollera spänningsnivåer och verifiera att nätverksenheter får ström.

Kabeltestare

Kabeltestare är handhållna enheter som används för att testa olika typer av datakommunikations kablar.

De kan upptäcka brutna ledare, korskopplade ledare, kortslutningar och felaktiga parningar. De finns i olika prisklasser: från enkla kontinuitetstestare till mer avancerade kabeltestare och tidsdomänreflektometrar (TDR). En TDR kan exakt mäta avståndet till ett kabelbrott genom att skicka signaler längs kabeln och mäta tiden tills de reflekteras. Vid testning av fiberoptik används en variant som kallas OTDR (Optical Time-Domain Reflectometer).

Kabelanalysatorer

Kabelanalysatorer är multifunktionella handhållna enheter som används för att testa och certifiera koppar- och fiberkablar enligt olika tjänster och standarder.

De mer avancerade analysatorerna har diagnostik som mäter t.ex. närliggande överhörning (NEXT) eller returförlust (RL), föreslår korrigerande åtgärder och visar beteende grafiskt. De inkluderar vanligtvis även PC-mjukvara för att skapa rapporter baserat på insamlade fältdata.

Portabla nätverksanalysatorer

Dessa används för felsökning av switchade nätverk och VLAN.

Genom att ansluta analysatorn var som helst i nätverket kan man direkt se till vilken switchport den är ansluten, samt aktuell och högsta bandbreddsanvändning. Analysatorn kan även avslöja VLAN-konfigurationer, identifiera tunga trafikavsändare (top talkers), analysera trafikmönster och visa gränssnittsdetaljer. Den kan även exportera data till en dator med övervakningsmjukvara för vidare analys.

Cisco Prime Network Analysis Module

Cisco Prime Network Analysis Module (NAM), som visas i figuren, består av hård- och mjukvara för prestandaanalys i switch- och routermiljöer. Den har ett webbaserat gränssnitt som genererar rapporter över trafik som använder kritiska nätverksresurser. NAM kan även fånga och avkoda paket samt mäta svarstider, vilket hjälper till att identifiera om problem ligger i nätverket eller på en server.

Syslog-server som felsökningsverktyg

Syslog är ett enkelt protokoll där en IP-enhet (syslog-klient) skickar textbaserade loggmeddelanden till en annan IP-enhet (syslog-server). Syslog är definierat i RFC 5424.

Att implementera en loggningsfunktion är en viktig del av både nätverkssäkerhet och felsökning. Cisco-enheter kan logga information om t.ex. konfigurationsändringar, ACL-överträdelser, gränssnittstatus och andra händelser. Meddelanden kan skickas till:

• Console – Är aktiverat som standard. Meddelanden visas på konsolen via terminalemuleringsprogram.
• Terminal lines – Aktiva EXEC-sessioner kan konfigureras att ta emot loggmeddelanden. Meddelandena sparas dock inte.
• Buffered logging – Sparar meddelanden i enhetens minne tillfälligt. Informationen förloras vid omstart.
• SNMP traps – Händelser, t.ex. när en gräns överskrids, kan vidarebefordras till ett SNMP-system.
• Syslog – Cisco-enheter kan skicka loggar till en extern syslog-server (t.ex. på Windows eller Linux). Syslog är det mest använda systemet tack vare sin möjlighet till långsiktig logglagring och centralisering.

Cisco IOS loggmeddelanden delas in i åtta nivåer, vilket visas i tabellen.

	Level	Keyword	Description	Definition
	0	Emergencies	System is unusable	LOG_EMERG
	1	Alerts	Immediate action is needed	LOG_ALERT
	2	Critical	Critical conditions exist	LOG_CRIT
		Errors	Error conditions exist	LOG_ERR
		Warnings	Warning conditions exist	LOG_WARNING
Lowest Level	5	Notifications	Normal (but significant) condition	LOG_NOTICE
	6	Informational	Information messages only	LOG_NFO
	7	Debugging	Debugging messages	LOG_DEBUG

Ju lägre siffra på loggnivån, desto högre är allvaret. Som standard loggas alla meddelanden från nivå 0 till 7 till konsolen. Även om det är mycket användbart att kunna visa loggar på en central syslog-server vid felsökning, kan det vara överväldigande att gå igenom stora mängder loggdata. Kommandot logging trap level används för att begränsa vilka meddelanden som skickas till syslog-servern, baserat på allvarlighetsnivå. Nivån anges antingen med namn eller nummer. Endast meddelanden som är lika med eller lägre än den angivna nivån loggas.

I kommandoutdata skickas systemmeddelanden från nivå 0 (emergencies) till nivå 5 (notifications) till syslog-servern med IP-adressen 209.165.200.225.