Slik leser du pakketap før du gir kabelen skylden

To prosent tap over en lang ping-kjøring føles som et tall du kan handle på, og det er det sjelden. Det sier ikke hvor svarene ble borte, om de forsvant sammen, eller hvordan en bestemt applikasjon opplevde det intervallet. Tap fordelt jevnt over ett minutt og tap samlet inne i én enkelt utveksling gir svært ulike utfall for den samme prosenten.

Sammenlign tre målinger i stedet for å stole på én: hva sonden så, hva grensesnittellerne gjorde og hva applikasjonen faktisk ventet på.

Hva en ping-prosent egentlig måler

En ekkosonde tester én retning av én protokoll med én pakkestørrelse, ved den hastigheten du valgte. En tunnel som bærer en stor opplasting gjør noe helt annet, og en lenke som slipper små sonder, er ikke nødvendigvis lenken som skader overføringen. Prosenten knuser også tidsinformasjonen som betyr mest, fordi ti tapte svar i en byge ikke er det samme som ti tapte svar med en times mellomrom. Den kan heller ikke fortelle deg hvilken side av tunnelen som slapp noe.

Behold sondens resultat som et hint om ruten. Gå deretter på jakt etter tidspunktet og grensen som skapte det.

Sammenlign tellerforskjeller, ikke livstidssummer

Ta tidsstemplede avlesninger før og etter vinduet der symptomet dukket opp, ved begge endepunktene og ved enhver svitsjport du styrer. Noter trafikkvolumet sammen med feil, forkastede pakker og endringer i lenkestatus, fordi en sum som ikke er null og har samlet seg over måneder, beskriver historie og ikke denne hendelsen. En teller som flyttet seg med tre under stansen, er en annen observasjon enn en teller som viser tre tusen og aldri har endret seg.

ip -s link show dev eth0
nstat -az TcpRetransSegs TcpExtTCPTimeouts
date -u +%Y-%m-%dT%H:%M:%SZ

Pakker som forkastes på grunn av mottaksfeil, og pakker som forkastes av andre grunner, lever i adskilte tellere, og den forskjellen endrer oppfølgingen. Feiltellere peker på det fysiske laget eller driverlaget, mens køtrykk og policy-forkastninger peker et sted over det. Ta vare på retningen og grensesnittnavnet også, fordi en økning i mottaksfeil på en opplenke og en tunnelpakketeller ikke er utbyttbare.

Hvis en driver viser detaljerte fysiske tellere, les dem gjennom dokumentasjonen til den adapteren. Å gi én betydning til hvert felt som heter «drop» hos to leverandører er måten en vanlig regnskapsmessig særhet blir en maskinvarediagnose.

Hvordan et tapt segment blir en lang ventetid

En applikasjon kan vente mye lenger enn én rundtur etter å ha mistet et segment. TCP anslår rundturtiden, beregner en omsendingstimer fra anslaget og trekker seg tilbake når en omsending også mislykkes, så ett tapt segment på feil tidspunkt kan stanse en forespørsel i et merkbart intervall. Denne mekanismen er spesifisert i RFC 6298, og den forklarer hvorfor en taprate som ser triviell ut, likevel kan merkes.

Men ikke enhver pause er en omsendingstimeout. Den samme ventingen kan komme fra navneoppslag, en treg server eller en applikasjon som prøver sin egen forespørsel på nytt etter en feil. Skill disse tilfellene ved å justere den mislykkede operasjonen mot transportobservasjoner og mot tunnelens egne sesjonshendelser. En avbrytelse på datastien uten gjenoppkobling er en annen hendelse enn en fersk håndtrykk og utveksling av påloggingsinformasjon.

Der opptak er tillatt, hold det smalt. Det du trenger, er om de forventede pakkene eller bekreftelsene stopper ved en bestemt grense, ikke at det finnes en omsending et eller annet sted i et travelt spor.

Endre én grense uten å flytte de andre

Hvis bevisene peker på en lokal lenke, bytt ut en godkjent kabel eller port som en kontrollert sammenligning og la alt annet være. Hold endepunktet, applikasjonen og arbeidsbelastningen sammenlignbare, og endre nøyaktig én grense per forsøk. Å sammenligne en kablet bærbar med en trådløs mens du også bytter utganger og protokoller, forteller deg ingenting du kan tilskrive.

Rene lokale tellere bekrefter ikke resten av ruten. De avgrenser den delen du ser, og den ærlige rapporten sier hvilke grenser som ble observert og hvilke som ikke ble det. Det du vil ha til slutt, er en uttalelse om at én observasjon endret seg da én inngripen skjedde, ikke en anekdote om en dårlig kabel som er løftet til en universell regel.