Hoe je pakketverlies leest voordat je de kabel de schuld geeft

Twee procent verlies over een lange ping-reeks voelt als een getal waarop je kunt handelen, en dat is het zelden. Het zegt niet waar de antwoorden verdwenen, of ze samen verdwenen, of hoe een bepaalde toepassing dat interval ervoer. Verlies gelijkmatig verdeeld over een minuut en verlies samengebald binnen één uitwisseling geven bij hetzelfde percentage heel verschillende uitkomsten.

Vergelijk drie metingen in plaats van op één te vertrouwen: wat de probe zag, wat de interfacetellers deden en waarop de toepassing werkelijk wachtte.

Wat een ping-percentage werkelijk meet

Een echoprobe test één richting van één protocol met één pakketgrootte, tegen welk tempo je ook koos. Een tunnel die een grote upload draagt, doet iets heel anders, en een link die kleine probes laat vallen is niet per se de link die de overdracht schaadt. Het percentage verplettert ook de tijdsinformatie die het meest telt, want tien verloren antwoorden in één uitbarsting zijn niet hetzelfde als tien verloren antwoorden met een uur ertussen. Het kan je ook niet vertellen welke kant van de tunnel iets liet vallen.

Bewaar het probresultaat als een aanwijzing over het pad. Zoek daarna de timing en de grens die het hebben veroorzaakt.

Vergelijk tellerverschillen, niet levenslange totalen

Neem tijdgestempelde metingen vóór en na het venster waarin het symptoom verscheen, aan beide uiteinden en op elke switchpoort die je beheert. Noteer het verkeersvolume samen met fouten, weggegooide pakketten en wijzigingen in de linkstatus, want een totaal dat niet nul is en zich over maanden heeft opgebouwd, beschrijft geschiedenis en niet dit incident. Een teller die tijdens de stilstand met drie verschoof, is een andere waarneming dan een teller die drieduizend aanwijst en nooit veranderde.

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

Pakketten die door ontvangstfouten worden weggegooid en pakketten die om andere redenen worden weggegooid, leven in aparte tellers, en dat verschil verandert de vervolgstap. Fouttellers wijzen op de fysieke laag of de stuurprogrammalaag, terwijl wachtrijdruk en beleidsverwerpingen ergens daarboven wijzen. Bewaar ook de richting en de interfacenaam, want een toename van ontvangstfouten op een uplink en een tunnel-pakketteller zijn niet uitwisselbaar.

Als een stuurprogramma gedetailleerde fysieke tellers blootlegt, lees ze dan via de documentatie van die adapter. Aan elk veld met de naam “drop” bij twee leveranciers één betekenis toekennen, is hoe een normale boekhoudkundige eigenaardigheid een hardwarediagnose wordt.

Hoe een verloren segment een lange wachttijd wordt

Een toepassing kan veel langer dan één heen-en-terugreis wachten nadat ze een segment verloor. TCP schat de heen-en-terugtijd, berekent daaruit een herverzendtimer en trekt zich terug wanneer een herverzending ook mislukt, zodat één verloren segment op het verkeerde moment een verzoek voor een merkbaar interval kan stilzetten. Dat mechanisme is vastgelegd in RFC 6298, en het verklaart waarom een verliespercentage dat triviaal lijkt toch voelbaar kan zijn.

Niet elke pauze is echter een herverzendtime-out. Dezelfde wachttijd kan van naamresolutie, een trage server of een toepassing komen die haar eigen verzoek na een fout opnieuw probeert. Scheid die gevallen door de mislukte bewerking af te stemmen op transportwaarnemingen en op de sessiegebeurtenissen van de tunnel zelf. Een onderbreking op het datapad zonder herverbinding is een andere gebeurtenis dan een nieuwe handdruk en een uitwisseling van inloggegevens.

Waar vastleggen is toegestaan, houd het smal. Wat je nodig hebt, is of de verwachte pakketten of bevestigingen bij een bepaalde grens stoppen, niet het feit dat er ergens in een druk spoor een herverzending bestaat.

Verander één grens zonder de andere te verplaatsen

Als het bewijs op een lokale link wijst, vervang dan een goedgekeurde kabel of poort als gecontroleerde vergelijking en laat al het overige met rust. Houd het eindpunt, de toepassing en de werklast vergelijkbaar, en verander per poging precies één grens. Een bekabelde laptop met een draadloze vergelijken terwijl je ook uitgangen en protocollen wisselt, vertelt je niets dat je kunt toeschrijven.

Schone lokale tellers bevestigen de rest van het pad niet. Ze begrenzen het deel dat je ziet, en het eerlijke verslag zegt welke grenzen zijn waargenomen en welke niet. Wat je uiteindelijk wilt, is een uitspraak dat één waarneming veranderde toen één ingreep plaatsvond, niet een anekdote over een slechte kabel die tot algemene regel is verheven.