Com llegir la pèrdua de paquets abans de culpar el cable
Una xifra petita de pèrdua pot amagar una llarga aturada de l’aplicació. Compareu les diferències dels comptadors, el comportament de retransmissió i la tasca real abans de substituir maquinari.
Una pèrdua del dos per cent al llarg d’una seqüència llarga de ping sembla una xifra sobre la qual es pot actuar, i poques vegades ho és. No diu on van desaparèixer les respostes, si van desaparèixer juntes ni com va viure aquell interval una aplicació concreta. Una pèrdua repartida uniformement al llarg d’un minut i una pèrdua agrupada dins d’un sol intercanvi produeixen resultats molt diferents per al mateix percentatge.
Compareu tres mesures en lloc de confiar en una: què va veure la sonda, què van fer els comptadors de la interfície i què va esperar realment l’aplicació.
Què mesura realment un percentatge de ping
Una sonda d’eco prova una direcció d’un protocol amb una mida de paquet, al ritme que hàgiu triat. Un túnel que transporta una pujada gran fa una cosa completament diferent, i un enllaç que descarta sondes petites no és necessàriament l’enllaç que perjudica la transferència. El percentatge també aixafa la informació de temps que més importa, perquè deu respostes perdudes en una ràfega no són el mateix que deu respostes perdudes amb una hora de separació. Tampoc no us pot dir quin costat del túnel ha descartat res.
Conserveu el resultat de la sonda com una pista sobre el camí. Després busqueu el moment i la frontera que el van produir.
Compareu diferències de comptadors, no totals de tota la vida
Preneu lectures amb marca de temps abans i després de la finestra en què va aparèixer el símptoma, als dos extrems i a qualsevol port de commutador que controleu. Registreu el volum de trànsit juntament amb errors, descarts i canvis d’estat de l’enllaç, perquè un total diferent de zero acumulat durant mesos descriu història, no aquest incident. Un comptador que s’ha mogut de tres durant l’aturada és una observació diferent d’un comptador que marca tres mil i mai no ha canviat.
ip -s link show dev eth0
nstat -az TcpRetransSegs TcpExtTCPTimeouts
date -u +%Y-%m-%dT%H:%M:%SZ
Els paquets descartats per errors de recepció i els paquets descartats per altres motius viuen en comptadors separats, i aquesta distinció canvia el seguiment. Els comptadors d’errors apunten a la capa física o de controlador, mentre que la pressió de cues i els descarts per política apunten a algun lloc per sobre. Conserveu també la direcció i el nom de la interfície, perquè un augment d’errors de recepció en un enllaç ascendent i un comptador de paquets de túnel no són intercanviables.
Si un controlador exposa comptadors físics detallats, llegiu-los amb la documentació d’aquest adaptador. Assignar un sol significat a cada camp anomenat “drop” en dos fabricants és com una peculiaritat comptable normal es converteix en un diagnòstic de maquinari.
Com un segment perdut es converteix en una espera llarga
Una aplicació pot esperar molt més que un sol viatge d’anada i tornada després de perdre un segment. TCP estima el temps d’anada i tornada, calcula un temporitzador de retransmissió a partir d’aquesta estimació i recula quan una retransmissió també falla, de manera que un sol segment perdut en el moment equivocat pot aturar una petició durant un interval notable. Aquest mecanisme s’especifica a RFC 6298, i explica per què una taxa de pèrdua que sembla trivial encara es pot notar.
Ara bé, no tota pausa és un temps d’espera de retransmissió. La mateixa espera pot venir de la resolució de noms, d’un servidor lent o d’una aplicació que torna a intentar la seva pròpia petició després d’un error. Separeu aquests casos alineant l’operació fallida amb les observacions de transport i amb els esdeveniments de sessió del túnel. Una interrupció al camí de dades sense reconnexió és un esdeveniment diferent d’una estreta de mans nova i un intercanvi de credencials.
On la captura estigui permesa, manteniu-la estreta. El que necessiteu és si els paquets o reconeixements esperats s’aturen en una frontera concreta, no el fet que hi hagi alguna retransmissió en algun lloc d’una traça carregada.
Canvieu una frontera sense moure les altres
Si les proves apunten a un enllaç local, substituïu un cable o port aprovat com a comparació controlada i deixeu tota la resta tranquil·la. Manteniu l’extrem, l’aplicació i la càrrega de treball comparables, i canvieu exactament una frontera per intent. Comparar un portàtil amb cable amb un de sense fils mentre també canvieu sortides i protocols no us diu res que pugueu atribuir.
Els comptadors locals nets no certifiquen la resta del camí. Limiten la part que podeu veure, i l’informe honest diu quines fronteres s’han observat i quines no. El que voleu al final és una afirmació que una observació va canviar quan va passar una intervenció, no una anècdota sobre un cable dolent elevada a regla universal.