- Community Home
- >
- Servers and Operating Systems
- >
- HPE BladeSystem
- >
- BladeSystem - General
- >
- vSwitch load balancing policy in Virtual Connect A...
Categories
Company
Local Language
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Forums
Discussions
Discussions
Discussions
Forums
Discussions
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Community
Resources
Forums
Blogs
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
03-27-2014 11:16 AM
03-27-2014 11:16 AM
vSwitch load balancing policy in Virtual Connect Active-Active configuration
Gautham had a question on load balancing:
***************
Hi guys,
Sanity check:
Just to confirm, when we are using an active-active Virtual Connect configuration with ESXi 5.5 hosts, the vSwitch load balancing policy should NOT be Route based on IP hash.
The individual VMnics will be going to different VC modules & not be in the same LACP group(which will lead to MAC flapping in the uplink switches).
*************
Input from Robert:
*************
You are correct. It should be route based on originating port ID.
*************
More from Dave:
***********
Elaborating a bit more…
VMware provides a number of different NIC teaming algorithms, which are outlined in Table 2-3. As the table shows, any of the available algorithms can be used, except IP Hash. IP Hash requires switch assisted load balancing (802.3ad), which Virtual Connect does not support 802.3ad with server downlink ports. HP and VMware recommend using Originating Virtual Port ID with Standard vSwitch, and Physical NIC Load when using vDS and NetIOC, as shown in Table 2-3.
Table 2-3 VMware Load Balancing Algorithms |
||
Name |
Algorithm |
Works with VC |
Originating Virtual Port ID |
Choose an uplink based on the virtual port where the traffic entered the virtual switch. |
Yes |
Source MAC Address |
MAC Address seen on vnic port |
Yes |
IP Hash |
Hash of Source and Destination IP’s. Requires switch assisted load balancing, 802.3ad. Virtual Connect does not support 802.3ad on server downlink ports, as 802.3ad is a Point-to-Point bonding protocol. |
No |
Physical NIC Load |
Introduced in vSphere 4.1 and only available with a vDS, Load-Based Teaming policy monitors the flow when the mean send or receive utilization on a dvUplink exceeds 75% capacity over 30-sec intervals. |
Yes |
Explicit Failover |
Highest order uplink from the list of Active pNICs. |
Yes |
Regards
***********
Any other comments or questions?