ESXCLI command to enable a disabled vmknic on vDS fails
Article ID: 344017
Updated On:
Products
Issue/Introduction
NOTE: Broadcom strictly advises against disabling or enabling VMkernel interfaces attached to a vSphere Distributed Switch (vDS) using the ESXCLI framework. Executing state changes via ESXCLI on vDS-backed interfaces causes the vDS to abruptly reclaim the allocated distributed port and desynchronizes the host from the vCenter Server database.
Administrators who previously disabled a vDS-backed VMkernel interface via esxcli network ip interface set -e false -i vmk1 will observe failures when attempting to re-enable it via esxcli network ip interface set -e true -i vmk1.
The operation fails with one of the following exact fault strings depending on the ESXi version and execution context:
Variant 1: Unable to complete Sysinfo operation. Please see the VMkernel log file for more details.: Not found: VSI node (105:VSI_NODE_net_tcpip_instances_plumb)
Variant 2: SysinfoException: Node (VSI_NODE_net_tcpip_instances_plumb) ; Status(bad0003)= Not found; Message= Instance(1):defaultTcpipStack Input(7) if=5 dvsId=<REDACTED_SECRETS> portId=528 cnId=819161394 macaddr=<REDACTED_MAC_ADDRESSES> tsomss=65535 mtu=1500
If the administrator removes and recreates the VMkernel interface via the vCenter Server UI after encountering this fault, the interface may exhibit a total loss of physical network connectivity (isolated from the physical fabric) despite appearing active in the management plane.
Environment
Cause
Bypassing vCenter Server API control to disable a vDS-backed VMkernel interface leaves an orphaned port lock in the local ESXi proxy switch (net-dvs) memory state. Subsequent attempts to re-enable the interface or recreate it fail because the TCP/IP instance cannot plumb through the locked distributed port ID.
Resolution
Delete the affected, non-functional VMkernel interface (e.g.,
vmk1) via the vCenter Server UI.Open an SSH session to the affected ESXi host and execute the following read-only diagnostic commands to identify orphaned local configuration remnants:
net-dvs -l | grep -A 15 -B 5 -i vmk1grep -i vmk1 /etc/vmware/esx.confIf the commands in Step 2 return output, the host state is desynchronized. Forcefully overwrite the proxy switch state by navigating to the vCenter Server UI > Right-click the vDS > Add and Manage Hosts > Manage Host Networking. Select the affected host and complete the wizard without making any topology changes.
Re-run the commands from Step 2. They must return absolutely zero output. (Note: If remnants persist after the resynchronization, place the host in Maintenance Mode and reboot it to manually flush the locked VMkernel memory space).
Recreate the VMkernel interface via the vCenter Server UI with the correct IP address, MTU, Subnet Mask, and TCP/IP stack parameters.
Network Connectivity Validation: If the newly recreated interface cannot reach the network gateway, execute the following packet capture pipeline on the ESXi host to isolate a physical fabric drop (e.g., missing VLAN tags):
pktcap-uw --vmk vmk1 -c 100 -o - | tcpdump-uw -enr - "arp or icmp"Open a secondary SSH session to the exact same host and forcefully generate traffic to the gateway:
vmkping -I vmk1 -c 4 <Gateway_IP>Analyze the packet capture output. If outbound
ARP Requestbroadcasts are visible (e.g.,who-has <Gateway_IP> tell <vmk1_IP>) but no inboundARP Replyframes are received, the ESXi host is correctly forwarding frames. The traffic is being dropped by the physical Top of Rack (ToR) switch. Provide this packet capture output to the physical network administrator as empirical evidence to correct the port trunk or 802.1Q VLAN configuration.
Additional Information
Feedback
