mi reto
Necesito realizar tcpdumping de una gran cantidad de datos; en realidad, desde 2 interfaces que quedan en modo promiscuo y que pueden ver una gran cantidad de tráfico.
En resumen
- Registre todo el tráfico en modo promiscuo desde 2 interfaces
- Esas interfaces sonnoasignado una dirección IP
- Los archivos pcap deben rotarse cada ~1G
- Cuando se almacenen 10 TB de archivos, comience a truncar el más antiguo
lo que hago actualmente
Ahora 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
Contiene $FILTERfiltros src/dst para que pueda usarlos -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.shse encarga de asignar tar a otro núcleo de CPU, comprimir los datos, darle un nombre de archivo razonable y moverlo a una ubicación de archivo.
No puedo especificar dos interfaces, por eso elegí usar filtros y volcar desde anyla interfaz.
En este momento, no hago ninguna limpieza, pero planeo monitorear el disco y cuando me queden 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 ha estado ejecutándose durante algunas horas y recopiló 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 pierdan tantos paquetes?
Estas cosas ya las probé o miré.
Cambió el valor de /proc/sys/net/core/rmem_maxy /proc/sys/net/core/rmem_defaulteso realmente ayudó; de hecho, se encargó de aproximadamente la mitad de los paquetes descartados.
yo también he miradotrago- El problema con Gulp es que no admite múltiples interfaces en un 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 activar la rotación automática. Obtener un archivo enorme de 10 TB no es muy eficiente y no tengo una máquina con más de 10 TB de RAM en la que pueda ejecutar Wirehark, así que eso está descartado.
¿Tienes alguna sugerencia? Quizás incluso sea una mejor manera de hacer mi volcado de tráfico.
Respuesta1
tcpdump almacena los datos entrantes en un búfer en anillo. Si el búfer se desborda antes de que tcpdump procese su contenido, perderá paquetes.
El tamaño predeterminado del búfer circular es probablemente 2048(2MiB).
Para aumentar el tamaño del búfer, agregue la -Bopción:
tcpdump -B 4096 ...
También deberías intentar utilizar un almacenamiento en disco más rápido.
Respuesta2
Terminé encontrando una solución con la que vivir. Los paquetes eliminados se han reducido de 0,0047% a 0,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 era cambiar el tamaño del búfer circular como sugirió Michael Hampton.
Además, creé un ramfs y realicé un volcado en vivo, 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, aunque todas las pruebas y evaluaciones comparativas del disco muestran que el disco no debería ser el cuello de botella. Supongo que el tiempo de acceso es muy importante aquí.
Desactivar Hyper Threading también hizo más de lo que pensaba.