Cómo capturar "paquetes descartados" en tcpdump

Tengo un problema con el rendimiento de mi red. Estoy usando Ubuntu 16.04 en VMware Cloud Server con NIC E1000. Pero veo algunos paquetes descartados en secciones del comando ifconfig:

root@ubuntu:~# ifconfig ens192
ens192    Link encap:Ethernet  HWaddr 00:50:56:03:25:14  
          inet addr:192.16.1.100  Bcast:192.16.1.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:574749 errors:0 dropped:83 overruns:0 frame:0
          TX packets:76478 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:44109471 (44.1 MB)  TX bytes:19484534 (19.4 MB)

Aunque solo se descartaron algunos paquetes, mi servidor está ejecutando un juego en tiempo real en línea, por lo que sabe que afecta a mis clientes que se están conectando a él.

He investigado y explorado información en Google, luego intenté cambiar el archivo de configuración para el anillo de búfer, el tamaño máximo de las ventanas, etc. Pero todavía me cae los paquetes.

Entonces, ahora quiero capturar paquetes que se descartaron para analizar qué tipo de paquetes es exactamente.

También probé esta captura para mi vista en wireshark:

sudo tcpdump -i ens192 -n -w /var/www/html/logs.pcap -C 1 -Z root

¡Pero no creo que pueda ver qué paquetes se descartan! Creo que los paquetes descartados se ignoran antes de pasar al filtro de tcpdump.

¿Me puede sugerir qué método para capturar "paquetes descartados" arriba ( descartado: 83 )?

¡Gracias por adelantado!

El problema puede estar en tcpdump: si no responde lo suficientemente rápido, los paquetes antiguos se sobrescribirán con los nuevos, lo que significa que se descartan.

Si captura todos los bytes de cada paquete, es muy fácil anular el búfer de captura de paquetes del núcleo. Los síntomas de esta saturación son que su programa de rastreo de paquetes informará que descartó los paquetes.

En el caso de tcpdump, imprime un resumen de cuántos paquetes fueron capturados, filtrados y descartados cuando detiene la captura. Por ejemplo:

$ sudo tcpdump -i en0 -w trace.pcap
tcpdump: listening on en0, link-type EN10MB (Ethernet), capture size 65535 bytes
^C
94 packets captured
177 packets received by filter
0 packets dropped by kernel

Si el droppedrecuento no es cero, debe aumentar el tamaño del búfer de captura de paquetes pasando la -Bopción a tcpdump. Pruébelo también sin un archivo de captura, para ver si esto mejora la relación de captura.

Sus preguntas parecen referirse a regresar y descubrir qué pudo haber causado la caída de un paquete anterior en lugar de intentar capturar paquetes en tiempo real para tratar de encontrar uno que se caiga. Para este último, la respuesta de harrymc debería poder capturar finalmente la que estás buscando.

Para volver y ver qué podría estar sucediendo en esa interfaz, debe comprender que esos encabezados que está viendo RX packets:574749 errors:0 dropped:83 overruns:0 frame:0son simplemente resúmenes de contadores subyacentes.

Según mi comentario , recomendaría usar el ethtoolcomando / paquete de esta respuesta para analizar algunos de los contadores para ver si puede encontrar algo que parece fuera de lugar.
ethtool -S ens192

Desde el archivo fuente de los controladores de broadcom , vemos tp->rx_dropped++;en algunas ocasiones por separado en el archivo. 1 2 3 Cualquiera de estos o más (dependiendo de su NIC exacta y los controladores subyacentes) contribuyen a lo que podría estar causando paquetes descartados.

Para aliviar su mente, su servidor está cayendo menos del 0.015% de los paquetes recibidos en función de su salida anterior. Sus clientes no notarían ninguna interrupción del servidor o incluso nerviosismo hasta que su tasa de caída / tasa de error supere el 1%. Incluso entonces, apenas se notaría. TCP se encargará de cualquiera de las retransmisiones requeridas.