Dette tipset opprinnelig dukket opp på WindowsNetworking.com.
Så langt i denne artikkelserien, har jeg vist deg alle slags triks som involverer ved hjelp av ping-kommandoen til å diagnostisere problemer med nettverkstilkobling. I denne artikkelen vil jeg diskusjonen ved å vise deg noen varianter av disse teknikkene for å fortsette.
Packet tap
Så langt når vi har brukt ping kommandoen, kommando enten har vært vellykket, eller det har sviktet. Det egentlig ikke har vært noen i mellom. Som du kanskje husker, er ping-kommandoen designet for å gå tilbake fire forskjellige svar. Av og til kan en eller flere av disse responsene svikter mens andre lykkes. Når dette skjer, betyr det at pakketap skjer.
I en slik situasjon, den lokale verten og den eksterne verten eller begge fungerer som de skal, men det foreligger forhold som forårsaker noen pakker å være tapt underveis. TCP /IP-protokollen er utformet slik at den kan forsøke overføring når pakketap oppstår, men pakketap dreper ytelse. En treg tilkobling uten pakketap vil ofte utkonkurrere en høyhastighets tilkobling som pakketap oppstår.
Den vanskelige ting om pakketap er at det noen ganger kan være vanskelig å få øye på. Jada, vet du at pakketap skjer hvis noen av ping svar mislykkes, men ICMP-pakker brukes av pinge er så små at de ofte vil være vellykket returneres selv om det finnes et nettverk tilstand som kan føre til pakketap i virkelige situasjoner.
Hvis du mistenker at pakketap kan ha oppstått, men ping returnerer ikke noen feil så kan du prøve å øke størrelsen på ICMP-pakker. Større pakker er mer utsatt for feil hvis nettverksproblemer eksisterer. Du kan fortelle ping å bruke større pakkestørrelser ved hjelp av -L bryteren.
Bruke -L bryteren er enkel. Alt du trenger å gjøre er å skrive inn kommandoen ping etterfulgt av den adressen du ønsker å pinge, og -L bryteren og antall byte som du vil sende. For eksempel anta at nettverket var opplever dårlig ytelse når du kobler til en bestemt vert. Du mistenker at pakketap er oppstått, men ping er konsekvent vellykket. Derfor bestemmer deg for å fortelle ping å bruke en pakkestørrelse på 1024 bytes. For å gjøre dette, vil du bruke følgende kommando:
Ping 192.168.1.1 -L 1 024
Du kan se en virkelig verden eksempel på hvordan denne kommandoen fungerer, i Figur A:
Figur A:
Tillegg av den -L kommando til ping-kommandoen til å øke størrelsen på ICMP pakke
Time-to-live
neste konsept som jeg ønsker å diskutere i forhold til ping-kommandoen er at av time-to-live (TTL). Hvis du tar en titt på figur A, vil du legge merke til at hver av ping svarer ender i TTL = 64.
Som du sikkert vet, består Internett av et stort antall rutere som er koblet til hverandre . Hver ruter er koplet til minst to andre rutere. Ideen bak denne arkitekturen er at hvis en kobling svikter, bør det være minst en annen vei til bestemmelsesstedet. Problemet med denne typen arkitektur er at under visse omstendigheter lenker feil kan føre til pakker for å reise i sirkler for uendelighet, faktisk aldri nådde sitt bestemmelsessted.
Det er der TTL verdi kommer inn i bildet. Tenk på TTL verdi som et selvbilde ødelegge mekanismen for pakken. TTL-verdien er i utgangspunktet satt på et relativt høyt antall, selv om dette antall er avhengig av operativsystemet som blir brukt. Hver gang den pakke overføres over til en ruter, blir pakken sies å ha utført en hop. Hver gang et hopp skjer, blir TTL-verdien dekrementert med en. Om TTL-verdien når null, blir pakken ødelagt. Dette holder en tapt pakke fra reiser rundt på Internett for all evighet.
Traceroute
En annen grunn til at TTL-verdien er så nyttig er fordi et feilsøkingsverktøy kalt traceroute ( tracert) er basert på den. Bruke ping-kommandoen er greit for feilsøking små nettverk der den eksterne verten er i umiddelbar nærhet til verten som sender, men når det kommer til Internett eller til et regionnett (WAN) den eksterne verten kan være tusenvis av miles away. Som sådan, kan ICMP pakke generert av ping-kommandoen må reise gjennom dusinvis av rutere for å nå den eksterne verten. Du kan av og til kjøre inn i situasjoner der den lokale verten og den eksterne verten eller begge jobber riktig, men en av ruterne et sted på veien er å ha problemer. Heldigvis kan du bruke tracert kommandoen til å diagnostisere slike problemer.
tracert kommandoen er faktisk basert på ping-kommandoen. Den grunnleggende ideen bak tracert er at det sender ut en ICMP-pakke til den eksterne verten, men med TTL-verdien satt til én. Dette fører til den første ruteren støtt å sende tilbake en TTL utløp i meldingen transitt. Denne meldingen inneholder informasjon som identifiserer de ruter som produseres meldingen. Ruterens identifikasjon er dokumentert, og deretter ICMP pakken sendes ut igjen, men denne gangen med en TTL verdi av to. Denne gangen når ICMP pakke den andre ruteren før TTL verdi utløper. Denne prosessen gjentas, øker TTL-verdien med en hver gang, før verten til slutt nås. Dette gjør at du kan se en rapport over alle rutere mellom den lokale verten og den eksterne verten. Du kan noen ganger bruke denne informasjonen til å oppdage problemer langs ruten som kan påvirke trafikkflyt.
Bruke tracert kommandoen er veldig lik ved hjelp av ping-kommandoen. For å gjøre dette, bare skriv tracert kommandoen etterfulgt av IP-adressen eller fullt kvalifiserte domenenavnet til verten. Figur B viser tracert kommandoen i aksjon:
Figur B Bilde: tracert kommandoen som brukes til å oppdage problemer med trafikkflyt
Det er et par forskjellige ting å huske på når du bruker tracert kommandoen. Først noen verter bruke en brannmur til å blokkere ICMP-pakker. Som sådan, vil du noen ganger se en serie med stjerner som indikerer at spor rute var ikke i stand til å få informasjon fra en bestemt vert.
En annen ting å huske på er at, som vertene seg selv, er hver router tildelt en IP-adresse. Uavhengig av om de brukes til verter eller for rutere, IP-adresser er strukturert på en måte som gir dem mulighet til å reflektere deres geografiske plassering. Faktisk, noen ganger dette geografisk informasjon eller en beskrivelse av ruteren gis innenfor tracert. Hvis du ønsker mer informasjon om, det finnes tredjepartsverktøy som kan grafisk spore tracert kommandoen basert på denne geografisk informasjon. Du kan se et eksempel på et slikt verktøy i Figur C:
Figur C Bilde: Utføre en visuell tracert å bestemme en rekke geografiske plassering
Konklusjon
I denne artikkelen har jeg vist deg hvordan du kan øke antall byte brukt av ping-kommandoen i et forsøk på å gjøre det lettere å få øye på pakketap. Jeg fortsatte med å introdusere deg til tracert kommandoen. .
Brien M. Posey, MCSE, er: I neste del av denne artikkelserien, jeg vil diskusjonen
Om forfatteren fortsette ved å vise deg hvordan du skal tolke resultatene som tilbys av tracert en Microsoft Most Valuable Professional for sitt arbeid med Windows 2000 Server og IIS. Brien har fungert som CIO for en landsdekkende kjede av sykehus og var en gang ansvaret for IT-sikkerhet for Fort Knox. Som freelance teknisk forfatter har han skrevet for Microsoft, CNET, ZDNet, Techtarget, MSD2D, relevante teknologier og andre teknologiselskaper. Du kan besøke Brien personlige hjemmeside www.brienposey.com
WindowsNetworking.com inneholder et vell av nettverksinformasjon for administratorer. Med informasjon om hvordan du kan sette opp og feilsøke ulike nettverk i alle størrelser. Inkluderer også et omfattende arkiv av hundrevis av anmeldt nettverk programvare og maskinvareløsninger. Hyppig oppdatert med artikler og tips av et team av ledende forfattere, er det fortsatt en favoritt innenfor nettverk samfunnet
Feilsøking nettverkstilkobling tips serie
Del 1:. Bruk ping-kommandoen til å feilsøke nettverkstilkobling
Del 2: Sjekk IP-konfigurasjon
Del 3: Test din protokollstakken
Del 4: Bruke TTL og tracert
Del 5: dechiffrere tracert utgang