Muitos pacotes descartados ao tcpdumping na interface ocupada

Meu desafio

Eu preciso fazer o 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.

Resumindo

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

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 $FILTERcontém src / dst filtros para que eu possa usar -i any. A razão para isso é que eu tenho duas interfaces e gostaria de executar o dump em um único thread em vez de dois.

compress.sh cuida da atribuição de tar a outro núcleo da CPU, compacta os dados, fornece um nome de arquivo razoável e move-o para um local de arquivamento.

Não posso especificar duas interfaces, portanto, escolhi usar filtros e despejar da anyinterface.

No momento, não faço tarefas domésticas, mas planejo monitorar o disco e, quando tiver 100G, começarei a limpar os arquivos mais antigos - isso deve ser bom.

E agora; meu problema

Eu vejo pacotes descartados. Isso é de um dump que está em execução há algumas horas e coletou cerca de 250 GB de arquivos pcap:

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

Como evitar que muitos pacotes sejam descartados?

Essas coisas que eu já tentei ou olhei

Alterou o valor /proc/sys/net/core/rmem_maxe o /proc/sys/net/core/rmem_defaultque realmente ajudou - na verdade, ele cuidou de quase metade dos pacotes descartados.

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

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

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

O tcpdump armazena os dados recebidos em um buffer de anel. Se o buffer exceder o limite antes que o tcpdump processe 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 -Bopção:

tcpdump -B 4096 ...

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

Acabei encontrando uma solução que é 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 era mudar o tamanho do buffer do anel, conforme sugerido por Michael Hampton.

Além disso, criei um ramfs e fiz o dumping ao vivo, reescrevi meu script de compactação para cuidar de mover os dumps do ramfs para o disco. Isso diminuiu muito pouco, mas o suficiente para ser notável - mesmo que todos os testes e testes de desempenho 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ê pensava.