Muitos pacotes descartados quando tcpdumping na interface ocupada

Question

Meu desafio

Eu preciso fazer tcpdumping de muitos dados - na verdade, a partir de 2 interfaces deixadas no modo promíscuo que são capazes de ver muito tráfego.

Para resumir

• Registrar todo o tráfego no modo promíscuo de 2 interfaces
• Essas interfaces são não atribuídas a um endereço IP
Os arquivos
• pcap devem ser rotacionados por ~ 1G
• Quando 10 TB de arquivos são armazenados, comece a truncar os mais antigos

O que eu faço atualmente

Agora eu uso o tcpdump assim:

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

O $FILTER contém filtros src / dst para que eu possa usar -i any . A razão para isso é que eu tenho duas interfaces e gostaria de executar o despejo em um único thread em vez de dois.

compress.sh cuida de atribuir tar a outro núcleo da CPU, compactar os dados, fornecer um nome de arquivo razoável e movê-lo para um local de arquivamento.

Eu não posso especificar duas interfaces, assim escolhi usar filtros e despejo da interface any .

Neste momento, eu não faço nenhum serviço de limpeza, mas planejo monitorar o disco e quando tiver 100G restantes, vou começar a limpar os arquivos mais antigos - isso deve ser bom.

E agora; meu problema

Eu vejo pacotes descartados. Este é um dump que está sendo executado por algumas horas e coletou aproximadamente 250 GB de arquivos pcap:

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

Como posso evitar que muitos pacotes sejam descartados?

Essas coisas que eu já tentei ou olhei

Alterou o valor de /proc/sys/net/core/rmem_max e /proc/sys/net/core/rmem_default , o que realmente ajudou - na verdade, ele cuidou de apenas metade dos pacotes descartados.

Eu também olhei gulp - o problema com o gulp é que ele não suporta múltiplas interfaces em um processo e fica irritado se a interface não tiver um endereço IP. Infelizmente, isso é um problema no meu caso.

O próximo problema é que, quando o tráfego flui através de um pipe, não consigo fazer a rotação automática. Conseguir um arquivo enorme de 10 TB não é muito eficiente e eu não tenho uma máquina com 10TB + RAM que eu possa executar o wireshark, então está fora.

Você tem alguma sugestão? Talvez até mesmo uma maneira melhor de fazer o meu despejo de tráfego por completo.

    

Answer 1

Acabei encontrando uma solução com a qual conviver. Os pacotes descartados foram reduzidos de 0,0047% para 0,00013% - o que não parece muito a princípio, mas quando estamos falando de milhões de pacotes, é bastante.

A solução consistiu em várias coisas. Uma delas foi alterar o tamanho do buffer de toque, conforme sugerido por Michael Hampton.

Além disso, criei um ramfs e fiz live dump para isso, reescrevi meu script de compactação para cuidar de mover os despejos de ramfs para o disco. Isso só diminuiu muito pouco, mas o suficiente para ser notável - mesmo que todos os testes e benchmarking do disco mostrem que o disco não deve ser o gargalo. Eu acho que o tempo de acesso é muito importante aqui.

Desativar o hyper-threading também fez mais do que você imaginava.

    

Answer 2

O tcpdump armazena dados de entrada em um buffer de anel. Se o buffer estourar antes do tcpdump processar seu conteúdo, você perderá pacotes.

O tamanho padrão do buffer de toque é provavelmente 2048 (2MiB).

Para aumentar o tamanho do buffer, adicione a opção -B :

tcpdump -B 4096 ...

Você também deve tentar usar um armazenamento em disco mais rápido.