Windows server 2008 with VMXNET 3, Blocks when enable Routing and Remote Access

[ramosmarco]

Hello every one,

May be this help other.

I have a Windows Server 2008 (SP2) on ESXi 5.0 with VMXNET 3 (VMware tools installed), everything was working fine until tried to enable Routing and Remote Access, as soon I clicked OK, the network gone, even ping not work, I get in via the VM console, and the Network Adapter looks enable without any error, but there was not connection and the network can’t be disabled, a couple of times the Windows Server stop responding, after restart works fine for about a minute and then the network goes again. I’d review everything on the Windows server, but apparently there were not problems, so I checked the VM Settings and change the Ethernet Adapter from VMXNET 3 to E1000 wuala!! problem solved, now Routing and Remote Access can be enable and disable. It supposes that VMXNET 3 its better, but who wants this kind of surprises on their Domain Controller?

Good luck,

Marco Ramos

[nilesh56]

Hi

Tried it over Win2K8 R2 over ESXi 5 with vmxnet3 is working fine for me...as it was a test setup evaluated it for some 30 min and was working.

[ramosmarco]

Yeah I understand it should work, it's a fresh VM and ESXi, hardware compatible!! Well E1000 looks not bad at all!!

Sent from my BlackBerry® smartphone

[inmarket]

Experiencing same problem with Workstation 8 on Windows server 2008.

It appears that there is a network traffic loop occuring when the routing and remote access service is started. This builds up until the machine becomes unresponsive. On my machines this takes a couple of minutes and using a network monitor I can watch it happenning.

Disabling VMNet1 and VMNet8 host adapters and disabling the VMWare NAT and routing services appears to reduce the speed of build up but not stop it.

I will try your solution of changing to the E1000 adapter on the guest.

[inmarket]

After lots of heart-ache and testing I found the following...

1. The E1000 adaptor did not help with my problem
   
2. It is related to network packet flags to do with quality of service and prioritisation. Some applications on the host that play with these charactoristics on the packet cause the problem to occur.
   
3. Once one of these tampered packets has been "discovered" by VMWare the problem will continue regardless of whether or not the original application is still running. Stopping the "Routing and Remote Access" service on the host or shutting down VMWare will temporarily "hide" the problem but restarting the service will restart the problem. The only way to avoid the problem is to not "trigger" it in the first place with one of the suspect applications. Once triggered, only a reboot will remove the problem.
   
4. An example application that triggers the problem:   "cFosSpeed System Service" which comes as part of the software suite on some motherboards and is run at system start time. Other applications in the group mentioned in 2) above can also trigger the problem.
   

VMWare have so far refused to acknoledge this as a problem with their software even though packet prioritisation is a normal (albiet uncommon) function to perform on a server.

Hope this helps some people with the same problem.