I de föregående avsnitten lärde du dig hur olika verktyg och kommandon kan användas för att identifiera problemområden i ett nätverk. Detta är ett centralt steg i all felsökning.
Det finns många sätt att felsöka nätverksproblem, men för att arbeta effektivt är det viktigt att ha en strukturerad metod. I det här avsnittet går vi därför igenom en systematisk felsökningsprocess som hjälper dig att tänka som en nätverksadministratör – logiskt, metodiskt och konsekvent.
Du kommer också att få bekanta dig med några fler kommandon som ofta används i praktiken när man löser nätverksproblem. De kan variera från mycket enkla till mycket komplexa och kan bero på hårdvara, mjukvara, felaktiga konfigurationer eller anslutningsfel – ofta en kombination av flera faktorer.
En nätverkstekniker måste kunna analysera problemet, identifiera orsaken och avgöra lämplig åtgärd innan problemet kan lösas. Denna process kallas helt enkelt för felsökning (troubleshooting).
En välbeprövad och effektiv felsökningsmetod bygger på den vetenskapliga metoden – att observera, formulera en hypotes, testa och dra slutsatser. Tabellen nedan visar de sex huvudstegen i denna process:
| Steg | Beskrivning |
|---|---|
| 1. Identifiera problemet | Detta är det första steget i felsökningen. Även om verktyg kan användas här, är ett samtal med användaren ofta mycket värdefullt. |
| 2. Formulera en teori om sannolika orsaker | När problemet är identifierat, försök skapa en teori om vad som kan orsaka det. Detta steg leder ofta till flera möjliga orsaker. |
| 3. Testa teorin för att fastställa orsaken | Baserat på de sannolika orsakerna testar du dina teorier för att se vilken som verkligen är orsaken. Teknikern kan ofta utföra en snabb testprocedur för att se om det löser problemet. Om detta inte fungerar behövs mer forskning för att fastställa den exakta orsaken. |
| 4. Skapa en handlingsplan och implementera lösningen | När orsaken är känd, utarbeta en plan för att lösa problemet och genomför den. |
| 5. Verifiera lösningen och genomför förebyggande åtgärder | När problemet är löst, kontrollera att allt fungerar fullt ut. Om möjligt, vidta åtgärder för att förhindra att samma problem uppstår igen. |
| 6. Dokumentera fynd, åtgärder och resultat | I det sista steget dokumenterar du vad du upptäckte, vilka åtgärder du tog och vilka resultat du fick. Detta är mycket viktigt för framtida referens. |
När du påbörjar felsökningen är det viktigt att först avgöra omfattningen av problemet – hur många enheter i nätverket som är påverkade.
- Om endast en enhet har problem, bör du börja felsökningen direkt vid den enheten. Det kan röra sig om en lokal konfigurationsfel, en trasig kabel eller en felaktig IP-inställning.
- Om flera eller alla enheter påverkas, bör du istället börja felsökningen vid den gemensamma punkten i nätverket – till exempel vid switchen, routern eller den centrala länken som alla enheter är anslutna till.
Arbeta sedan systematiskt och uteslut ett problem i taget. På så sätt utvecklar du en logisk och konsekvent metod som hjälper dig att snabbt ringa in orsaken och undvika onödigt dubbelarbete.
Lösa eller eskalera?
I vissa situationer är det inte möjligt att lösa ett problem direkt. Det kan bero på att lösningen kräver särskild kompetens, ett beslut på högre nivå eller åtkomst till resurser som den ansvariga teknikern inte har. I sådana fall ska problemet eskaleras – det vill säga överlämnas till rätt person eller nivå i organisationen för vidare hantering. Till exempel följande:
En nätverkstekniker på första linjens support (first line) upptäcker att en router inte svarar som den ska.
Efter grundläggande felsökning konstaterar nätverksteknikern att problemet verkar ligga i själva hårdvaran eller i en komplex konfiguration.
Nätverksteknikern eskalerar då ärendet till second line, det vill säga till nätverksadministratören, som har djupare teknisk kompetens och tillgång till fler verktyg.
Om även nätverksadministratören bedömer att problemet kräver exempelvis utbyte av utrustning eller inköp av ny modul, eskaleras ärendet vidare till chefen för beslut och eventuellt vidare till ekonomiavdelningen för godkännande.
För att undvika missförstånd eller förseningar bör det alltid finnas en tydlig företagspolicy som anger:
- När ett ärende ska eskaleras
- Till vem det ska skickas vidare
- Hur kommunikationen och dokumentationen ska ske
En tydligt definierad eskaleringskedja säkerställer att varje problem hanteras av rätt person i rätt tid – vilket sparar både tid och resurser. Support avdelningar använder ofta ett ärendehanteringssystem.
En väl fungerande ärendehanteringsprocess säkerställer att alla problem följs upp, prioriteras korrekt och hanteras av rätt person – vilket ökar effektiviteten och minskar risken för att något “faller mellan stolarna”.
Kommandot debug
Operativsystem, protokoll och olika processer i en Cisco-enhet genererar kontinuerligt meddelanden som beskriver deras status och aktivitet. Dessa meddelanden är mycket värdefulla vid felsökning och när man vill verifiera att systemet fungerar som det ska.
Kommandot debug i Cisco IOS gör det möjligt för administratören att visa dessa meddelanden i realtid, direkt i terminalen. Det är ett av de mest användbara – men också mest kraftfulla – verktygen för att övervaka händelser på en Cisco-router eller switch.
Alla debug-kommandon körs i privilegierat EXEC-läge.
Utskriften kan begränsas till en viss funktion eller ett delområde, vilket är viktigt eftersom debug-kommandon ges hög prioritet i CPU-processen. Om man aktiverar för mycket debug-utdata riskerar man att överbelasta systemet, vilket i värsta fall kan göra routern tillfälligt oanvändbar.
Tips: Använd alltid debug för att undersöka specifika problem – aldrig som ett generellt övervaknings verktyg.
Exempel: För att övervaka ICMP-meddelanden på en router används kommandot:
R1# debug ip icmp ICMP packet debugging is on R1# R1# ping 10.1.1.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 10.1.1.1, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/2 ms R1# *Aug 20 14:18:59.605: ICMP: echo reply rcvd, src 10.1.1.1, dst 209.165.200.225,topology BASE, dscp 0 topoid 0 *Aug 20 14:18:59.606: ICMP: echo reply rcvd, src 10.1.1.1, dst 209.165.200.225,topology BASE, dscp 0 topoid 0 *Aug 20 14:18:59.608: ICMP: echo reply rcvd, src 10.1.1.1, dst 209.165.200.225,topology BASE, dscp 0 topoid 0 *Aug 20 14:18:59.609: ICMP: echo reply rcvd, src 10.1.1.1, dst 209.165.200.225,topology BASE, dscp 0 topoid 0 *Aug 20 14:18:59.611: ICMP: echo reply rcvd, src 10.1.1.1, dst 209.165.200.225,topology BASE, dscp 0 topoid 0 R1#
Användbara debug-kommandon
Visar en lista över alla tillgängliga debug-funktioner i IOS.
Router# debug ?
Stäng av en specifik debug-funktion:
Router# no debug ip icmp
eller med alternativ syntax:
Router# undebug ip icmp
Stäng av alla aktiva debug-kommandon:
Router# undebug all
Viktigt att tänka på
Kommandon som debug all eller debug ip packet ska inte användas utan mycket god anledning. De genererar stora mängder utdata och kan snabbt förbruka systemets resurser. Routern kan bli så upptagen med att skriva debug-meddelanden att den inte längre hinner utföra nätverksfunktioner – eller till och med inte svarar på kommandon för att stänga av debug.
Kommandot terminal monitor
Det finns två sätt att ansluta till en Cisco-enhet för att få åtkomst till kommandoraden (CLI):
- Lokalt – via konsolporten med en rollover-kabel.
- Fjärranslutet – via Telnet eller SSH till en IP-adress på enheten.
Vissa system meddelanden visas automatiskt på konsolen, men inte på fjärranslutna sessioner.
Till exempel visas debug-utdata normalt endast på konsol anslutningar, inte på Telnet/SSH.
Exempel: En användare ansluter via Telnet och aktiverar debug ip icmp, men inget debug-utdata visas:
R2# telnet 209.165.200.225
R1# debug ip icmp
ICMP packet debugging is on
R1# ping 10.1.1.1
!!!!!
(no debug output displayed)
För att visa loggmeddelanden på en fjärrterminal används kommandot:
R1# terminal monitor
För att stänga av det:
R1# terminal no monitor
Efter att terminal monitor aktiverats visas debug-utdata även under Telnet/SSH-sessionen:
R1# terminal monitor R1# ping 10.1.1.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 10.1.1.1, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/2 ms R1# *Aug 20 16:03:49.735: ICMP: echo reply rcvd, src 10.1.1.1, dst 209.165.200.225,topology BASE, dscp 0 topoid 0 **Aug 20 16:03:49.737: ICMP: echo reply rcvd, src 10.1.1.1, dst 209.165.200.225,topology BASE, dscp 0 topoid 0 **Aug 20 16:03:49.738: ICMP: echo reply rcvd, src 10.1.1.1, dst 209.165.200.225,topology BASE, dscp 0 topoid 0 **Aug 20 16:03:49.740: ICMP: echo reply rcvd, src 10.1.1.1, dst 209.165.200.225,topology BASE, dscp 0 topoid 0 **Aug 20 16:03:49.741: ICMP: echo reply rcvd, src 10.1.1.1, dst 209.165.200.225,topology BASE, dscp 0 topoid 0 R1# no debug ip icmp ICMP packet debugging is off R1#
Obs: Syftet med debug är att tillfälligt fånga upp live-utdata under kort tid (några sekunder till en minut).
Avsluta alltid debug när det inte längre behövs.