Muchos paquetes descartados cuando tcpdumping en una interfaz ocupada


11

Mi reto

Necesito hacer tcpdumping de una gran cantidad de datos, en realidad de 2 interfaces que quedan en modo promiscuo que pueden ver mucho tráfico.

Para resumirlo

  • Registre todo el tráfico en modo promiscuo desde 2 interfaces
  • A esas interfaces no se les asigna una dirección IP
  • los archivos pcap deben rotarse por ~ 1G
  • Cuando se almacenan 10 TB de archivos, comience a truncar el más antiguo

Lo que hago actualmente

En este momento uso tcpdump así:

ifconfig ethX promisc
ifconfig ethX promisc
tcpdump -n -C 1000 -z /data/compress.sh -i any -w /data/livedump/capture.pcap $FILTER

El $FILTERcontiene filtros src / DST para que pueda utilizar -i any. La razón de esto es que tengo dos interfaces y me gustaría ejecutar el volcado en un solo subproceso en lugar de dos.

compress.sh se encarga de asignar tar a otro núcleo de CPU, comprime los datos, le da un nombre de archivo razonable y lo mueve a una ubicación de archivo.

No puedo especificar dos interfaces, por lo tanto, he elegido usar filtros y volcar desde la anyinterfaz.

En este momento, no hago ninguna tarea de limpieza, pero planeo monitorear el disco y cuando me quede 100G, comenzaré a borrar los archivos más antiguos, esto debería estar bien.

Y ahora; mi problema

Veo paquetes caídos. Esto es de un volcado que se ha estado ejecutando durante unas horas y ha recopilado aproximadamente 250 gigas de archivos pcap:

430083369 packets captured
430115470 packets received by filter
32057 packets dropped by kernel  <-- This is my concern

¿Cómo puedo evitar que se caigan tantos paquetes?

Estas cosas que ya probé o miré

Cambió el valor de /proc/sys/net/core/rmem_maxy /proc/sys/net/core/rmem_defaultlo que realmente ayudó: en realidad se hizo cargo de casi la mitad de los paquetes descartados.

También he visto gulp : el problema con gulp es que no admite múltiples interfaces en un solo proceso y se enoja si la interfaz no tiene una dirección IP. Desafortunadamente, eso es un factor decisivo en mi caso.

El siguiente problema es que cuando el tráfico fluye a través de una tubería, no puedo poner en marcha la rotación automática. Obtener un archivo enorme de 10 TB no es muy eficiente y no tengo una máquina con 10TB + RAM en la que pueda ejecutar wireshark, así que eso está fuera.

¿Tienes alguna sugerencia? Tal vez incluso una mejor manera de hacer mi volcado de tráfico por completo.


En mi caso, estaba usando la opción -s0, cambiarlo a -s1600 (justo encima de MTU) lo resolvió para mí.
LatinSuD

Respuestas:


11

tcpdump almacena los datos entrantes en un buffer de anillo. Si el búfer se desborda antes de que tcpdump procese su contenido, entonces pierde paquetes.

El tamaño predeterminado del búfer en anillo es probablemente 2048 (2MiB).

Para aumentar el tamaño del búfer, agregue la -Bopción:

tcpdump -B 4096 ...

También debe intentar usar un almacenamiento en disco más rápido.


Intentaré cambiar el tamaño del búfer. Estoy casi seguro de que la velocidad de almacenamiento en disco no es el problema. Escribe datos con alrededor de 15M / seg al descargar y al crear un archivo de 17 conciertos: 17179869184 bytes (17 GB) copiados, 23.5737 s, 729 MB / s (usando bs = 8k count = 2048k)
Frands Hansen

7

Terminé encontrando una solución para vivir. Los paquetes descartados se redujeron de .0047% a .00013%, lo que no parece mucho al principio, pero cuando hablamos de millones de paquetes, es bastante.

La solución consistió en varias cosas. Una fue cambiar el tamaño del búfer de anillo como lo sugirió Michael Hampton.

Además, creé un ramfs y viví volcado a eso, reescribí mi script de compresión para encargarme de mover los volcados de ramfs al disco. Esto solo disminuyó la cantidad muy poco, pero lo suficiente como para ser notable, a pesar de que todas las pruebas y evaluaciones comparativas del disco muestran que el disco no debe ser el cuello de botella. Supongo que el acceso es muy importante aquí.

Desactivar el hiperprocesamiento también hizo más de lo que pensabas


¿Te refieres a "deshabilitar el subproceso hiper"? ¿Cuánto puede ayudar? Gracias.
poordeveloper

Francamente, ya no puedo recordar los detalles. He cambiado de lugar de trabajo desde entonces, pero por lo que escribí parece que deshabilitar el hiperprocesamiento ayudó al problema.
Frands Hansen
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.