October 6, 2010 1 Comment
In some cases you need to troubleshoot your network infrastructure from your vSphere hosts all the way back into your core network. In this case you can enable beacon probing and watch your log files for issues. But before I continue to show how to enable beacon probing I want to share some information about what beacon probing is and when is it recommended to be used :
Beacon Probing is a network failover detection mechanism that sends out and listens for beacon probes on all NICs in the team and uses this information, in addition to link status, to determine link failure.
This detects failures, such as cable pulls and physical switch power failures, but not configuration errors, such as a physical switch port being blocked by spanning tree or misconfigured to the wrong VLAN or cable pulls on the other side of a physical switch that are not detected by link status alone.
Beacon probing is most useful to detect failures in the closest switch to the ESX hosts, where the failure does not cause a link-down event for the host.
You can use beaconing with 2 NICs, but this only detects failures on the immediate uplink. If you really want to detect upstream failures, use beaconing with 3 or more NICs.
When there are only two NICs in service and one of them loses connectivity it is unclear which NIC needs to be taken out of service as both no longer receive beacons. Using at least 3 NICs in such a team allows for N – 2 failures where N is the number of NICs in the team before getting into an ambiguous situation.
More information about beacon probing can be found here: http://blogs.vmware.com/networking/ and in part 4 of the great vSwitch debate: http://kensvirtualreality.wordpress.com/2009/04/10/the-great-vswitch-debate-part-4/