¿Cómo se diagnostica la pérdida de paquetes?

Me doy cuenta de que esto es muy subjetivo y depende de una serie de variables, pero me pregunto qué pasos deben seguir la mayoría de las personas cuando necesitan diagnosticar la pérdida de paquetes en un sistema determinado.

Soy ingeniero de redes, así que lo describiré desde mi perspectiva.

Para mí, diagnosticar la pérdida de paquetes generalmente comienza con "no está funcionando muy bien". A partir de ahí, generalmente trato de encontrar el kit lo más cerca posible de ambos extremos de la comunicación (por lo general, una estación de trabajo en una oficina y un servidor en algún lugar) y hacer ping lo más cerca posible del otro extremo (idealmente el "punto final remoto", pero a veces hay firewalls a los que no puedo enviar pings, por lo que tendré que conformarme con una interfaz LAN en un enrutador) y ver si puedo ver alguna pérdida.

Si puedo ver la pérdida, generalmente es un caso de "ancho de banda insuficiente" o "enlace con problemas" en algún punto intermedio, así que encuentre la ruta a través de la red y comience desde el medio, que generalmente le da un extremo u otro.

Si no puedo ver la pérdida, los siguientes dos pasos tienden a ser "enviar más pings" o "enviar pings más grandes". Si eso no soluciona, dé una indicación de cuál es el problema, es hora de comenzar a mirar las políticas de QoS y las estadísticas de la interfaz a lo largo de todo el camino entre los puntos finales.

Si eso no encuentra nada, es hora de comenzar a cuestionar sus suposiciones, ¿realmente está sufriendo la pérdida de paquetes? La única forma segura de encontrar eso es hacer capturas simultáneas en ambos extremos, ya sea utilizando WireShark (o equivalente) en los hosts o conectando máquinas sniffer (probablemente utilizando WireShark o similar) a través de toques de red. Luego viene la diversión de comparar las dos capturas de paquetes ...

A veces, lo que se atribuye como "pérdida de paquetes" es simplemente algo en el lado del servidor que es notablemente más lento (como, por ejemplo, mover la base de datos de "en la misma LAN" a "20 ms de distancia" y usar consultas que requieren una gran cantidad de ida y vuelta entre el front-end y la base de datos).

Desde la perspectiva de un sistema Linux, primero buscaré la pérdida de paquetes en la interfaz de red con ethtool -S ethX.

La mayoría de las veces, aumentar el buffer de anillo ethtool -G ethX rx VALUEresuelve esto.

A veces, las interrupciones no se equilibran porque al sistema le falta el servicio irqbalance, así que mire en chkconfig(EL) o update-rc(Debuntu) para ver si este servicio se está ejecutando. Puede saber si las interrupciones no se equilibran porque /proc/interruptssolo mostrará Core 0 dando servicio a todos los canales IRQ.

De lo contrario, es posible que deba aumentar net.core.netdev_max_backlogsi el sistema pasa más de unos pocos gigabits de tráfico, y tal vez net.core.netdev_budget.

Si eso no funciona, puede ajustar los valores de fusión de interrupción con ethtool -C.

Si no hay caídas de paquetes en la interfaz de red, mire netstat -sy vea si hay caídas en los búferes de socket, se informarán con estadísticas como " pruned from receive queue" y " dropped from out-of-order queue".

Puede intentar aumentar los búferes de socket predeterminados y máximos para el protocolo apropiado (por ejemplo, net.ipv4.tcp_rmempara TCP).

Si la aplicación establece su propio tamaño de búfer de socket, entonces la aplicación puede necesitar cambios de configuración. Si su aplicación tiene tamaños de búfer de socket codificados, reclame a su proveedor de aplicaciones.

Personalmente, no me gusta la descarga de protocolos en las NIC (suma de verificación, descarga de segmentación, descarga de recepción grande) ya que parece causar más problemas de lo que vale. Jugar con estos ajustes ethtool -Kpuede valer la pena.

Mire las opciones del módulo para su NIC ( modinfo <drivername>) ya que es posible que deba modificar algunas funciones. Para dar un ejemplo que he encontrado, usar el Flow Director de Intel en un sistema que maneja un flujo TCP grande probablemente dañará la eficiencia de ese flujo, así que apague FDir.

Más allá de eso, se está poniendo a mano este sistema específico para su carga de trabajo específica, lo que supongo que está fuera del alcance de su pregunta.

Comenzaré usando una herramienta de captura de paquetes como: wireshark (en Windows) y tcpdump (en la terminal de Linux).

También comprobaré la configuración del firewall (firewall del host y firewall de la red).

Aislar, luego eliminar.

Encuentre el subconjunto más pequeño de rutas con el problema. Para ello, pruebe diferentes combinaciones y / o destile informes de usuarios. No olvides factorizar el tiempo en la ecuación. Tal vez solo sea pérdida de paquetes en todo el tráfico a una red específica, o tal vez solo los clientes inalámbricos estén sufriendo. Tenga en cuenta diferentes tipos de tráfico (límite de velocidad en pings). Encuentre la forma más confiable y fácil de repetir para probarlo.

Luego elimine las posibles causas. Reduzca el tráfico en los enlaces (temporalmente), elimine las fuentes de interferencia del espectro, desconecte ciertos clientes. Eventualmente encontrarás la fuente del problema.

A veces puede tomar atajos mirando los volcados de paquetes o adivinando (siempre es bittorrent). Además, dile a tu profesor que el servidor por defecto es increíble

¡Los pings pueden no mostrar pérdida de paquetes a menos que envíe pings grandes! Tuve una pérdida de paquetes en mi red que era invisible hasta que aumenté el tamaño de mi paquete de ping.

Para ventanas:

ping -n 30 -l <largevalue> <target>

Porque largevalueusé 40960 (paquete de 40k)

Porque targetutilicé las primeras direcciones IP detracert google.com

(que era mi enrutador y módem por cable). Uno de los dispositivos más abajo de la cadena tuvo una terrible pérdida de paquetes (> 60%) para paquetes grandes pero 0% para paquetes pequeños. Lo arreglé reiniciando, pero también podría ser un cable o algo interno que necesita ser reemplazado.