In order to troubleshoot network issues for a specific virtual machine running in vSphere, it is crucial to first determine which physical NIC (Uplink) on the ESXi Host the VM finally is using for sending uplink traffic.

In vSphere, uplink traffic refers to the network traffic sent from virtual machines (VMs), VMkernel ports, or other entities inside the virtual switch to the physical NICs (uplinks) that connect to the physical network. Monitoring and managing uplink traffic is essential for understanding network performance and troubleshooting issues.


To determine which physical NIC our virtual machine finally is using to send uplink traffic we can use the esxtop utility on the ESXi host.

You can run the esxtop utility using the ESXi Shell to communicate with the management interface of the ESXi host. You must have root user privileges.
Source: https://docs.vmware.com/en/VMware-vSphere/8.0/vsphere-monitoring-performance/GUID-D89E8267-C74A-496F-B58E-19672CAB5A53.html


Using the esxtop utility will provide real-time monitoring for resources on a ESXi host.

To run the utility just enter esxtop in the ESXi Shell of the corresponding ESXi host.

> ssh root@<FQDN or IP Address ESXi Host>
[root@ESXi-01:~] esxtop


Press n to view networking statistics.


PORT-ID identifies the port, DNAME shows the virtual switch name (here the distributed vSwitch from vCenter) and TEAM-PNIC is the physical NIC we are finally interested in and is used by the virtual machine for uplink traffic.

USED-BY here is my virtual machine named Matrix-Squid. The .eth0 suffix is the virtual network adapter of the virtual machine and under TEAM-PNIC we see here vusb1 which is the physical NIC of the ESXi Host, in my case here this is a USB NIC as my vSphere lab environment is using notebooks for the ESXi hosts. Usually under TEAM-PNIC you will see here names like vmnic1, vmnic2, …


So finally I can see above that my virtual machine named Matrix-Squid is using the physical NIC named vusb1 for uplink traffic.

Because for the distributed virtual switch in my case two physical NICs are configured, you cannot determine which physical NIC finally is used by the virtual machine for uplink traffic just by checking the configuration. Here the virtual machine also could use the vusb2 physical NIC to send uplink traffic.


In vCenter below we can associate physical network adapter (so called uplinks) with a distributed virtual switch.


Include two or more physical NICs in a team to increase the network capacity of a distributed port group or port. Configure failover order to determine how network traffic is rerouted in case of adapter failure. Select a load balancing algorithm to determine how the distributed switch load balances the traffic between the physical NICs in a team.

Route based on the originating virtual port -> Select an uplink based on the virtual port IDs on the switch. After the virtual switch selects an uplink for a virtual machine or a VMkernel adapter, it always forwards traffic through the same uplink for this virtual machine or VMkernel adapter.

Source: https://docs.vmware.com/en/VMware-vSphere/6.7/com.vmware.vsphere.networking.doc/GUID-73AB2E00-FE02-4D1B-970F-7D2F21F52825.html



To troubleshoot NIC errors and other network traffic faults in ESXi we can also use the following esxcli command.

# esxcli network nic stats get -n vmnicX

VxRail: High vSAN latency and CRC errors on network NIC stats
https://www.dell.com/support/kbdoc/en-us/000182663/high-vsan-latency-and-crc-errors-caused-by-faulty-sfp





Links

ESXTOP Guide
https://www.virten.net/vmware/esxtop/

Interpreting esxtop Statistics
https://www.dihe.de/docs/docs/DOC-9279.pdf

ESXTOP | Networking edition
https://next.nutanix.com/how-it-works-22/esxtop-networking-edition-39153

Configure NIC Teaming, Failover, and Load Balancing on a Distributed Port Group or Distributed Port
https://docs.vmware.com/en/VMware-vSphere/6.7/com.vmware.vsphere.networking.doc/GUID-73AB2E00-FE02-4D1B-970F-7D2F21F52825.html

Troubleshooting NIC errors and other network traffic faults in ESXi
https://knowledge.broadcom.com/external/article/341594

VxRail: High vSAN latency and CRC errors on network NIC stats
https://www.dell.com/support/kbdoc/en-us/000182663/high-vsan-latency-and-crc-errors-caused-by-faulty-sfp