So whats the word on Beacon Probing

[chuckk281]

Dan was looking for some advice:

******************

I had seen a lot of threads before on Beacon Probing in VMware causing more problems than it was worth.

Customer of mine is thinking of using it because they had an odd issue where one of their Nexus 7000 switches hung and they rebooted it, but the Link state to the VC modules never actually went down.  So while it was hung and rebooting, VC was sending half the packets into the blackhole that became the Nexus switch.

Thus even with SmartLink, they were screwed.

They were thinking of using Beacon Probing with an Active Active VC design to mitigate the risk.

Can anyone give me a summary on the Beacon probing problems and if there is a known fix to make it work reliably without making the system unstable?

************

Input from Andy:

Beacon probing has not changed since the 4.x days and I would likewise recommend against using it in a BladeSystem + VC environment.  The purpose of Beacon Probing is to provide a means to detect a failure at the network edge beyond a simple up/down scenario.  This effectively provides a method to detect configuration errors, VLAN’s missing, or non-forwarding ports where the link state is still up.  Unfortunately the method used to achieve this is lost at the VC device due to stacking links and internal traffic management by the VC modules.  The alternative is, as recommended, to use Link Status Only on the ESXi host (instructions work for 4.x and 5.x), SmartLink on the VC modules and potentially also Link State Tracking (or non-Cisco equivalent) on the physical switch depending on the network topology

And From Ken:

If you do use beacon probing, there is a recommendation from VMware to use 3 or more uplinks in the team:

http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1005577

*****************

Other comments or suggestions?