Cisco Etherchannel connect to VMWare 4.1

[mr1y]

My question is "Has there been any bad effects observed concerning Cisco Etherchannel on VMware 4.1?"  We are about to change our configuration to trunk etherchannel with VLID's and I would like to find out if there has been side effects noted.  Here is our configuration:

*  Currently our hosts have 3 vswitches, vswitch0 has 2 nics and is for vmotion and service console, vswitch1 has 3 nic's and has our VM's, vswitch2 has 3 nic's for NFS. no etherchannel

*  Our new config will be one vswitch0 with all of our vkernal connections: Service Console, vMotion, NFS, and all our Port Groups for VM's.  All 8 nics will be Etherchannel with VLanID's required.

We have one host configured this way and it has been flawless for 3 weeks.  We verified that all nics work with all networks by unpluging all but one then plugging  another and disconnect the first after a couple minutes for all 8 nics.  Then we swapped cables for nic0 with another cable to verify that there was not a 1-1 link with Service Console.  Durring this whole time continuously pinging the default gateway from the host and ping the service console of the host from another machine.  At most one packet was lost on several nics during transition otherwise the host was able to communicate and be communicated with.

We like this setup since it relieves us from having 1-1 nic - cisco switch port connections. This is a far better nic to switch redundancy ( half our nics go to a second Cisco switch blade for switch redundancy).

My concern is the Service Console although it appears to work fine on our one host is there a 1-1 connection that will try to reassert for a specific nic?

And is this OK for ESXi 4.1.

Any enlightenment would be appreciated.

[kjb007]

Are you stacking your switches?

If not, then unless you are making 1 etherchannel active to 1 switch, and the other passive, depending on portgroup, then you won't really form a channel from the vSwitch perspective, since all pNICs attached to the vSwitch are not in the same etherchannel.

Also, in that scenario, your pNICs will be teamed for redundancy only, and not for load balancing, for the same reason as above.

-KjB

[a_p_]

I'm not sure whether this will work as expected. With an EtherChannel configuration (IP-Hash load balancing) only the outgoing traffic is distributed across the uplinks based on the target IPs. Incoming traffic will most likely use only one of the uplinks, so this could become a bottleneck.

André

[mr1y]

Thank you.

I will check this out with our network guy. I am pretty sure our switches are stacked.

Your comments are appreciated.

Michael Ray

VMware Systems Administrator

Eastern Washington University

[mr1y]

Thank you.

I will check this out .

Your comments are appreciated.

Michael Ray

VMware Systems Administrator

Eastern Washington University

[MauroBonder]

i´d like share this kb too http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=100404...

[kjb007]

That's not exactly correct.  By default, using src-dst-ip, outbound connections will be made using all available uplinks, but to get the reverse to work as well, is where the etherchannel comes in.  That is, provided that the etherchannel is properly configured.  Since there's no dynamic negotiation occurring here, both sides must be manually set to on.  If your switches are not stacked, then traffic can theoretically go out one switch, and attempt to come back another switch, which will not be allowed, causing intermittent communication problems, using that algorithm.  So, in that scenario, the etherchannels are not really buying you anything additional.  To make it work, you would leave the etherchannel in an active/passive confguration on a portgroup basis, to utilize as many uplinks as you can.

Hope that makes sense.

-KjB

[mr1y]

Excellent, I will run this buy our Network Administrator to verify this is all the way it should be .

Thanks again.

Michael