VMware ESXi and vSphere Cluster Management

Network Failover Detection on VMware ESXi Standard vSwitches

Learn how VMware ESXi detects uplink failures on standard vSwitches and how to choose and configure Link status only or Beacon probing.

Network failover detection determines whether an uplink in an ESXi NIC team should still carry traffic. When ESXi identifies a failed uplink, it can move traffic for connected port groups to another available uplink. This protects virtual machines and VMkernel services when redundant physical network paths are configured correctly.

This lesson applies to standard virtual switches. For background, see the VMware ESXi online course and VMware ESXi fundamentals.

How Standard vSwitch Failover Works

A standard virtual switch, or vSwitch, is an ESXi-host-local virtual switch. It connects virtual machine port groups and VMkernel adapters to physical network adapters.

  • A port group supplies common network settings to virtual machines or VMkernel adapters.
  • An uplink is a physical ESXi network adapter assigned to the vSwitch.
  • NIC teaming uses multiple physical adapters for redundancy and, depending on the load-balancing policy, traffic distribution.
  • Active, standby, and unused assignments define how uplinks participate in normal traffic and failover.
  • Teaming and failover contains the load-balancing, failover-order, and network-failure-detection settings.

Detection alone does not create redundancy. At least one usable alternate uplink must be available, and the alternate path must connect to a network that provides the required VLANs and physical connectivity. If every uplink uses the same failed switch, cable route, or incorrectly configured network segment, changing the detection method cannot preserve service.

Purpose of Network Failover Detection

Network failover detection is the ESXi mechanism that decides whether an uplink in a NIC team has failed and should no longer be used. The decision is based on the selected detection method:

  • Link status only uses physical NIC carrier or link-state information.
  • Beacon probing uses Layer 2 beacon traffic exchanged and observed across participating team uplinks.

After an uplink is classified as failed, ESXi can use an active alternate or promote a standby uplink according to the configured failover order. The affected port groups continue using the vSwitch, but their traffic is sent through the available path.

Link Status Only

Link status only is the default network-failure-detection method. ESXi relies on the physical adapter reporting whether its local link, commonly called carrier, is up or down.

Failures Link Status Only Commonly Detects

  • A cable is disconnected from the ESXi host-side physical adapter.
  • The directly attached physical switch loses power and the adapter loses its link.
  • The directly connected switch port or physical link is disabled in a way that removes carrier.

For example, if an ESXi host has two uplinks and a cable is removed from one adapter, that adapter normally reports link down. ESXi can stop using the failed uplink and use the other adapter, provided the other uplink is active or available as standby and has the required network configuration.

Limits of Link Status Only

Link status only cannot generally detect a failure that leaves the local physical link up. A physical switch port may continue to report carrier even though traffic cannot reach its destination.

  • A VLAN assignment or trunk configuration on the directly connected switch port may be wrong.
  • A cable, interface, or device farther upstream may fail while the ESXi-to-switch link remains active.
  • An upstream routing or switching problem may interrupt the intended path without changing local NIC carrier.

This distinction is important: link state is not the same as end-to-end reachability. An interface can be electrically connected to a switch and still be unable to forward the VLAN traffic required by a virtual machine or VMkernel service.

Beacon Probing

Beacon probing uses Layer 2 beacon traffic across all uplinks participating in the team. ESXi sends and observes beacon traffic to determine whether the uplinks can see the expected Layer 2 network presence through the team.

Because it observes traffic rather than relying only on local carrier state, beacon probing can provide broader visibility into some failures involving:

  • Upstream cabling or switching paths that do not cause the local NIC to go down.
  • Some physical-switch or VLAN-path problems.
  • Network segments where the ESXi adapter remains connected but the expected Layer 2 path is no longer usable.

Beacon probing requires multiple participating uplinks. A single uplink cannot provide useful cross-uplink comparison. The physical network must also be designed so the probes can be transmitted and observed as intended. VLAN boundaries, switch configuration, and the placement of uplinks can affect what beacon probing can see.

Comparison of ESXi Network Failover Detection Methods

Method: Link status only

Default status: Default detection method

How failure is determined: ESXi uses physical NIC carrier or link-state reporting.

Failures commonly detected: Host-side cable disconnects, directly attached switch power loss, and other failures that remove the local physical link.

Failures that may remain undetected: Incorrect VLAN configuration and failures beyond the directly connected switch that leave local carrier up.

Compatibility considerations: Simpler behavior; review whether its visibility matches the topology.

Typical use case: Environments where direct physical-link failure detection is sufficient and predictable behavior is preferred.

Method: Beacon probing

Default status: Optional detection method

How failure is determined: ESXi sends and observes Layer 2 beacon traffic across participating team uplinks.

Failures commonly detected: Certain upstream, cabling, VLAN, or switch-path failures that do not produce local link-down status.

Failures that may remain undetected: Problems outside the visibility of the Layer 2 probing design, destination-specific failures, and issues where probes cannot be observed.

Compatibility considerations: Requires multiple participating uplinks and must not be combined with IP Hash load balancing.

Typical use case: Environments that need visibility into selected failures that leave local NIC link state up.

Beacon Probing and IP Hash Compatibility

IP Hash is a load-balancing policy that uses source and destination IP information to select traffic paths. Beacon probing must not be combined with IP Hash.

Before enabling beacon probing, inspect the existing load-balancing selection in Teaming and failover. If the vSwitch or relevant design uses IP Hash, stop and review the supported teaming design with the network and virtualization teams. Do not simply change network-failure detection without resolving the policy incompatibility.

Also review whether the uplinks are active, standby, or unused. Beacon probing requires multiple participating uplinks, while meaningful failover requires an alternate uplink with a working physical and logical path.

Choosing a Detection Method

Choose Link Status Only When

  • The main failure concern is a disconnected cable, failed local link, or directly attached switch outage that removes carrier.
  • The network design makes local link state a reliable indicator for the required failure scenarios.
  • A simple default behavior is preferred and additional Layer 2 probing is unnecessary.
  • The team has a valid alternate uplink with consistent switch-port and VLAN configuration.

Consider Beacon Probing When

  • Important failure modes can leave the ESXi NIC link up.
  • The topology has multiple participating uplinks and supports the intended beacon traffic.
  • The organization needs broader visibility into selected upstream, cabling, VLAN, or switch-path failures.
  • The existing load-balancing policy is compatible; specifically, beacon probing is not paired with IP Hash.

Make the decision using the complete design: physical topology, switch configuration, VLAN placement, uplink separation, active and standby assignments, load-balancing policy, and redundancy objectives. A detection method should be tested against the failures the environment is expected to survive.

Configure Network Failure Detection in the vSphere Web Client

  1. Select the target ESXi host that owns the standard vSwitch.
  2. Open the host's Manage area.
  3. Open Networking.
  4. Select the standard virtual switch to modify.
  5. Open the virtual-switch settings editor.
  6. Expand or select Teaming and failover.
  7. Locate Network failure detection.
  8. Select Link status only or Beacon probing.
  9. Review the load-balancing policy. If Beacon probing is selected, confirm that the policy is not IP Hash.
  10. Review the active, standby, and unused uplink assignments and confirm that the failover order provides the intended redundancy.
  11. Save the change.

Apply the setting to the correct standard vSwitch. A vSwitch-level change can affect the connected port groups and the virtual machines or VMkernel adapters that use them. Before saving, verify the host identity, switch name, uplink assignments, and port-group impact.

Configuration Checklist

  • The target is a standard vSwitch, not a different virtual-switch object.
  • At least one alternate uplink is available for meaningful failover.
  • Alternate physical switch ports have consistent VLAN and network settings.
  • The selected detection mechanism matches the anticipated failure modes.
  • Beacon probing is not used with IP Hash load balancing.
  • Uplink active, standby, and unused assignments match the redundancy design.
  • Management and VMkernel network dependencies have been considered before testing.

Failure Scenario and Expected Detection Coverage

Failure scenario: Host-side cable disconnect

Local NIC link state likely changes: Yes; the adapter normally reports link down.

Link status only result: Detects the link failure and can fail over to an available alternate uplink.

Beacon probing result: Can also identify the failed participating path, assuming the team and network allow the probes to be observed.

Validation approach: Use an approved controlled cable or link interruption and observe connectivity, failover, and recovery.

Failure scenario: Directly attached switch power loss

Local NIC link state likely changes: Normally yes, because the directly connected switch no longer supplies link.

Link status only result: Detects the local link loss and can move traffic to the alternate path.

Beacon probing result: Can detect the loss when the affected path stops participating as expected.

Validation approach: Use a controlled switch or lab test approved by operations; monitor host and workload connectivity.

Failure scenario: Wrong switch-port VLAN configuration

Local NIC link state likely changes: Usually no; the physical port can remain up.

Link status only result: May not classify the uplink as failed.

Beacon probing result: May provide additional detection when the VLAN and Layer 2 design allow the probe failure to be observed, but it is not guaranteed to detect every VLAN problem.

Validation approach: Check switch-port VLAN or trunk settings, port-group VLAN settings, and observed Layer 2 traffic.

Failure scenario: Upstream cabling or path failure

Local NIC link state likely changes: Not necessarily; the first switch link may remain up.

Link status only result: May miss the outage.

Beacon probing result: May detect some Layer 2 path failures if the probes can no longer be observed.

Validation approach: Trace the physical and logical path beyond the directly attached switch and compare results with the documented topology.

Validate the Configuration

  1. Return to the vSwitch Teaming and failover configuration and verify that the selected detection method is displayed.
  2. Confirm that multiple uplinks are assigned as intended.
  3. Check the active, standby, and unused failover order.
  4. Confirm that the alternate uplink connects to a usable network path with the required VLANs.
  5. Perform a controlled and approved failure test appropriate to the selected method.
  6. Observe ESXi host connectivity, virtual-machine connectivity, and management or VMkernel network connectivity during failover.
  7. Restore the failed path and observe recovery according to the configured policy.
  8. Document which failure types the selected method is expected to detect and which remain outside its coverage.

Testing should avoid uncontrolled disruption to management, storage, vMotion, or production traffic. If a test involves a shared physical switch or uplink, coordinate it with the teams responsible for the host and network infrastructure.

Troubleshooting

Connectivity Is Lost While the Uplink Still Appears Connected

Possible causes include a wrong VLAN configuration on the connected switch port, an upstream network failure, or another problem that does not remove local NIC carrier.

  • Check the configured network-failure-detection method and its limits.
  • Validate the physical switch port's VLAN or trunk configuration.
  • Compare the port-group VLAN configuration with the physical switch design.
  • Trace the path beyond the directly connected switch.
  • Evaluate whether beacon probing is suitable for the topology and current load-balancing policy.

Failover Does Not Occur After a Network-Path Outage

  • Link status may remain up, so Link status only does not classify the uplink as failed.
  • No usable standby or alternate uplink may be configured.
  • The outage may be outside the visibility of both the selected detection method and the physical topology.
  • The alternate uplink may lack the required VLAN or physical switch configuration.

Review failover order and uplink availability, determine whether the outage changes physical link state, and compare the scenario with the expected coverage of Link status only and Beacon probing.

Beacon Probing Is Unsuitable for the Existing Team

Review the current Teaming and failover load-balancing selection. If it is IP Hash, do not combine it with beacon probing. Reassess the teaming policy, physical uplink arrangement, switch configuration, and beacon visibility before selecting a different supported design.

Exam-Relevant Notes

  • Link status only is the default and depends on physical NIC link-state reporting.
  • Link status only can detect a host-side cable disconnect or a directly attached switch failure when the local link goes down.
  • Link status only may miss VLAN errors and failures beyond the directly connected switch when local carrier remains up.
  • Beacon probing uses Layer 2 traffic across multiple participating uplinks.
  • Beacon probing can provide broader failure visibility, but it depends on the physical and VLAN design.
  • Beacon probing must not be combined with IP Hash.
  • A detection method is useful only when the team has an alternate uplink and a valid alternate network path.