VMware ESXi and vSphere Cluster Management
Network Failover Detection on VMware ESXi Standard Switches
Learn how ESXi standard vSwitches detect uplink failures with Link status only or Beacon probing, including teaming compatibility, configuration, scenarios, and troubleshooting.
Network failover detection is the mechanism a VMware ESXi standard virtual switch uses to decide whether an uplink path is still usable. The result influences NIC teaming, uplink selection, and whether traffic should move away from a failed path.
This lesson covers the two detection choices available for a standard vSwitch: Link status only and Beacon probing. The setting is configured per standard virtual switch in its Teaming and failover settings.
Key terms
- Standard virtual switch (vSwitch): An ESXi host-local virtual switch that connects virtual machines and VMkernel services to physical networking.
- Physical NIC (pNIC): A host network adapter, commonly shown as a vmnic, that provides a physical uplink.
- Uplink: The connection from a vSwitch through a pNIC to the physical network.
- NIC teaming: The use of multiple physical uplinks to provide availability and, depending on the load-balancing policy, distribute traffic.
- Active uplink: An adapter currently eligible to carry traffic.
- Standby uplink: An adapter reserved for failover when an active adapter becomes unavailable.
- VLAN: A Layer 2 segmentation setting. A physical switch can report a port as connected even when its VLAN configuration does not match the ESXi network design.
Why network failover detection matters
A vSwitch can have several teamed uplinks. If one path fails, ESXi needs a signal indicating that the adapter or path should no longer carry traffic. The vSwitch can then use another eligible adapter according to the configured failover order.
For example, a team might contain two active uplinks and one standby uplink. If ESXi detects that one active path has failed, traffic can continue through the surviving active uplink. If both active paths become unavailable, the standby uplink can become eligible, assuming it is correctly connected and configured.
Detection does not repair a cable, correct a VLAN, or fix a physical switch. It only helps the vSwitch recognize a failure and change uplink selection. Correct cabling, VLANs, switch ports, and teaming policy remain essential.
Detection method: Link status only
Link status only uses the physical NIC's reported carrier or link state. The pNIC tells ESXi whether its directly connected physical link is up or down.
Link status only is the default detection choice for a standard vSwitch. It is useful when direct physical-link failures are the main concern and the network design is straightforward.
What it can detect
- A host-facing cable is unplugged.
- The pNIC loses carrier because of a damaged cable or transceiver.
- The directly connected physical switch loses power and the host-facing port goes down.
- The directly connected switch or port stops presenting a local link signal.
What it cannot validate
Link status only does not test whether traffic can reach the intended destination. A physical link can remain up while the network path is unusable.
- A switch port may be assigned to the wrong VLAN.
- A trunk or allowed-VLAN configuration may not match the ESXi port group.
- A cable or device failure beyond the directly connected switch may preserve carrier at the host.
- An upstream Layer 2 or Layer 3 problem may not change the local NIC link state.
For example, if a physical switch port is placed in the wrong VLAN, the vmnic can still report link up. Link-status-only detection may therefore leave traffic on that uplink even though the intended network is unreachable.
Detection method: Beacon probing
Beacon probing uses probe traffic across teamed uplinks. The vSwitch sends and observes beacon traffic through the physical adapters, comparing what can be seen across the team to infer whether a path has failed beyond the local carrier boundary.
This can expose some failures that do not cause a pNIC to report link down. Examples include certain incorrect VLAN or switch-port configurations and failures farther along the physical path.
Why multiple uplinks are required
Beacon probing depends on comparison and observation between teamed physical uplinks. A single uplink cannot provide a meaningful alternate path for this purpose. Multiple physical uplinks in the team are therefore required for useful beacon-based detection.
The uplinks must also be connected according to a topology that makes the observations meaningful. Enabling beacon probing without understanding how the host, switches, VLANs, and inter-switch paths are connected can produce misleading expectations.
Trade-offs
- Beacon probing adds probe traffic that is similar to broadcast-like Layer 2 traffic.
- It requires multiple suitable physical uplinks in the team.
- It can identify more path conditions than local carrier detection, but it is not a replacement for correct VLAN and switch configuration.
- Its usefulness depends on the physical topology and the location of the failure.
Compatibility with the load-balancing policy
Beacon probing must not be combined with the IP Hash load-balancing policy.
IP Hash is associated with a physical-switch EtherChannel or static link aggregation design. Beacon probing is not supported for that arrangement. If IP Hash is required, use a compatible failure-detection option. Alternatively, redesign the teaming and physical-switch configuration before selecting beacon probing.
Comparison of network failure detection methods
| Method | Detection signal | Default status | Detects local cable or direct-switch failure | Can detect wrong VLAN or switch-port configuration | Can help detect upstream-path failure with local link still up | IP Hash compatibility | Primary limitations |
|---|---|---|---|---|---|---|---|
| Link status only | pNIC carrier or local link state | Default | Yes, when the local link goes down | No, not reliably | No | Compatible as a detection choice, subject to the overall IP Hash and physical aggregation design | Cannot validate reachability beyond the directly connected link |
| Beacon probing | Probe traffic exchanged and observed across teamed uplinks | Not the default | Yes, and it may provide additional path information | It may expose certain configuration problems | It may help when multiple teamed paths reveal the failure | Not compatible | Requires multiple uplinks, adds probe traffic, and depends on suitable physical topology |
Configuration workflow in the vSphere client
- Open the target ESXi host in the vSphere client.
- Go to the host's networking management view.
- Select the standard virtual switch to modify.
- Open the switch's edit-settings or equivalent settings workflow.
- Open Teaming and failover.
- Review the existing uplink team, including the number of physical uplinks and their active or standby roles.
- Review the load-balancing policy. Do not select Beacon probing if the policy is IP Hash.
- Under Network failure detection, select Link status only or Beacon probing.
- Save or apply the change.
- Validate host and virtual-machine connectivity, and test failover during an approved maintenance window.
Configuration checklist
- Confirm the number and role of physical uplinks in the team.
- Review which adapters are active and which are standby.
- Confirm that physical-switch VLAN settings match the intended ESXi port group and network design.
- Verify the selected vSwitch load-balancing policy.
- If IP Hash is configured, check whether the physical switch uses the required EtherChannel or static aggregation arrangement.
- Confirm that the physical topology supports the chosen detection method.
Choosing an appropriate method
| Network design or requirement | Recommended detection method | Conditions to verify | Reason |
|---|---|---|---|
| Direct physical-link failures are the primary concern and the design is straightforward | Link status only | Check cables, pNICs, switch-facing ports, VLANs, and failover order | It is simple, is the default, and promptly detects loss of local carrier |
| Protection is needed against some failures that preserve local carrier | Beacon probing | Use multiple teamed uplinks, validate the topology, and confirm the policy is not IP Hash | Probe observations can reveal path conditions that local link state misses |
| IP Hash with EtherChannel or static aggregation is required | Use a compatible detection option, or redesign the teaming architecture | Verify the physical aggregation and vSwitch policy | Beacon probing is not supported with IP Hash |
| VLAN and switch configuration are uncertain | Do not rely on detection selection alone | Validate port mode, allowed VLANs, tagging, trunks, and port groups first | Detection cannot substitute for correct network design |
Choose Link status only when local physical-link detection is sufficient. Consider Beacon probing when the design requires additional protection against failures that leave NIC carrier up. In either case, validate VLANs, switch configuration, uplink topology, and load-balancing mode before changing the setting.
Failure scenarios and operational behavior
| Failure scenario | Local NIC link remains up? | Link status only result | Beacon probing result | Operational notes |
|---|---|---|---|---|
| Host-facing cable is unplugged | No | Expected to recognize the failed uplink | Expected to recognize the failed path as well | Traffic can move to another eligible active or standby uplink according to failover order |
| Directly attached physical switch loses power | Usually no | Expected to recognize the local link-down condition | Expected to recognize the failure as well | The result depends on the host-facing link reporting down; surviving team members can carry traffic |
| Physical switch port is assigned to the wrong VLAN | Usually yes | Usually does not recognize the network failure | May expose the problem when teamed paths provide useful comparison | Correct the VLAN and port configuration; detection is not a substitute for that correction |
| Failure occurs beyond the directly connected switch | Often yes | Usually does not recognize the failure | May help detect the failed path if multiple teamed uplinks can observe the condition | Trace the physical path and verify whether the failure is within the method's coverage |
| vSwitch uses IP Hash | Depends on the physical failure | Use a compatible detection design | Invalid pairing | Beacon probing must not be enabled with IP Hash; review EtherChannel or static aggregation requirements |
Example: two active uplinks and one standby uplink
Assume a standard vSwitch has vmnic0 and vmnic1 as active uplinks and vmnic2 as standby. When the configured detection method identifies one active uplink as failed, that adapter is no longer eligible for traffic. The other active adapter continues carrying traffic. If both active adapters become unavailable, ESXi can use vmnic2 according to the configured failover order.
The exact result depends on the failure, detection method, physical-switch behavior, and whether the surviving uplinks have correct VLAN and connectivity settings.
Troubleshooting
Virtual machines lose network access but the uplink reports link up
- Check the physical switch port's VLAN, trunk, and allowed-VLAN settings.
- Compare the switch configuration with the ESXi port group's VLAN design.
- Trace the physical path beyond the directly attached switch.
- Identify whether the failure is an upstream Layer 2, Layer 3, or service-layer problem.
- Assess whether Beacon probing is appropriate for the uplink topology and teaming policy.
Beacon probing cannot be selected or should not be enabled
Common causes include an IP Hash load-balancing policy or a physical network that relies on EtherChannel or static aggregation. Retain a compatible detection option, or redesign the teaming architecture after evaluating the physical-switch requirements.
An expected failover does not occur
- Determine whether the outage actually caused local carrier to drop. Link status only cannot detect many failures beyond the local link.
- Review the selected failure-detection method.
- Check whether a suitable surviving active or standby adapter is available.
- Inspect cabling, pNIC state, physical-switch ports, VLANs, and the failover order.
- Confirm that the failure is within the detection scope of the selected method.
Beacon probing provides no useful protection
- Verify that multiple physical adapters are teamed.
- Confirm that the physical topology allows meaningful comparison between paths.
- Validate switch ports, VLANs, trunks, and inter-switch connectivity.
- Determine whether the fault is actually at the host, switching, routing, or service layer.
Practical validation plan
- Record the vSwitch name, uplink team, active and standby roles, load-balancing policy, and current detection setting.
- Confirm that every physical uplink reaches the intended switch port and VLAN configuration.
- Test one failure at a time during a controlled maintenance window.
- For a local-link test, disconnect a host-facing cable or disable the directly connected switch port using the approved operational procedure.
- Observe the pNIC link state, vSwitch uplink eligibility, and virtual-machine connectivity.
- Restore the path and confirm that the expected uplink roles return.
- For beacon probing, test only a topology and policy that support it, and monitor the effect of the additional probe traffic.
Summary
- Network failover detection decides whether a standard vSwitch uplink path remains usable.
- Link status only reads the pNIC's local carrier state and is the default method.
- Link status only detects local cable and directly attached switch failures, but not every upstream or VLAN problem.
- Beacon probing uses traffic observed across multiple teamed uplinks and can provide additional path-failure coverage.
- Beacon probing must not be combined with IP Hash.
- Detection settings belong in the standard vSwitch's Teaming and failover section.
- Correct VLANs, switch configuration, physical topology, uplink roles, and load-balancing policy are prerequisites for dependable failover.
For related study, review network failover detection alongside vSwitch load-balancing policies, IP Hash and EtherChannel, VLAN troubleshooting, and ESXi network troubleshooting.