Velocidade de upload lenta para máquinas virtuais VMWare funcionando via pfSense

Question

Temos servidores ProLiant DL360 Gen8 e Gen9 executando o VMWare ESXi 6.0 com máquinas virtuais em várias versões do Windows que são roteadas por meio do pfSense 2.3.4-RELEASE (64 bits) com o pacote Open-VM-Tools 10.1.0,1 .

As máquinas virtuais que funcionam via pfSense estão demonstrando velocidade de upload muito baixa, por exemplo: ping 2ms, download de 134 Mbps, upload de 0,25 Mbps (a propósito, 0,25 Mbps é velocidade aceitável para conexões de área de trabalho remota, mas, na prática RDP mal funciona, o cliente freqüentemente fica parado por alguns segundos, ou a atualização ocorre em quadrados, levando de 5 a 10 segundos para atualizar a tela, é instável ou às vezes até se reconecta - tornando o trabalho via RDP praticamente impossível).

Os ajustes nas máquinas afetadas do Windows, como "netsh interface tcp definir global autotuninglevel = highlyrestricted", não alteraram nada.

As máquinas virtuais que têm conexão direta, ignorando o pfSense, não têm esses problemas - elas têm aproximadamente a mesma velocidade de upload e download.

Todas as máquinas virtuais (pfSense, Windows, etc.) estão usando o adaptador VMXNET3.

As opções a seguir são todas desmarcadas no pfSense:

[ ] Disable hardware checksum offload
[ ] Disable hardware TCP segmentation offload
[ ] Disable hardware large receive offload

Não há forma de tráfego no pfSense. Qual pode ser o motivo?

Se eu VERIFICAR a opção "Desativar descarga de recebimento grande de hardware", ela se tornará rápida novamente, mas não quero desabilitá-la, quero que o pfSense use descarga de recebimento grande de hardware com VMWare VMXNET3.

Atualização: Eu atualizei o VMWare para o 6.5 mais recente com todos os patches e pfSense para o 3.4.5 BETA, atualizei o firmware para as versões mais recentes, e isso não ajudou.

    

Answer 1

Eu resolvi o problema desativando "Hardware Large Receive Offloading" nas configurações do pfSense (Sistema / Avançado / Rede | Interfaces de Rede)

Existe uma caixa de seleção "Desativar hardware de recebimento de carga grande" e eu mudei para "Verificado" (ON).

A descrição diz o seguinte sobre esta opção:

Checking this option will disable hardware large receive offloading (LRO). This offloading is broken in some hardware drivers, and may impact performance with some specific NICs. This will take effect after a machine reboot or re-configure of each interface.

Outras opções estão desmarcadas. Então agora as opções nas "Interfaces de Rede" são as seguintes:

[ ] Disable hardware checksum offload
[ ] Disable hardware TCP segmentation offload
[✓] Disable hardware large receive offload

De acordo com a documentação da HP, os adaptadores de rede em Gen8 / Gen9 (modelo 331 com base no Broadcom BCM5719 chipset ) suportam técnicas de descarregamento TCP / IP padrão, incluindo: - TCP / IP, UDP checksum offload (TCO) (move o descarregamento de checksum TCP e IP da CPU para o adaptador de rede). - Large send offload (LSO) ou TCP segmentation offload (TSO) (permite que a segmentação TCP seja manipulada pelo adaptador em vez da CPU).

Isso é o que pfSense escreve sobre esses recursos :

The settings for Hardware TCP Segmentation Offload (TSO) and Hardware Large Receive Offload (LRO) under System > Advanced on the Networking tab default to checked (disabled) for good reason. Nearly all hardware/drivers have issues with these settings, and they can lead to throughput issues. Ensure the options are checked. Sometimes disabling via sysctl is also necessary.

Na verdade, não havia problemas de hardware / drivers, mas um erro de configuração. LRO e TSO nunca devem ser habilitados em um roteador. Somente se o pfSense estiver configurado como um ponto final (por exemplo, um servidor DNS), essas opções podem estar ativadas.

Deixe-me citar a entrada do bug no FreeBSD :

From my testing this is not a bug and everything is working as designed. I am seeing a large decrease in performance when LRO is turned on and using pfSense as a gateway. This is due to the originating packets having the IP DF (don’t fragment) flag set which then gets combined into larger packets via LRO. When this (larger) packet needs to be fragmented to match the other NIC the FreeBSD kernel sees the DF flag, drops the packet, and then sends back an ICMP “unreachable - need to frag” message to the sender. The reason it works at all is due to other traffic which disallows the LRO to occur and some packets get forwarded. One test I did was turning LRO on and using scp to put a file onto the pfSense appliance which resulted in good performance (not seeing the same drop in performance). I would be interested if you 1) see good performance with LRO turned on and scp a large file to the appliance and 2) see ICMP "need to frag" with LRO turned on and scp to a machine on the remote side. Since the pfSense appliance is being used as a gateway you should leave LRO turned off.

    

Answer 2

Eu experimentei esse problema algumas vezes, e a solução rápida é: reinicialização. O gerenciamento do Windows da memória não é o melhor, e eles precisam de uma reinicialização às vezes.

Se a reinicialização não funcionar, determine o problema. São os servidores ou o cliente? Servidores estão no modo TS ou TS apenas para administração? Você está se conectando ao console ou a uma sessão remota padrão?

Pense, também, se eles são todos "novos" computadores (servidores, suportados), eles podem obter a mesma atualização. Talvez você precise de uma atualização no cliente para trabalhar com as alterações do serviço do servidor de terminal.

Como resposta direta, administro um grupo de 15 servidores há mais de 6 anos. Do Windows 2000 para o Windows 2012 R2. Eu tenho esse problema às vezes, mas 90% das vezes eles são resolvidos com uma reinicialização. Os outros 10%, com uma atualização do cliente.

Minha recomendação sobre isso, use o serviço do WSUS e gerencie a aprovação de todas as atualizações instaladas nos servidores.

p. Se você não conseguir resolver o problema, poderá usar o utilitário "restauração do sistema" para restaurar a máquina há uma semana, antes de instalar as atualizações. A desinstalação não é reconfigurada, mas a restauração do sistema reverte todo o sistema para um estado passado (desinstalando o aplicativo, desfazendo as alterações de configuração, mas também excluindo seus documentos ou outras coisas na máquina).