Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

My ESX hosts each have 8 NICS.

I have set up 2 NICs for our iSCSI SAN - each is connected to a different SAN switch. 2 NICs are set up for vMotion and Service Console - these are each connected to a different core switch (ports are trunked with VLANs dedicated to vMotion and Management)

I now have four ports left over. Currently we have these set up each going into our default VLAN. Two NICs are connected to one core-switch and two are connected to the other. We decided to aggregate the connections to each switch - so they are teamed at the vswitch end, and port channelled at the physical switch end.

I am now reading that port channelling these connections is not particularly useful, perhaps even over complicating things.

Is there a particular problem with using port channels for VMware? What method provides the best balance between redundancy and performance?

share|improve this question
add comment

2 Answers 2

up vote 2 down vote accepted

Duncan Epping knows his VMware networking quite well and the scenario he describes is particularly nasty but it's little bit unusual (four nics aggregated into two separate Etherchannel groups). His analysis is right though - VMware doesn't support link aggregation in the way that set up required.

Port aggregation does not improve single session bandwidth, it makes it easier to get better overall utilization of available links. Your four links wont ever be used to provide a single session from a server with 4Gbps of potential bandwidth for example, individual sessions are still traverse a single nic on the VMware Host (or any other system for that matter) and traverse your switches over single point to point connections. However if you choose a load balancing algorithm then separate sessions will be distributed across the available links providing you with better overall performance. With VMware you can choose various teaming policies (failover only, route by source port hash and route by source\destination IP hash) and unless its changed recently it only supports static trunking not active LACP. Load balancing will only work on correctly configured switches so if you want to use it then you will have to do some sort of port trunking\Etherchannel configuration on your switches. This VMware KB article explains some of the background and gives a Cisco and HP configuration example.

The drawback is that if you want to distribute your nics across separate switches and use IP hashing to load balance then they must be stacked in some fashion, otherwise you will end up with a problem similar to the one Duncan described. This has some obvious risks in terms of the potential for issues with that stack impacting all NICs at the same time. The fact that VMware still do not support LACP fully for vSwitches makes this a lot harder than it should be.

share|improve this answer
add comment

The post you linked to is underlining a bad configuration example. The first comment in there is what we did in our environment - 4 NICs in an etherchannel across two stacked Cisco switches. There is nothing wrong with this configuration and it's been working great for over a year now - just be aware that you don't get a 4Gb/s link but rather 4 1Gb/s links.

Edit: I also want to point out that if you want to portchannel across two switches for redundancy, they must be stacked in some fashion - independent switches will not work. If you have two independent switches, then portchannel is not the way to go.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.