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.