Como ler a perda de paquetes antes de culpar o cable

Unha perda do dous por cento ao longo dunha xeira longa de ping parece unha cifra sobre a que se pode actuar, e raras veces o é. Non di onde desapareceron as respostas, se desapareceron xuntas nin como viviu ese intervalo unha aplicación concreta. Unha perda repartida uniformemente ao longo dun minuto e unha perda agrupada dentro dun só intercambio producen resultados moi distintos para a mesma porcentaxe.

Compare tres medidas en lugar de confiar nunha: o que viu a sonda, o que fixeron os contadores da interface e o que a aplicación esperou en realidade.

Que mide realmente unha porcentaxe de ping

Unha sonda de eco proba unha dirección dun protocolo cun tamaño de paquete, ao ritmo que vostede escollese. Un túnel que transporta unha subida grande fai algo completamente distinto, e unha ligazón que descarta sondas pequenas non é necesariamente a ligazón que está a prexudicar a transferencia. A porcentaxe ademais esmaga a información de tempo que máis importa, porque dez respostas perdidas nunha ráfaga non son o mesmo que dez respostas perdidas cunha hora de separación. Tampouco pode dicirlle que lado do túnel descartou algo.

Conserve o resultado da sonda como unha pista sobre a ruta. Despois busque o momento e o límite que o produciron.

Compare diferenzas de contadores, non totais de por vida

Tome lecturas con marca de tempo antes e despois da xanela na que apareceu o síntoma, en ambos os extremos e en calquera porto de conmutador que controle. Rexistre o volume de tráfico xunto con erros, descartes e cambios de estado da ligazón, porque un total distinto de cero acumulado durante meses describe historia, non este incidente. Un contador que se moveu en tres durante a pausa é unha observación distinta dun contador que marca tres mil e nunca cambiou.

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

Os paquetes descartados por erros de recepción e os paquetes descartados por outros motivos viven en contadores separados, e esa distinción cambia o seguimento. Os contadores de erros apuntan á capa física ou de controlador, mentres que a presión de colas e os descartes por política apuntan a algún lugar por riba. Conserve tamén a dirección e o nome da interface, porque un aumento de erros de recepción nunha ligazón ascendente e un contador de paquetes de túnel non son intercambiables.

Se un controlador expón contadores físicos detallados, léaos coa documentación dese adaptador. Asignar un só significado a cada campo chamado “drop” en dous fabricantes é como unha peculiaridade contable normal se converte nun diagnóstico de hardware.

Como un segmento perdido se converte nunha espera longa

Unha aplicación pode esperar moito máis que unha soa viaxe de ida e volta despois de perder un segmento. TCP estima o tempo de ida e volta, calcula un temporizador de retransmisión a partir desa estimación e retrocede cando unha retransmisión tamén falla, así que un só segmento perdido no momento equivocado pode deter unha petición durante un intervalo notable. Ese mecanismo especifícase en RFC 6298, e explica por que unha taxa de perda que parece trivial aínda se pode sentir.

Porén, non toda pausa é un tempo de espera de retransmisión. A mesma espera pode vir da resolución de nomes, dun servidor lento ou dunha aplicación que reintenta a súa propia petición tras un fallo. Separe eses casos aliñando a operación fallida coas observacións de transporte e cos eventos de sesión do propio túnel. Unha interrupción na ruta de datos sen reconexión é un evento distinto dun aperto de mans novo e un intercambio de credenciais.

Onde a captura estea permitida, mantéñaa estreita. O que necesita é saber se os paquetes ou acuses de recibo esperados se deteñen nun límite concreto, non o feito de que exista algunha retransmisión nalgún lugar dunha traza ocupada.

Cambie un límite sen mover os demais

Se as probas apuntan a unha ligazón local, substitúa un cable ou porto aprobado como comparación controlada e deixe todo o demais en paz. Manteña o extremo, a aplicación e a carga de traballo comparables, e cambie exactamente un límite por intento. Comparar un portátil con cable cun inalámbrico mentres tamén cambia saídas e protocolos non lle di nada que poida atribuír.

Os contadores locais limpos non certifican o resto da ruta. Limitan a parte que vostede ve, e o informe honesto di que límites se observaron e cales non. O que quere ao final é unha afirmación de que unha observación cambiou cando ocorreu unha intervención, non unha anécdota sobre un cable malo elevada a regra universal.