Loading

×Sorry to interrupt
Uncaught ReferenceError: addCTracking is not defined
throws at https://kb.vmware.com/resource/KM_TealiumTrackingJS?v=0.5:100:1

Refresh

Cookie Preference Center

General Information on cookies

When you visit our website, we use cookies to ensure that we give you the best experience. This information does not usually directly identify you, but it can give you a more personalized web experience. Because we respect your right to privacy, you can choose not to allow some types of cookies by clicking on the different category headings to find out more and change your settings. However, blocking some types of cookies may impact your experience on the site and the services we are able to offer. Further information can be found in our

Cookie Policy.

Strictly Necessary

Strictly Necessary

Always Active

Strictly Necessary

Strictly necessary cookies are always enabled since they are essential for our website to function. They enable core functionality such as security, network management, and website accessibility. You can set your browser to block or alert you about these cookies, but this may affect how the website functions. For more information please visit www.aboutcookies.org or www.allaboutcookies.org.

Cookie Details‎

Performance

Performance

Performance

Performance cookies are used to analyze the user experience to improve our website by collecting and reporting information on how you use it. They allow us to know which pages are the most and least popular, see how visitors move around the site, optimize our website and make it easier to navigate.

Cookie Details‎

Please confirm your settings by refreshing the page.

Functional

Functional

Functional

Functional cookies help us keep track of your past browsing choices so we can improve usability and customize your experience. These cookies enable the website to remember your preferred settings, language preferences, location and other customizable elements such as font or text size. If you do not allow these cookies, then some or all of these services may not function properly.

Cookie Details‎

Advertising

Advertising

Advertising

Advertising cookies are used to send you relevant advertising and promotional information. They may be set through our site by third parties to build a profile of your interests and show you relevant advertisements on other sites. These cookies do not directly store personal information, but their function is based on uniquely identifying your browser and internet device.

Cookie Details‎

Advertising Cookies

Consent Leg.Interest

Select All Vendors

Select All Vendors

Select All Hosts

Select All

Clear Filters

Information storage and access

Apply

Confirm My Choices Reject All Allow All

My Subscriptions

Loading

Knowledge Base

Hosts May Disconnect from vCenter when using a X710 or XL710 or X722 family card when LLDP is enabled. (53749)

Last Updated: 2/25/2022Categories: TroubleshootingTotal Views: 12275Language:
English

2 like this article

Subscribe to get an email
newsletter with new updates

2 people found this helpful Please provide article feedback:

Details

Why This Happens:
By design, vmk0 copies the physical MAC address of vmnic0. This is useful for some customers as they can prepare DHCP reservations ahead of the hardware arriving as server vendors will give you the MAC address for the onboard adapters once it is assembled. This family of network adapters has an embedded Link Layer Discovery Protocol (LLDP) engine that will keep issuing ARP requests of that MAC to the first port even if VMK0 moves to another port. This can cause the host to disconnect from vCenter if vmk0 is used for management traffic as the CAM table on the switch above gets confused about where to send packets.

Example:
If vmnic0 has a mac of 00:00:00:00:00:00 and vmnic1 has a mac of 11:11:11:11:11:11. The vmkernel adapter vmk0 will have mac 00:00:00:00:00:00. If LLDP packets are coming from vmnic0 (physical) over layer 2 to 00:00:00:00:00:00 and vmk0 moves to vmnic1, the physical switch CAM tables won’t know how to get the traffic to the correct ethernet port reliably because vSphere's attempt to issue a  reverse ARP will conflict with LLDP's request.

Troubleshooting:
If you have syslog configured for your physical switches you may see Mac Flapping (MACFLAP on Cisco) entries in the switch logs. This may also manifest itself in the switch logs as a high volume of CAM table updates as the 2 ports fight over the MAC Address.

vobd.log will report mac conflicts using the events "VmMacConflictEvent" or "VmStaticMacConflictEvent"

Solution

There is no solution, however using any of the following methods can help to work around the issue.

Create, but don’t use VMK0 for anything.

Put VMK0 on a tagged NON-Native VLAN. This will prevent conflict with the LLDP agent and MAC address if it's on a completely different broadcast domain.

Run LACP across the original physical port and another port.

Disable the NIC's built-in LLDP engine (see below).

Network driver i40en version 1.5.6 introduces additional parameters that allow you to allow or disallow the flow of LLDP frames to the network stack. This is currently supported with Intel X710/XL710/XXV710 adapters using FW 6.0.x and later and Intel X722 adapters using FW 4.0 or later.

Download: https://customerconnect.vmware.com/web/vmware/details?downloadGroup=DT-ESXI65-INTEL-I40EN-156&productId=614

Note: You may also have to change the "LLDP Agent" setting to "Disabled" in the NIC BIOS for each port.  Please contact your hardware vendor for exact instructions to accomplish this. The hardware vendor will also know the correct commands to run to disable or enable LLDP on the physical NICs.

For 2-port NICs:
To Disable LLDP: esxcli system module parameters set -m i40en -p LLDP=0,0
To Enable LLDP: esxcli system module parameters set -m i40en -p LLDP=1,1

For 4-port NICs:
To Disable LLDP: esxcli system module parameters set -m i40en -p LLDP=0,0,0,0
To Enable LLDP: esxcli system module parameters set -m i40en -p LLDP=1,1,1,1

Note: A reboot of the host is required for the changes to take effect.

For more information on resolving MAC address conflicts, see vmk0 management network MAC address is not updated when NIC card is replaced or vmkernel has duplicate MAC address

Related Information

ESXi host that uses Intel Corporation Ethernet Controller X710 for 10GbE SFP+ NIC with the i40e driver fails with PSOD

Detectable by VMware SkylineTM

Actions

Copy

link to clipboard
copied!

Print

Language:
English

Attachments

Additional Resources

KB
•
End Of General Availability of the Free vSphere Hypervisor (ESXi 7.x and 8.x) (2107518)

KB
•
ホストの vSphere クライアントを使用して直接接続するときに、ホストは [すべてのデータを退避] または [データの移行なし] ではなく、[データのアクセシビリティの確保] を使用してメンテナンス モードになる (55937)

KB
•
Download and Install VMware Fusion (2014097)

KB
•
RSA が構成されていると、6.5 から 6.7 への Windows vCenter Server のアップデートが失敗し、VMIdentity の firstboot エラー「VMware Identity Service のブートストラップに失敗しました (VMware Identity Service bootstrap failed)」が発生する (55627)

KB
•
vRealize Operations Manager 6.x 或更高版本中缺少或已停止虚拟机客户机衡量指标 (55697)

Results 1-5 of 5

Ask The Community

Get answers quickly from VMware experts in the community

Post Subject

CONTINUE IN COMMUNITIES

Related Products:

VMware vSphere

Related Versions:

VMware vSphere 6.x

Take Our Survey

Support Assistant