I forrige del av denne artikkelserien, Bruke tracert og TTL for å feilsøke problemer med nettverkstilkobling, jeg forklarte at tracert kan brukes til å diagnostisere tilkoblingsproblemer mellom lokale verter, og verter på fjern nettverk. I den artikkelen viste jeg deg hvordan du kan gi en grunnleggende tracert kommandoen. Så i denne artikkelen, vil jeg fortsette diskusjonen ved å vise deg hvordan du kan tolke resultatene.
For demonstrasjonsformål, har jeg utført en tracert mot www.espn.com. Den eneste grunnen til at jeg valgte denne bestemte området er at det er en av de få områdene som jeg vet om av toppen av hodet mitt som ikke blokkerer (ICMP) trafikk Internet Control Message Protocol.
Du kan se utgang fra traceroute nedenfor. Jeg vil henvise til denne produksjonen i hele resten av artikkelen:
C: \\ Users \\ Administrator > tracert www.espn.com
Følge rute til www. espn.com [199.181.132.250] over maksimalt 30 hopp:
1 2 ms 1 ms < 1 ms 147.100.100.100
2 10 ms 10 ms 9 ms 208.104.224.1
3 9 ms 9 ms 9 ms 208.104.1.13
4 9 ms 8 ms 9 ms 208.104 .0.13
5 10 ms 9 ms 10 ms 208.104.0.1
6 11 ms 14 ms 10 ms 165.166.125.193
7 11 ms 10 ms 11 ms gig-1-1-3.core01.ncchrl.infoave.net [165.166.22.61]
8 31 ms 31 ms 30 ms 64.200.130.17
9 38 ms 39 ms 40 ms hrndva1wcx2-pos15-3-oc48.wcg.net [64.200.240.213]
10 31 ms 31 ms 31 ms 64.200.249.170
11 31 ms 30 ms 31 ms 4.68.110.5
12 48 ms 35 ms 35 ms vlan99.csw4.Washington1.Level3.net [4.68.17.254]
13 32 ms 31 ms 33 ms ae-92-92.ebr2.Washington1.Level3. net [4.69.134.157]
14 60 ms 53 ms 54 ms ae-2.ebr3.Chicago1.Level3.net [4.69.132.69]
15 86 ms 71 ms 70 ms ae-3.ebr2.Denver1.Level3.net [4.69.132.61]
16 137 ms 103 ms 102 ms ae-2.ebr2 .Seattle1.Level3.net [4.69.132.53]
17 95 ms 95 ms 95 ms ae-23-52.car3.Seattle1.Level3.net [4.68.105.36]
18 94 ms 95 ms 95 ms WALT-DISNEY.car3.Seattle1.Level3.net [4.71.152.22]
19 * * * Request tidsavbrudd.
20 97 ms 95 ms 98 ms 199.181.132.250
Trace fullført.
Hvis du ser på tracert ovenfor, vil du se at hver linje av produksjonen inneholder flere forskjellige biter av informasjon. Den første del av informasjon som finnes på den lengst til venstre side av hver linje, er det hopp nummer. Som jeg forklarte i forrige artikkel, fungerer tracert ved å sende en ping forespørsel til den angitte verten. I første omgang blir forespørselen time-to-live (TTL) verdi satt til 1. Dette sikrer at forespørselen mislykkes etter første hopp. Informasjon om hop er presentert, og deretter ICMP anmodning sendes på nytt, men denne gangen med TTL-verdien er satt til 2. Prosessen gjentas om og om igjen, øker TTL verdien med 1 hver gang, helt til den angitte verten er endelig nådd. Ved å gjøre det, er tracert stand til å rapportere hvor mange hopp forespørselen måtte gjøre for å nå den eksterne verten. Hvis du ser på den siste linjen av output ovenfor, vil du se at det begynner med nummer 20. Det er fordi det tok 20 hopp for å nå den angitte verten.
De neste tre stykker av informasjon for hver linje viser hvor lang tid det tok å nå ruteren eller verts at den spesielle linjen refererer til. Hvis du ser gjennom listen, vil du legge merke til at tids lenker generelt øker med hvert hopp. Det er to ting som du virkelig trenger å vite om de tids koblinger som vises.
Først tre separate tidslengder vises for hvert hopp. Som jeg nevnte tidligere, er traceroute basert på konseptet av å sende flere ICMP-forespørsler. Når vi jobbet med ping-kommandoen tidligere i denne artikkelserien, så du at ping-kommandoen alltid tilbake fire forskjellige verdier som en måte å måle pakketap. Det samme konseptet gjelder for traceroute, bortsett fra at tiden anmodningen tok måles tre ganger i stedet for fire.
Den andre tingen som du trenger å vite om de responstider er at en stjerne indikerer at en forespørsel er utløpt. Dette kan eller ikke kan indikere et problem, avhengig av hvor stjernen vises. Hvis du ser på hopp nummer 19 i produksjonen ovenfor, vil du legge merke til at alle tre responstid verdier presenteres som stjerner. Når du ser tre stjernene på rad, betyr det vanligvis at enheten som blir pinget på at hop har sin brannmur konfigurert til å avvise ICMP-pakker. Dette vil føre til hver av de tidtakere til annen ut, og den siste kolonnen vil bare vise ordene " Forespørsel avbrutt ".
Husk imidlertid at selv om dette er vanligvis tilfelle, er det ikke den eneste mulighet. Traceroute vil også vise tre stjernene når den aktuelle enheten er ikke nås. Selvfølgelig, reiser det spørsmålet om hvordan du kan fortelle forskjellen mellom et nettsted som blokkerer ICMP-pakker og en kobling svikt. Vel, det kan være litt vanskelig.
Ved første øyekast ser en kobling svikt identisk med hva du ser når en ruter eller en rekke blokker ICMP forespørsler. Når det oppstår en feil, er du ikke kommer til å se en feilmelding. Faktisk ender prosessen med standard " Trace Complete " meldingen.
Det er to gode tegn på at en kobling feil har oppstått. Ett tegn er at utover et visst punkt i kurven, hvert resultat som returneres ganger ut. Et annet tegn på en link svikt er at tracert går for en full 30 hopp. Ingen av disse betingelser sikrer at en kobling feil har oppstått, selv når de forekommer sammen. For eksempel er min hjemmeside, www.brienposey.com, fungerer fint i øyeblikket, og likevel når jeg kjører en tracert mot det, begge disse symptomene viser seg, som vist i produksjonen under:
< i> C: \\ brukere \\ Administrator > tracert www.brienposey.com
Følge rute til www.brienposey.com [24.235.10.4]
mer enn maksimalt 30 hopp:
1 1 ms 1 ms < 1 ms 147.100.100.100
2 8 ms 12 ms 8 ms 208.104.224.1
< p> 3 9 ms 8 ms 9 ms 208.104.1.9
4 10 ms 9 ms 8 ms 208.104.0.9
5 10 ms 12 ms 11 ms 208.104.0.5
6 12 ms 10 ms 9 ms 165.166.18.1
7 15 ms 23 ms 13 ms gig2-2-1.c01.scclma.infoave.net [165.166.22.17]
8 13 ms 12 ms 13 ms 66.192.166.9
< i> 9 31 ms 30 ms * peer-01-ge-0-0-0-1.asbn.twtelecom.net [64.129.249.10]
10 56 ms 57 ms 55 ms bb2-p6-0.ipltin.sbcglobal.net [151.164.242.59]
11 55 ms 53 ms 55 ms ded2-g8-0.ipltin.sbcglobal.net [151,164. 42,159]
12 59 ms 56 ms 56 ms Winnet-1148485.cust-rtr.ameritech.net [66.73.221.254]
13 64 ms 63 ms 68 ms 216-24-2-237.ip.win.net [216.24.2.237]
14 68 ms 68 ms 64 ms fa0-0.cust-GW2 .noc.win.net [216.24.30.69]
15 * * * Forespørsel avbrutt.
16 * * * Forespørsel avbrutt .
17 * * * Forespørsel avbrutt.
18 * * * Forespørsel avbrutt.
19 * * * Forespørsel avbrutt.
20 * * * Forespørsel avbrutt.
21 * * * Forespørsel avbrutt .
22 * * * Forespørsel avbrutt.
23 * * * Forespørsel avbrutt.
24 * * * Forespørsel avbrutt.
25 * * * Forespørsel avbrutt.
26 * * * Forespørsel avbrutt .
27 * * * Forespørsel avbrutt.
28 * * * Forespørsel avbrutt.
29 * * * Forespørsel avbrutt.
30 * * * Forespørsel avbrutt.
Trace fullført.
Hvis du ser en utgang som den ovenfor, kan det tyde på at en kobling feil har oppstått, men det garanterer ikke det. Den eneste måten å vite sikkert er å prøve å kjøre en tracert mot flere nettsteder for å se om du får stadig den samme type resultater. Husk at høyere nummererte humle er lenger borte fra deg. Jo lenger unna en fiasko er, jo vanskeligere vil det være å diagnostisere, fordi tester av andre nettsteder kan ta alternative ruter. Når du utfører tracert tester mot flere nettsteder, må du se på de rutene som faktisk ble tatt for å avgjøre hvorvidt en kobling svikt oppstår.
Den siste delen av informasjon som vises på hver rad er identiteten av ruteren eller verts som svarte på ICMP forespørsel. Tracert vil identifisere hver vert eller ruter ved navn når det er mulig, men du vil ikke alltid få en fullt navn oppløsning. For eksempel, hvis du ser på resultatet ovenfor, kan du se at omtrent halvparten av rutere er identifisert med navn, mens andre ikke er det. I seg selv, er det vanligvis ikke en stor avtale.
Hva du kan finne interessant er at verten som du sporer ruten til, er ikke alltid kommer til å bli identifisert. For eksempel, hvis du ser på helt i begynnelsen av den første prøven utgang ovenfor, vil du legge merke til at vi inn kommandoen tracert WWW.ESPN.COM.
Umiddelbart etter å gjøre det, tracert løst www.espn.com til IP-adressen 199.181.132.250. Hvis du hopper videre til slutten av prøven utgang, vil du se at tracert til slutt når sin destinasjon, men det betyr ikke identifisere målet ved navn (i det minste ikke i dette tilfellet).
Denne oppførselen er ikke problematisk, er det av design. Grunnen til at jeg viste deg dette er slik at du ikke ville prøve å utføre en tracert til et nettsted og mener at prosessen mislyktes fordi målvert ikke er identifisert ved navn.
Konklusjon
In denne artikkelen har jeg vist deg hvordan å tyde resultatet av en tracert. I neste artikkel i denne serien, vil jeg vise deg hvordan du bruker Route-kommandoen til å undersøke en maskinrutingtabeller.
Brien Posey
Feilsøking nettverkstilkobling tips serie
del 1: bruk ping-kommandoen til å feilsøke nettverkstilkobling
del 2: Kontroller IP-konfigurasjonen
del 3: Test din protokollstakken
del 4: Bruke TTL og tracert
del 5: Decipher tracert utgang