Como capturar “pacotes descartados” no tcpdump

5

Eu tenho um problema com o desempenho da minha rede. Estou usando o Ubuntu 16.04 no VMware Cloud Server com NIC E1000. Mas vejo alguns pacotes descartados em seções do comando ifconfig:

root@ubuntu:~# ifconfig ens192
ens192    Link encap:Ethernet  HWaddr 00:50:56:03:25:14  
          inet addr:192.16.1.100  Bcast:192.16.1.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:574749 errors:0 dropped:83 overruns:0 frame:0
          TX packets:76478 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:44109471 (44.1 MB)  TX bytes:19484534 (19.4 MB)

Embora apenas alguns pacotes tenham sido descartados, mas meu servidor está executando um jogo on-line em tempo real, você sabe que isso afeta meus clientes que estão se conectando a ele.

Eu fiz em algumas pesquisas e explorando informações no Google, depois tentei alterar o arquivo de configuração para o anel de buffer, tamanho máximo do Windows e assim por diante. Mas ainda deixa meus pacotes.

Então, agora eu quero capturar os pacotes que caíram para analisar o tipo de pacote que ele é exatamente.

Eu também tentei essa captura para minha visualização no wireshark:

sudo tcpdump -i ens192 -n -w /var/www/html/logs.pcap -C 1 -Z root

Mas acho que não consigo ver quais pacotes são descartados! Acho que os pacotes descartados são ignorados antes de ir para o filtro do tcpdump.

Você pode me sugerir qual método para capturar "pacotes descartados" acima ( caiu: 83 )?

Obrigado antecipadamente!

    
por Joey 13.05.2017 / 11:26

2 respostas

3

O problema pode ser com o próprio tcpdump: Se ele não responder com rapidez suficiente, os pacotes antigos serão sobrescritos por novos, o que significa que eles serão descartados.

Se você capturar todos os bytes de cada pacote, é muito fácil invadir o buffer de captura de pacotes do kernel. Os sintomas dessa sobrecarga são que seu programa de rastreamento de pacotes relatará que descartou pacotes.

No caso do tcpdump, ele imprime um resumo de quantos pacotes foram capturados, filtrados e descartados quando você interrompe a captura. Por exemplo:

$ sudo tcpdump -i en0 -w trace.pcap
tcpdump: listening on en0, link-type EN10MB (Ethernet), capture size 65535 bytes
^C
94 packets captured
177 packets received by filter
0 packets dropped by kernel

Se a contagem dropped for diferente de zero, você precisará aumentar o tamanho do buffer de captura de pacote passando a opção -B para tcpdump. Experimente também sem um arquivo de captura, para ver se isso melhora a taxa de captura.

    
por 28.05.2017 / 09:47
2

Suas perguntas parecem pertencer a voltar e descobrir o que pode ter causado a queda de um pacote anterior em vez de tentar capturar pacotes em tempo real para tentar encontrar um que caia. Para o último, a resposta da harrymc deve ser capaz de capturar uma que você esteja procurando.

Para voltar e analisar o que pode estar acontecendo nessa interface, você precisa entender que os cabeçalhos pelos quais você está vendo RX packets:574749 errors:0 dropped:83 overruns:0 frame:0 são simplesmente resumos dos contadores subjacentes.

De meu comentário , recomendo usar o ethtool command / package from esta resposta para analisar alguns dos contadores para ver se consegue encontrar algo que apareça lugar.
ethtool -S ens192

No arquivo de origem dos drivers broadcom , vemos tp->rx_dropped++; para algumas ocasiões separadas no arquivo. 1   2 3 Qualquer um desses ou mais (dependendo do sua placa de rede exata e os drivers subjacentes) contribuem para o que poderia estar causando a queda de pacotes.

Para aliviar sua mente, seu servidor está reduzindo menos de 0,015% dos pacotes recebidos com base na saída acima. Seus clientes não notarão qualquer interrupção no servidor ou até mesmo instabilidade até que sua taxa de erro / taxa de erro fique acima de 1%. Mesmo assim, dificilmente seria perceptível. A TCP cuidará de qualquer das re-transmissões necessárias.

    
por 30.05.2017 / 00:50