Hi,

If I'm not mistaken, most of the newer IOS-based Catalyst switches (including the Sup IV in the 4507) support auto PAGP and LACP, which means PAGP / LACP will detect directly connected switches / hosts with matching aggregation characteristics and build the EtherChannel automatically.

You can always check the log to see if EtherChannels have been built automatically... entries will exist if either PAGP or LACP have dynamically created the channel.

Regards,
Paul

Ah, my pet favourite...

ESX doesn't support dynamic IEEE 802.3ad Link Aggregation Groups (pagp & lacp port groups).
It does however support static IEEE 802.3as LAGs (Gigabit / Fast EtherChannel).

Some "network" guys will usually tell you to avoid FEC/GEC, but from my experience this is misguided.
The again I am a "server" guy, so perhaps I'm a bit biased...

You need to set up a channel group and observe the load balancing mechanism that is used, e.g. show etherchannel load-balance...

Hopefully, it is src-dst-ip. It doesn't matter if it's not.
This one is just the most flexible - especially if you're using NLB...
Consider changing it if there's little chance of impact...

The trick here is to setup your vSwitch load balancing policy to be compatible.
src-mac, dst-mac, src-dst-mac = MAC hash
src-ip, dst-ip, src-dst-ip = IP hash

Use a pSwitch config like this:

!
interface port-channel1
description VMware ESX - Trunk A
switchport trunk encapsulation dot1q
switchport trunk allowed vlan 100,200
switchport mode trunk
switchport nonegotiate
speed 1000
spanning-tree portfast trunk
!
exit
!
interface GigabitEthernet3/10
description VMware ESX - Trunk A - NIC 0
switchport trunk encapsulation dot1q
switchport trunk allowed vlan 100,200
switchport mode trunk
switchport nonegotiate
speed 1000
spanning-tree portfast trunk
channel-group 1 mode on
!
exit
!
interface GigabitEthernet3/11
description VMware ESX - Trunk A - NIC 1
switchport trunk encapsulation dot1q
switchport trunk allowed vlan 100,200
switchport mode trunk
switchport nonegotiate
speed 1000
spanning-tree portfast trunk
channel-group 1 mode on
!
end

That should do the trick!

Ben

EDIT: Corrected syntax error

Quotient,

Thanks again. I've applied your recommended configuration to our "pSwitch".

At first, I struck out. We lost connectivity to the VMs. Then I attempted to identify the load balancing mechanism on the pSwitch. I'm not sure that I was able to establish the method being used. Here's the port-channel details:

myswitch#show etherchannel 25 detail
Group state = L2
Ports: 2 Maxports = 8
Port-channels: 1 Max Port-channels = 1
Protocol: -
Ports in the group:
-------------------
Port: Gi3/10
------------

Port state = Up Mstr In-Bndl
Channel group = 25 Mode = On/FEC Gcchange = -
Port-channel = Po25 GC = - Pseudo port-channel = Po25
Port index = 0 Load = 0x00 Protocol = -

Age of the port in the current state: 00d:00h:26m:53s

Port: Gi3/11
------------

Port state = Up Mstr In-Bndl
Channel group = 25 Mode = On/FEC Gcchange = -
Port-channel = Po25 GC = - Pseudo port-channel = Po25
Port index = 1 Load = 0x00 Protocol = -

Age of the port in the current state: 00d:00h:26m:53s

Port-channels in the group:
---------------------------

Port-channel: Po25
------------

Age of the Port-channel = 06d:19h:09m:23s
Logical slot/port = 11/25 Number of ports = 2
GC = 0x00000000
Port state = Port-channel Ag-Inuse
Protocol = -

Ports in the Port-channel:

Index Load Port EC state No of bits
------+------+------+------------------+-----------
0 00 Gi3/10 On/FEC 0
1 00 Gi3/11 On/FEC 0

Time since last port bundled: 00d:00h:26m:53s Gi3/11
Time since last port Un-bundled: 01d:02h:24m:17s Gi3/11

Figuring trial and error couldn't hurt, I tried adjusting the Load Balancing options on the vSwitch.

Route Based on Originating Virtual Port ID fails.
Route Based on ip hash works
Route Based on source MAC hash fails.

If I compare and contrast these results with my prior efforts, Route Based on Originating Virtual Port ID appeared to work when I did not explicitly define the GEC/FEC port-channel.

I wish I understood this stuff better. And I agree completely with your assessment, it would be great to have some agreed-upon nomenclature.

So now I have a working Port-Channel, and I am using the "Route Based on IP hash" algorithm. Am I headed in the right direction?

Thanks again for the advice.

-gL

Quotient,

You've got this stuff down cold. Thanks.

We are currently running at:

#show ether load-balance
Source XOR Destination IP address

So, it appears that the IOS option for "Source XOR Destination IP address" load balancing is equivalant the VMware's "IP hash".

I take it that this is default behavior on the Sup IVs?

I just caught up on your earlier solution too, http://www.vmware.com/community/thread.jspa?threadID=49110.

This is starting to make sense.

I just learned another interesting fact from VMware support. ESX supports outbound load balancing by default. EtherChannel is required for inbound load balancing.

Is there any advantage to the different load-balancing algorithms?

-gL [edit: updated with info from Support Request]

Quotient,

Excellent input. You've not only given me the correct answer, but provided more than a few very helpful answers. I can't seem to figure out the points/award system, sorry, but I'd hook you up with the full measure (22 points?) if I could.

Thanks again.

-gL

Looks like its too late now to convert this thread into a question. I tried editing the original post, but the option to flag the thread as a question is not available. Maybe a benevolent moderator can reverse my mistake and award you the points you deserve.

Thanks again!

-gL