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

vDS Health Check reports unsupported VLANs for MTU and VLAN (2140503)

Last Updated: 2/27/2024Categories: InformationalTotal Views: 84296Language:
Chinese (Simplified)JapaneseEnglish

28 like this article

Subscribe to get an email
newsletter with new updates

28 people found this helpful Please provide article feedback:

Symptoms

When Network Health Check is enabled on a vSphere Distributed Switch (vDS), you experience these symptoms:

Alarms are generated for errors with VLAN and MTU configuration.

The monitor page for the vDS Health Check reports that some VLANs are Supported and some are Not Supported for the Physical Network Adapter under either VLAN and MTU.

VLAN 0 shows as Not Supported.

Alarm can also occur if IP Hash is the load balancing policy on the vDS

Cause

This issue occurs when a vDS is connected to multiple uplinks with different VLANs permitted, and the teaming/failover order is set on individual port groups to control which uplinks are used for that port group.
While this results in a working network configuration, Health Check does not distinguish between uplinks, and so reports any VLAN configured on the vDS as not supported for an uplink if it is not enabled on that particular network adapter. This affects the MTU, VLAN and Teaming & Failover test results.

The same alarm can also occur if a port group is configured with the VLAN type set to None. In this case, VLAN 0 shows as not supported.

This can also occur because of the combination of the Health Check protocol design and Route Based on IP hash of Load Balancing algorithm. If Load balancing policy for the vDS switch port is configured as Route based on IP hash and EtherChannel is configured in the opposed physical switch, the physical switch may send the unicast frame to another uplink of host which the broadcast was not sent because of load balancing algorithm.

Impact / Risks

There is no data path impact. However, the Health Check does not fully monitor the status of the vDS when one or more of the above configuration is used.

Resolution

This is an expected behavior with the Health Check feature in vSphere.

To prevent the vSphere Distributed Switch Health Check from showing these reports, apply one of these options:

Disable health check on the vDS. For more information, see Enabling vSphere Distributed Switch health check in the vSphere Web Client (2032878).

Use multiple vSphere Distributed Switches, so that every uplink connected to a particular vDS supports the VLANs of all port groups configured on it.

Allow every VLAN used by a port group on the vDS on every uplink, even if the Teaming/Failover order would prevent the port group from using that uplink.

To resolve the issue where a port group with no VLAN assigned is in use, apply one of these options:

Assign the port group to a VLAN that is configured on the physical network for communication between all ESXi hosts connected to the vDS.

Move the port group to a Virtual Standard Switch (VSS) instead of a vDS, which is not affected by the Health Check.

Related Information

Limitations of Network Health Check

The distributed switch network health check for vSphere does not diagnose the end-to-end full path problem. Using the echo type L2 protocol, the health check only checks the health status of ports to which the distributed switch connects. So, the check reports good health status only if two or more good setting peers (uplinks) appear in the same L2 networking.

The physical switch VLAN does not recognize the virtual networking in ESXi. If the physical switch is misconfigured, ESXi does not report warnings, resulting in networking failures until you enable the health check feature and the new round check completes.

The distributed switch network MTU health check is designed to probe the runtime true Jumbo Frame capability of ports to which the distributed switch connects. However, the maximum VLAN MTU size determines the physical switch trunk port MTU size setting in all trunk VLANs for the port. The MTU health check feature "Supported/Not supported" status result displays whether or not the access port supports the distributed switch MTU setting. The "VLAN Trunk" status result field displays all the distributed port groups VLAN setting range in that physical switch trunk port.

The distributed switch network health check, including the VLAN, MTU, and teaming policy check may not function properly when there are hardware virtual NICs on the server platform.

In vSphere, the teaming health check does not work for LAG ports as the LACP protocol itself is capable of ensuring the health of the individual LAG ports. However, VLAN and MTU health check can still check LAG ports.

Ensure that all portgroups in the virtual distributed switch with different VLANs have the same MTU in the physical switch because ESXi will not detect the MTU mismatch of full paths and Jumbo Frame packets might forwarded to other physical switch ports which are out of the virtual distributed switch. At those ports, there is a risk that the Jumbo Frame packets might be dropped if that port and VLAN do not enable Jumbo Frames.

Note: Depending on the options that you select, the vSphere Distributed Switch Health Check can generate a significant number of MAC addresses for testing teaming policy, MTU size, VLAN configuration, resulting in extra network traffic  The distributed switch network health check generates one MAC address for each uplink on a distributed switch for each VLAN multiplied by the number of hosts in the distributed switch to be added to the upstream physical switch MAC table. For example, for a vDS having 2 uplinks, with 35 VLANs across 60 hosts, the calculation is 2 * 35 * 60 = 4200 MAC table entries on the upstream physical switch.  Ensure the number of MAC addresses to be generated by the health check will be less than the size of the physical switch(es) MAC table maximums. Otherwise, there is a risk that the switches runs out of memory, with subsequent network connectivity failures.

After you disable the vSphere Distributed Switch Health Check, the generated MAC addresses age out of your physical network environment according to your network policy.

Detectable by VMware SkylineTM

Actions

Copy

link to clipboard
copied!

Print

Language:
Chinese (Simplified)JapaneseEnglish

Attachments

Additional Resources

No results for undefined

Ask The Community

Get answers quickly from VMware experts in the community

Post Subject

CONTINUE IN COMMUNITIES

Related Products:

VMware vSphere ESXi

VMware vCenter Server

Related Versions:

Take Our Survey

Support Assistant