What failure will beacon probing identify in vSphere networking?
A.
An improper VLAN configuration on a physical switch port
B.
A disconnected network cable
C.
A VMkernel IP mismatch affecting vMotion or HA traffic
D.
Jumbo frames improperly configured on an iSCSI target
Should be B. See http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1005577
B is correct
Beacon probing detects failures, such as cable pulls and physical switch power failures on the immediate physical switch and also on the downstream switches
A is correct isn’t it? Any vswitch will detect a cable pull on an uplink. The benefit of beacon probing is that it checks the downstream switches, this will highlight not only a cable pull, but an improper vlan configuration as well.
I think both are correct, it’s a terrible question as the probe would fail either way
Agree, both are correct. If choose two than A. B. but if presented with only one correct answer than I would go with A. Beacon Probing does more than simply alert link down state,.
Link Status only
Relies solely on the link status that the network adapter provides. This option 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 mis-configured to the wrong VLAN or cable pulls on the other side of a physical switch.
Beacon Probing
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 option detects many of the failures mentioned above that are not detected by link status alone.
Note: Do not use beacon probing with IP-hash load balancing.
B is correct answer.
Correct answer is A – detects link status and configuration errors
This question may be testing the difference between “Link Status Only” vs “Beacon Probing”
Answer B is “Link Status Only” detection
Link Status only. Relies solely on the link status that the network adapter provides. This option 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 that is misconfigured to the wrong VLAN or cable pulls on the other side of a physical switch.
Beacon Probing. 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 many of the failures previously mentioned that are not detected by link status alone.
http://pubs.vmware.com/vsphere-4-esxi-installable-vcenter/index.jsp?topic=/com.vmware.vsphere.esxi_server_config.doc_41/esx_server_config/advanced_networking/t_edit_the_failover_and_load_balancing_policy_on_a_vswitch.html
VMware ESX Beacon Probing Explained
AID: 8353
StatusPublished
3,270 points
dbarber012577
TypeTips/Tricks
Posted on2011-10-19 at 14:49:08
Was this article helpful?
I think it’s A too – ie not just link status
20
Beacon probing is a configurable network failure detection mechanism used by ESX to identify downstream network failures. The purpose of this article is to explain some of the mystery and clarify a commonly misunderstood subject. The information in this article was gathered through direct observation and discussions with VMware.
As opposed to “Link Status Only,” beacon probing can identify a downstream failure. In the event that a failure does not cause a link-down event or if the link-down state is not forwarded to the ESX host, beacon probing can identify and compensate for network failure. Beacon probing works in conjunction with link status, and link-state-down will still trigger a failover if beacon probing is enabled.
Beacon probing identifies failures by sending out and listening for broadcast packets of a specific type. ESX 4.1 uses ethertype 0x8922, ESX 4.0 uses an 802.3 frame which is displayed in Wireshark as an LLC frame with “BCN (0xFF)” in the control field. ESX 3.5 uses an ethertype of 0x05ff. The probes contain the virtual MAC associated with the physical NIC and the name of the interface.
When virtual switch tagging is used, beacon probing sends one packet per host, per second, per in-use VLAN. Meaning the probes are sent down VLANs on which there are virtual machines (this includes the ESX service console). In the case of two interfaces, each interface will send one probe every other second. A failure is identified if 3 consecutive packets are not received on an uplink. Therefore a total of 6 seconds will pass before an uplink is identified as down. As a side note, the maximum number of probes and VLANs to probe can be configured via vCenter under Software¿advanced settings¿net on the host configuration tab.
The number of packets can be alarming, especially in a large domain with many ESX hosts and multiple VLANs per host. For example, a single host with 2 physical interfaces and 3 VLANs will send 3 packets per second, 180 per minute, and 10,800 per hour. This can quickly add up in a farm domain with several hundred hosts.
VMware recommends using beacon probing for configurations with three or more network interfaces. Three or more interfaces allow ESX to identify the leg that is down. When using only 2 interfaces, beacon probing cannot pinpoint the outage. When a failure occurs in this scenario, ESX will enter “shotgun” mode and send all traffic down both legs.
I hope that this will help dispense with some of the conjecture and mystery surrounding beacon probing. I have not had the opportunity to its behavior with VGT configured, but I expect similar results.