Loading

×Sorry to interrupt
This page has an error. You might just need to refresh it.
[NoErrorObjectAvailable] Uncaught ReferenceError: addCTracking is not defined
Failing descriptor: {markup://c:KM_ArticleThemeLayout}

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

Skip to main content

My Subscriptions

Loading

Knowledge Base

Microsoft NLB not working properly in Unicast Mode (1556)

Last Updated: 2/22/2017Categories: TroubleshootingTotal Views: 285909Language:
Chinese (Simplified)Portuguese (European)JapaneseSpanishEnglish

19 like this article

Subscribe to get an email
newsletter with new updates

19 people found this helpful Please provide article feedback:

Details

When running Microsoft Network Load Balancing (NLB) configured in unicast mode, the Network traffic is directed to only one of the nodes.

Solution

In unicast mode, all the NICs assigned to a Microsoft NLB cluster share a common MAC address. This requires that all the network traffic on the switches be port-flooded to all the NLB nodes. Normally, port flooding is avoided in switched environments when a switch learns the MAC addresses of the hosts sending network traffic through it.

The Microsoft NLB cluster masks the cluster's MAC address for all outgoing traffic to prevent the switch from learning the MAC address.

In the ESXi/ESX host, the VMkernel sends a RARP packet each time certain actions occur; for example, when a virtual machine is powered on, experiences teaming failover, performs certain vMotion operations, and so forth. The RARP packet informs the switch of the MAC address of that virtual machine. In an NLB cluster environment, this exposes the MAC address of the cluster NIC as soon as an NLB node is powered on. This can cause all inbound traffic to pass through a single switch port to a single node of the NLB cluster.

To resolve this issue, you must configure the ESXi/ESX host to not send RARP packets when any of its virtual machines is powered on.

Notes:

VMware recommends configuring the cluster to use NLB multicast mode even though NLB unicast mode should function correctly if you complete these steps. This recommendation is based on the possibility that the settings described in these steps might affect vMotion operations on virtual machines. Also, unicast mode forces the physical switches on the LAN to broadcast all NLB cluster traffic to every machine on the LAN. If you plan to use NLB unicast mode, ensure that:

NLB Unicast members can be on the same ESX host or on different ESX hosts.

The client machine that connects to the NLB cluster must communicate to the cluster via a physical switch.

The reason for this is that NLB Unicast relies on port flooding to reach all cluster members and the virtual switch does not port flood unicast traffic.

To ensure traffic between client and cluster always goes through a physical switch the client and NLB cluster should be on separate broadcast domains.

vMotion for unicast NLB virtual machines is not supported.

The Security Policy Forged Transmit on the Portgroup is set to Accept.

The transmission of RARP packets is prevented on the portgroup / virtual switch as explained in the later part of the article.

VMware recommends having two NICs on the NLB server.

ESXi 6.x, 6.5.X

Please change “Notify Switches” setting to “No” in port groups or vSwitch to prevent RARP packet with vSphere Web Client.

Please check "vSphere Networking" document for detail.

ESXi/ESX 3.x, 4.x, and 5.x
You can prevent the ESXi/ESX host from sending RARP packets upon virtual machine power up, teaming failover, and so forth using the Virtual Infrastructure (VI) Client or vSphere Client. You can control this setting at the virtual switch level or at the port group level.

To prevent RARP packet transmission for a virtual switch:

Note: This setting affects all the port groups using the switch. You can override this setting for individual port groups by configuring RARP packet transmission for a port group.

Log in to the VI Client/vSphere Client and select the ESXi/ESX host.

Click Configuration tab.

Click Networking under Hardware.

Click Properties for the vSwitch. The vSwitch Properties dialog appears.

Click Ports tab.

Click vSwitch and click Edit.

Click NIC Teaming.

Select No from the Notify Switches dropdown.

Click OK and close the vSwitch Properties dialog box.

To prevent RARP packet transmission for a port group:

Note: This setting overrides the setting you make for the virtual switch as a whole.

Log in to the VI Client or vSphere Client and select the ESXi/ESX host.

Click Configuration tab.

Click Networking under Hardware.

Click Properties for the vSwitch. The vSwitch Properties dialog appears.

Click Ports .

Click the portgroup you want to edit and click Edit.

Click NIC Teaming.

Select No from the Notify Switches dropdown.

Click OK to close the vSwitch Properties dialog.

ESX 2.x

Log in to the Management Interface and click Options > Advanced Settings.

Set the value for Net.NotifySwitch to 0.

Note: Net.NotifySwitch is a global setting that impacts all virtual machines.

For more information on NLB, see the Microsoft TechNet article Network Load Balancing Technical Overview.

Note: The preceding link was correct as of January 14, 2014. If you find the link is broken, please provide feedback and a VMware employee will update the link. The information provided in this link is provided as-is and VMware does not guarantee the accuracy or applicability of this information.

For related information, see Microsoft Network Load Balancing Multicast and Unicast operation modes (1006580).

Windows 2008 introduced a strong host model that does not allow different NICs to communicate with each other. For example, if a request comes in on the second NIC and if there is no default gateway set up, then the NIC will not use the first NIC to reply to the requests, even though a default gateway setup on the first NIC.

To change that behavior and return to the 2003 model, run these commands from the command prompt:

netsh interface ipv4 set interface "Local Area Connection" weakhostreceive=enable
netsh interface ipv4 set interface "Local Area Connection" weakhostsend=enable

Where Local Area Connection is the name of the network interface.

For more information, see the Microsoft TechNet Magazine article on Strong and Weak Host Models.

Note: The preceding link was correct as of January 14, 2014. If you find the link is broken, provide feedback and a VMware employee will update the link. The information provided in this link is provided as-is and VMware does not guarantee the accuracy or applicability of this information.

Additional Information
Sample Configuration - Network Load Balancing (NLB) unicast mode configuration (1006778)

To configure NLB in Unicast mode using a Cisco Nexus 1000v, see the Cisco Nexus 1000v Configuration guide - Network Load Balancing for vEthernet.

For translated versions of this article, see:

Español: El Equilibrio de carga de red de Microsoft (NLB, Network Load Balancing) no funciona de forma adecuada en el modo de unidifusión (2016712)

Português: Microsoft NLB não está funcionando corretamente em modo Unicast (2016894)

日本語: Microsoft NLB がユニキャスト モードで適切に機能しない (2078469)

简体中文: Microsoft NLB 在单播模式下不能正常工作 (2040916)

Detectable by VMware SkylineTM

Actions

Copy

link to clipboard
copied!

Print

Language:
Chinese (Simplified)Portuguese (European)JapaneseSpanishEnglish

Attachments

Additional Resources

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

Result 1 of 1

Ask The Community

Get answers quickly from VMware experts in the community

Post Subject

CONTINUE IN COMMUNITIES

Related Products:

VMware vSphere ESXi

VMware ESX Server

Related Versions:

VMware vSphere ESXi 6.5

VMware vSphere ESXi 6.0

VMware vSphere ESXi 5.5

VMware vSphere ESXi 5.1

VMware vSphere ESXi 5.0

VMware ESXi 4.1.x Installable

VMware ESXi 4.1.x Embedded

VMware ESXi 4.0.x Installable

VMware ESXi 4.0.x Embedded

VMware ESXi 3.5.x Installable

VMware ESXi 3.5.x Embedded

VMware ESX Server 3.5.x

VMware ESX Server 3.0.x

VMware ESX Server 2.5.x

VMware ESX Server 2.1.x

VMware ESX Server 2.0.x

VMware ESX 4.1.x

VMware ESX 4.0.x

view all

Take Our Survey

Was this article helpful?

YES

NO

Copyright © 2005-2024 Broadcom. All Rights Reserved. The term “Broadcom” refers to Broadcom Inc. and/or its subsidiaries.

Terms of Use

Your California Privacy Rights

Privacy

Accessibility

Cookie Settings

Support Assistant