Muitos pacotes descartados ao tcpdumping na interface ocupada

Muitos pacotes descartados ao tcpdumping na interface ocupada

Meu desafio

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

Resumindo

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

O que eu faço atualmente

No momento 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

Contém $FILTERfiltros src/dst para que eu possa usar arquivos -i any. A razão para isso é que tenho duas interfaces e gostaria de executar o dump em um único thread em vez de dois.

compress.shcuida 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 arquivo.

Não consigo especificar duas interfaces, portanto optei por usar filtros e despejar da anyinterface.

No momento, não faço nenhuma limpeza, mas pretendo monitorar o disco e quando tiver 100G restantes, começarei a limpar os arquivos mais antigos - isso deve ficar bem.

E agora; meu problema

Vejo pacotes descartados. Isto vem 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 posso evitar que tantos pacotes sejam descartados?

Essas coisas que eu já tentei ou olhei

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

Eu também olheigole- o problema do 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 obstáculo no meu caso.

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

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

Responder1

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

O tamanho padrão do buffer de anel é 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.

Responder2

Acabei encontrando uma solução com a qual conviver. O número de pacotes descartados diminuiu de 0,0047% para 0,00013% - o que não parece muito a princípio, mas quando falamos de milhões de pacotes, é bastante.

A solução consistia em várias coisas. Uma delas era alterar o tamanho do buffer circular conforme sugerido por Michael Hampton.

Além disso, criei um ramfs e fiz um dump ao vivo para ele, reescrevi meu script de compactação para cuidar da movimentação dos dumps do ramfs para o disco. Isso apenas diminuiu muito pouco a quantidade, mas o suficiente para ser notável - embora 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.

informação relacionada