Depurando por que os pacotes de rede estão sendo descartados

1

Prefácio :

Eu tenho um aplicativo que estou testando atualmente que é executado em RHEL 6 . A configuração do meu teste é o aplicativo instalado em um dispositivo incorporado, conectado por um cabo Ethernet ao PC que se comunica com a máquina virtual no PC em que o Linux está sendo executado. A máquina virtual (no VMWare Workstation) no PC e o dispositivo embarcado têm um endereço IP estático, já que precisam se comunicar através do cabo Ethernet.

O aplicativo precisa se comunicar usando uma ferramenta pub-sub , neste caso, RTI DDS . Isso foi testado em um ambiente sem fio e em outro ambiente com fio com um PC diferente, mas com a mesma máquina virtual e, em ambos os ambientes, o pub-sub funcionou.

Problema:

Ao testar o pub-sub na configuração atual, podemos ver através de wireshark todos os pacotes fragmentados entregues a partir do dispositivo embarcado são entregues ao sistema operacional principal do PC (neste caso, windows). No entanto, quando os pacotes fragmentados são enviados do sistema operacional principal para o sistema operacional de máquinas virtuais, a máquina virtual está recebendo apenas o último pacote que foi recebido, como visto em wireshark , e o restante é descartado.

Até agora, tentamos desativar os dispositivos firewalls e pinging um do outro, todos funcionando corretamente e sem problemas. Assim, não nos deu nenhuma ideia de por que os pacotes estão sendo descartados.

Qual é o caminho para depurar como e por que os pacotes de rede estão sendo descartados, talvez até mesmo possível através do wireshark, já que estamos atualmente usando essa ferramenta?

    
por jgr208 25.04.2016 / 23:39

1 resposta

1

Em geral, suspeito que o MTU (tamanho do quadro) é a raiz do problema. Eu tenho algumas razões e algumas sugestões.

Primeiro, esse comportamento varia de acordo com o L2 (isso só acontece com o tráfego com fio em oposição ao sem fio). Isso por si só é suspeito e sugere que há um problema no nível da interface.

Em segundo lugar, a fragmentação de pacotes é um sintoma do desalinhamento da MTU. A fragmentação de pacotes não é um problema em si, mas não é ideal, pois cria sobrecarga e pontos adicionais de falha.

Em terceiro lugar, apenas "o último pacote recebido" recebido pela VM guest Linux é um problema conhecido em certas NICs e versões de VMware.

Agora, como o host está recebendo qualquer caso, e como o tamanho da MTU afeta somente os pacotes enviados , não é possível alterar sua MTU na VM e esperar algo diferente. Você pode, no entanto, fazer o seguinte:

Sugestões

Determine se a MTU é um problema

Execute ping -f -l (your host vm adapter mtu, which is a #) your.guest.ip.or.name , como ping -f -l 1500 myguest .

Se funcionar quando você usa um valor -l da sua MTU atual, estou errado e ignore. Caso contrário, continue diminuindo o valor -l até que ele responda e, em seguida, defina seu adaptador virtual do host para ter essa MTU. Consulte link

Use um driver vNic diferente na estação de trabalho vmware

Existem problemas conhecidos com determinados sistemas operacionais e determinados vNic e alguns hypervisors. Eu incluo algumas pesquisas de problemas de vmware conhecidos abaixo, mas apenas tente usar um driver vNIC diferente no convidado. Se você estiver usando o E1000, tente um dos mais novos. Se você estiver usando vmxnet3, tente 2 ou E1000. Etc. Se isso corrige, você pode mantê-lo ou procurar o driver específico que você tinha antes para descobrir como corrigi-lo do vmware.

Experimente um MTU mais baixo no seu host

Reduza o MTU em seu host de onde quer que esteja agora (provavelmente cerca de 1500) para algo em torno de 1380. Se o problema desaparecer, continue aumentando até chegar a cerca de 1468. Deixe-o.

    
por 26.04.2016 / 01:37