Prefácio :
Eu tenho um aplicativo que estou testando atualmente e que é executado no RHEL 6. A configuração para o meu teste é o aplicativo instalado em um dispositivo embarcado, conectado por um cabo Ethernet ao PC que se comunica com a máquina virtual naquele PC em que o Linux é executado. A máquina virtual (na VMWare Workstation) no PC e o dispositivo incorporado têm um endereço IP estático, pois precisam se comunicar entre si pelo cabo Ethernet.
O aplicativo precisa se comunicar usando uma pub-subferramenta neste caso RTI DDS. Isso foi testado em um ambiente sem fio e outro com fio com um PC diferente, mas 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 que wiresharktodos os pacotes fragmentados entregues do dispositivo incorporado são entregues ao sistema operacional principal do PC (neste caso, o Windows). No entanto, quando os pacotes fragmentados são enviados do sistema operacional principal para o sistema operacional das máquinas virtuais, a máquina virtual recebe apenas o último pacote recebido conforme visto wiresharke os demais são descartados.
Até agora, tentamos desabilitar os dispositivos firewallse pinginguns dos outros, todos funcionando corretamente e sem problemas. Portanto, não nos deu nenhuma ideia de por que os pacotes estão sendo descartados.
Que maneira existe para depurar como e por que os pacotes de rede estão sendo descartados, talvez até possível através do wireshark, já que estamos usando essa ferramenta?
De um modo geral, suspeito que o MTU (tamanho do quadro) seja a raiz do problema. Eu tenho algumas razões e algumas sugestões.
Primeiro, esse comportamento varia de acordo com o L2 (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 do pacote é um sintoma de 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" sendo recebido por sua VM convidada do Linux é um problema conhecido com certas NICs e versões do VMware.
Agora, como o host está recebendo qualquer caso e como o tamanho do MTU afeta apenas os pacotes enviados , você não pode alterar seu MTU na VM e esperar algo diferente. No entanto, você pode fazer o seguinte:
Sugestões
Determine se o MTU é um problema
Corra
ping -f -l (your host vm adapter mtu, which is a #) your.guest.ip.or.name, comoping -f -l 1500 myguest.Se funcionar quando você usa um
-lvalor do seu MTU atual, estou errado e ignoro. Caso contrário, continue diminuindo o-lvalor até que ele responda e, em seguida, defina seu adaptador virtual de host para ter esse MTU. Consulte http://www.thincomputing.net/2011/06/28/mtu-size-mismatch-a-major-cause-of-disconnections/Use um driver vNic diferente na estação de trabalho vmware
Existem problemas conhecidos com determinados sistemas operacionais e determinados vNic e determinados hipervisores. Incluo algumas pesquisas de problemas conhecidos de vmware abaixo, mas apenas tento 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 resolver, você pode mantê-lo ou procurar o driver específico que você tinha antes para descobrir como corrigi-lo no vmware.
Experimente um MTU mais baixo em seu host
Reduza o MTU em seu host de onde ele está 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.