Cisco CCNA / CCNP -sertifisering – Dekryptering av pingresultater

C

Når du studerer til CCNA- og CCNP-eksamenene dine, spesielt hvis du får praktisk praksis i hjemmelaboratoriet eller hylletjenesten din, kommer du til å sende mange pings. Som CCNA- eller CCNP -kandidat vet du at fem utropstegn (!!!!!) som en ping -retur indikerer at du har IP -tilkobling til den eksterne destinasjonen. Fem perioder (…..) indikerer at du ikke har den tilkoblingen.

Det er ikke nok å vite at du ikke har IP -tilkobling til den eksterne enheten, du må vite hvorfor. Ping er et flott første skritt for nettverksfeilsøking, men resultatene er ganske begrensede. Som CCNA og CCNP må du vite hvordan du diagnostiserer problemet og løser det. Bare å se på rutetabellen er ikke nok – en kraftig Cisco -feilsøkings-, feilsøkings -ip -pakke kan ofte vise deg nøyaktig hvor problemet er.

ADVARSEL: feilsøk ip -pakken bør ikke kjøres på noen produksjonsrutere uten å forstå effekten av denne kommandoen på ruteren din. Denne kommandoen resulterer i mye utgang og kan faktisk låse en ruter.

I dette tilfellet kjører vi kommandoen på en hjemmelaboratorrouter som ikke kan pinge 22.2.2.2. Feilsøkingen slås på og en annen ping sendes.

R1#feilsøk ip -pakke

IP -pakke feilsøking er på

R1#ping 22.2.2.2

Skriv inn rømningssekvens for å avbryte.

Sender 5, 100-byte ICMP Echos til 22.2.2.2, timeout er 2 sekunder:

3d23h: IP: s = 1.1.1.1 (lokal), d = 22.2.2.2, len 100, kan ikke kjøres.

R1#undebug alle

All mulig feilsøking er slått av

Jeg har redigert denne utgangen for klarhet; det viktige ordet er “unroutable”. Dette indikerer at pakken ikke forlater ruteren fordi det ikke er samsvar i rutetabellen for denne destinasjonen. Vi konfigurerer en statisk standardrute og sender pingen igjen.

R1#ping 22.2.2.2

Skriv inn rømningssekvens for å avbryte.

Sender 5, 100-byte ICMP Echos til 22.2.2.2, timeout er 2 sekunder:

UUU

Suksessraten er 0 prosent (0/5)

Denne utgangen kan overraske de av dere som er vant til å få fem av det samme symbolet tilbake når du sender en ping. Vi fikk tre U -er tilbake sammen med to perioder. Vi kjører nå feilsøkings -ip -pakken og sender pingen igjen.

R1#feilsøk ip -pakke

IP -pakke feilsøking er på

R1#ping 22.2.2.2

Skriv inn rømningssekvens for å avbryte.

Sender 5, 100-byte ICMP Echos til 22.2.2.2, timeout er 2 sekunder:

3d23h: IP: s = 172.12.123.1 (lokal), d = 22.2.2.2 (Serial0), len 100, sender

R1#traceroute 22.2.2.2

Skriv inn rømningssekvens for å avbryte.

Spor ruten til 22.2.2.2

1 172.12.123.2 36 msek 36 msek 36 msek

2 172.12.123.2! H *! H

R1#undebug alle

All mulig feilsøking er slått av

Igjen, jeg har redigert denne utgangen. Nøkkelordet i denne utgangen er “sending”, noe som betyr at pakkene forlater ruteren. Pingreturen til “UUU” er en generell indikasjon på at pakkene faktisk overføres, men at en nedstrøms ruter har et problem med å rute pakkene. Running traceroute avslører noen flere interessante returkarakterer! I dette tilfellet hadde ikke nedstrømsruteren en kamp for destinasjonen i rutetabellen.

Det er lett å konsentrere seg om den lokale ruteren når du ikke får positive ping -avkastninger. Når du feilsøker denne typen problemer, må du huske at problemet kan være på en mellomliggende ruter og ikke på den lokale ruteren. Bruk feilsøkings -ip -pakken for å kontrollere at pakkene forlater den lokale ruteren, og spor etter for å finne ut hvilken nedstrøms ruter som kan ha problemet. Og bli vant til at pings og traceroutes kan gi deg noen uvanlige utbytter!

About the author

Add comment

By user

Recent Posts

Recent Comments

Archives

Categories

Meta