ESXi vmnic Link Flapping and Network Drops During VM-to-VM File Transfers

Products

VMware vSphere ESXi

Issue/Introduction

Network connectivity drops (Ping Request Timed Out) when initiating file transfers between two Virtual Machines (VMs) residing on the same ESXi host, Standard vSwitch, and Port Group.
File transfers between a VM and an external client work without issue.
The ESXi host logs indicate the physical uplink (vmnic) disconnecting and automatically reconnecting approximately 5 minutes later without manual intervention.

Log excerpt (vmkernel.log):

2026-04-10T08:27:13.470Z In(182) vmkernel: cpu2:2097999)igbn: igbn_CheckLink:1628: vmnicX: Link is down
... [5 minutes elapsed] ...
2026-04-10T08:32:16.666Z In(182) vmkernel: cpu2:2097999)igbn: igbn_CheckLink:1628: vmnicX: Link is up

Environment

VMware vSphere ESXi

Cause

This issue is caused by a subnet mask mismatch within the guest Operating Systems of the interacting VMs, which inadvertently triggers a Layer 2 broadcast storm.

When the Source VM has a subnet mask configured such that the Destination VM's IP address falls exactly on its calculated Broadcast Address, the following chain of events occurs:

Broadcast Generation: The Source VM's OS treats the unicast file transfer as a network broadcast and addresses the Ethernet frames to the universal broadcast MAC (FF:FF:FF:FF:FF:FF).
Uplink Flooding: The ESXi Standard vSwitch receives the broadcast traffic and floods it to all available ports, including pushing the heavy file transfer traffic out of the physical uplink (vmnic).
Physical Switch Err-Disable: The physical network switch receives a massive, unexpected spike in broadcast traffic. To protect the network, the switch's Storm Control feature immediately shuts down the port, resulting in an err-disable state. This causes the ESXi host to report the vmnic link as down.
Automatic Recovery: Most enterprise physical switches are configured with an automatic err-disable recovery timer with a default of 300 seconds (5 minutes). Once the timer expires, the physical switch brings the port back up, matching the 5-minute gap seen in the ESXi logs.

Example Scenario (Masked IPs):

Source VM: 10.X.X.238 with Subnet Mask 255.255.255.240 (/28).
Destination VM: 10.X.X.239 with Subnet Mask 255.255.255.224 (/27).
Result: For the Source VM's /28 subnet, the network ID is 10.X.X.224, the usable IP range is .225 through .238, and the broadcast address is exactly 10.X.X.239.

Verification via ESXi CLI

To prove that a broadcast storm is occurring before the link drops, you can monitor the physical NIC statistics via the ESXi shell.

Connect to the ESXi host via SSH.
Run the following command to check the baseline statistics for your uplink (replace vmnicX with your specific adapter):
```
esxcli network nic stats get -n vmnicX
```
Look specifically for the Broadcast packets transmitted counter.
Initiate the file transfer between the two VMs.
Quickly run the command again. You will see the Broadcast packets transmitted counter skyrocketing by thousands or millions of packets, confirming the vSwitch is flooding the file transfer out the physical uplink as broadcast traffic.

Resolution

To resolve this issue, you must correct the subnet mask configuration inside the guest Operating System of the offending VM to match the actual network topology.

Identify the correct subnet mask for the network based on the default gateway and DHCP/IPAM allocation (e.g., 255.255.255.224).
Log into the guest OS of the Source VM.
Update the network adapter settings to use the correct subnet mask so that both VMs are consistently configured.
Save the changes and restart the network service or the VM if required by the guest OS.

Once the subnet mask is corrected, the Source VM will properly recognize the Destination VM as a unicast host on the same subnet. The VM-to-VM traffic will then route internally over the vSwitch backplane via memory without egressing the physical vmnic, preventing the physical switch from dropping the link.