Enhanced Network Stack (ENS) Unexpectedly Disabled on Uplinks After ESXi Host Reboot

Products

VMware vSphere ESXi

Issue/Introduction

ESXi hosts may have recently been upgraded, or rebooted.
Post upgrade/reboot, vMotion of a VM to the upgraded/rebooted ESXi fails with error below observed in the vSphere client:

Migration to host <<destination-host-IP>> failed with error Timeout (195887137).
vMotion migration [<migration-IDs] failed to read stream payload from network: Timeout. Failed waiting for data. Error 195887137. Timeout.
The below errors may also be seen on vCenter:

Failed waiting for data. Error 195887179. Connection reset by peer.
vMotion migration [<migration-IDs>] failed to send buffer to remote host: Timeout. vMotion migration [<migration-IDs>] failed writing stream completion: Timeout Migration to host <<destination-host-IP>> failed with error Timeout (195887137).
The migration transfer failed during the receive operation to socket <socket-ID>: received 0/36 bytes: Connection reset by peer. vMotion migration [<migration-IDs>] failed to read stream keepalive: Connection reset by peer
The impacted ESXi host will have "ENS driven" parameter set to false:
SSH to ESXi host as root user and check the output of the command "esxcfg-nics -e". The "ENS driven" parameter will be set to false.

esxcfg-nics -e

Name Driver ENS Capable ENS Driven INTR Capable INTR Enabled MAC Address
vmnic0 bnxtnet True False True False #################
vmnic1 bnxtnet True False True False #################
vmnic2 bnxtnet True False True False #################
vmnic3 bnxtnet True False True False #################
However, ENS is live on the switch in /var/log/vmkernel.log:

2026-07-07T09:33:53.907Z In(182) vmkernel: cpu8:2097584)ENS: Ens_NetWorldCreateWorlds:544: Created 8 ENS RX worlds 8 TX worlds for portset: DvsPortset-0
2026-07-07T09:33:53.907Z In(182) vmkernel: cpu8:2097584)ENS: Ens_CreateSwitch:2482: Create ENS switch DvsPortset-0: maxPorts 16384, swID 0, mode: interrupt
vMotion fails with error "Failed to read stream payload from network: Timeout. Failed waiting for data. Error 195887137."

Environment

VMware NSX 4.2.4 and lower
VMware ESXi 8.0 Update 3j and lower

Cause

NSX jumpstart script doesn't handle a specific scenario in which the host's uplink can be left out of ENS mode while the switch itself remains configured for ENS. Following an ESXi host reboot, the virtual switch itself remains configured for ENS, but the underlying uplinks came back up in the standard (non-ENS) network stack—creating a mismatch between the switch's intended ENS state and what NSX and the ESXi host actually had running.
This may result in poor performance on the uplink layer, which will lead to vMotion failures. This mismatch can also degrade network performance such as a sudden increase in per-packet processing latency and packet loss on the affected hosts, since traffic that should take the ENS fast path is instead using the standard network stack.

Resolution

This is a known issue impacting VMware NSX. Subscribe to this KB article to be updated if a fix version becomes available.

Workaround:

If a host is already in the bad state, follow the steps below to clear the mismatch:

Put the impacted ESXi host to maintenance mode.
Identify the "DvsPortset" identifier of the impacted distributed switch:
1. SSH to the ESXI host.
2. Identify ENS driven vmnics:
  # esxcfg-nics -e
3. Find the "DvsPortset" ID of the virtual switch using these vmnics:
  # net-stats -l
4. Disable ENS on the DvsPortset in question (e.g. DvsPortset-0):
  # esxcfg-vswitch -Y DvsPortset-0
5. Wait 5 seconds.
6. Re-enable ENS on the DvsPortset:
  esxcfg-vswitch -y -i DvsPortset-0
Take the host out of maintenance mode and confirm reproducibility of the issue.

Additional Information

If you believe you have encountered this issue, and the workaround doesn't clear the mismatch, open a support case with Broadcom Support and refer to this KB article.

For more information, see Creating and managing Broadcom support cases.