Så här läser du paketförlust innan du skyller på kabeln

Två procents förlust under en lång ping-körning känns som en siffra man kan agera på, och det är det sällan. Den säger inte var svaren försvann, om de försvann tillsammans eller hur en viss applikation upplevde det intervallet. Förlust jämnt fördelad över en minut och förlust samlad inom ett enda utbyte ger mycket olika resultat för samma procent.

Jämför tre mätningar i stället för att lita på en: vad sonden såg, vad gränssnittsräknarna gjorde och vad applikationen faktiskt väntade på.

Vad en ping-procent egentligen mäter

En ekkosond testar en riktning av ett protokoll med en paketstorlek, i vilken takt du än valde. En tunnel som bär en stor uppladdning gör något helt annat, och en länk som tappar små sonder är inte nödvändigtvis länken som skadar överföringen. Procenten krossar också den tidsinformation som betyder mest, eftersom tio förlorade svar i en skur inte är samma sak som tio förlorade svar med en timmes mellanrum. Den kan inte heller säga vilken sida av tunneln som tappade något.

Behåll sondens resultat som en ledtråd om vägen. Leta sedan efter tidpunkten och gränsen som skapade det.

Jämför räknardifferenser, inte livstidssummor

Ta tidsstämplade avläsningar före och efter fönstret där symtomet dök upp, vid båda ändpunkterna och på varje switchport du styr. Anteckna trafikvolymen tillsammans med fel, kasserade paket och ändringar i länkstatus, eftersom en summa som inte är noll och har samlats under månader beskriver historia och inte den här händelsen. En räknare som flyttade sig tre under stoppen är en annan observation än en räknare som visar tre tusen och aldrig har ändrats.

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

Paket som kasseras på grund av mottagningsfel och paket som kasseras av andra skäl lever i separata räknare, och den skillnaden ändrar nästa steg. Felräknare pekar på det fysiska lagret eller drivrutinslagret, medan kötryck och policykasseringar pekar någonstans ovanför. Bevara också riktningen och gränssnittsnamnet, eftersom en ökning av mottagningsfel på en upplänk och en tunnelpaketräknare inte är utbytbara.

Om en drivrutin exponerar detaljerade fysiska räknare ska du läsa dem via den adapterns dokumentation. Att ge en enda betydelse åt varje fält som heter ”drop” hos två tillverkare är sättet på vilket en normal redovisningsmässig egenhet blir en hårdvarudiagnos.

Hur ett förlorat segment blir en lång väntan

En applikation kan vänta mycket längre än en tur och retur efter att ha tappat ett segment. TCP uppskattar tur-och-returtiden, beräknar en omsändningstimer från uppskattningen och backar när en omsändning också misslyckas, så ett enda tappat segment vid fel tillfälle kan stoppa en begäran under ett märkbart intervall. Den mekanismen anges i RFC 6298, och den förklarar varför en förlustnivå som ser trivial ut ändå kan kännas.

Men inte varje paus är en timeout för omsändning. Samma väntan kan komma från namuppslagning, en långsam server eller en applikation som försöker igen med sin egen begäran efter ett fel. Separera de fallen genom att anpassa den misslyckade operationen till transportobservationer och till tunnelns egna sessionshändelser. Ett avbrott på datavägen utan återanslutning är en annan händelse än en ny handskakning och ett utbyte av inloggningsuppgifter.

Där avlyssning är tillåten, håll den smal. Det du behöver är om de förväntade paketen eller bekräftelserna stannar vid en viss gräns, inte att det finns en omsändning någonstans i ett upptaget spår.

Ändra en gräns utan att flytta de andra

Om bevisen pekar på en lokal länk, byt ut en godkänd kabel eller port som en kontrollerad jämförelse och låt allt annat vara. Håll ändpunkten, applikationen och arbetsbelastningen jämförbara och ändra exakt en gräns per försök. Att jämföra en trådbunden bärbar dator med en trådlös medan du också byter utgångar och protokoll säger dig ingenting du kan tillskriva.

Rena lokala räknare intygar inte resten av vägen. De avgränsar den del du ser, och den ärliga rapporten säger vilka gränser som observerades och vilka som inte gjorde det. Det du vill ha till slut är ett påstående att en observation ändrades när en åtgärd gjordes, inte en anekdot om en dålig kabel som lyfts till en universell regel.