Distributed trunking

[Domenico Viggiani]

The doc:
http://cdn.procurve.com/training/Manuals/3500-5400-6200-6600-8200-MCG-June2009-59923059-12-PortTrunk.pdf
shows configuration of distributed trunking on Procurve switches but it says nothing about configuration on the server side.
What protocol do I need to use if I connect:
- a Linux server with NICs "bonding"
- a Windows server with Intel or Broadcom cards
- an ESX host as described here:
http://www.vnephos.com/index.php/2009/09/hp-procurve-cross-stack-etherchannel/
- an EMC Celerra NAS
Always 802.3ad (LACP)? What Linux bonding mode is it?

[Antonio Milanese]

Hi Domenico,

there is a newer/better document:

http://cdn.procurve.com/training/Manuals/3500-5400-6200-6600-8200-MCG-Mar10-12-PortTrunk.pdf

on the endings servers you MUST use dynamic LACP (yes 802.3ad) that means bonding mode 4 on linux world and "802.3ad Dynamic with Fault Tolerance" for HP teaming.

Static LACP is required between switches as per documentation.

Best regards,

antonio

[Domenico Viggiani]

Dynamic LACP is not supported on VMware but here:
http://www.vnephos.com/index.php/2009/09/hp-procurve-cross-stack-etherchannel/
says that vSphere works with Procurve Distributed Trunking. Any reference other than this blog?

[Antonio Milanese · Accepted solution]

Hello Domenico,

i've read your posted link and agree with the comments.
ESX doesn't support LACP in "native" (d)vSwitches(you need Nexus 1000v), however in ESX you can still combine multiple pNICs as teaming groups..if you use and active/active group using "ip hash" as policy you can effectively form a "raw etherchannel" where all pNICs are in forwarding state since ESX is inspecting ip flow and "pinning" MAC address to distribute traffic on all pNICs:

ESX vSW can't neither exchange nor understant LACP pdus and if you want to form an active/active teaming you MUST force the physical switch to "channel" its interfaces:
on procurve jargon you have to create a static trunk (stricly speaking static LACP doesn't exist =)

So yes using dt-lacp and a ESX teaming with "ip hash" and link fail detection can work (no beaconing!!)...
but IMHO is violating my KISS mantra plus it's not worthing the effort especially when your bandwidth hungry apps are storage oriented and you have native MPIO solutions.
Hope this clarifies last post of mine.

Regards,

Antonio

[Domenico Viggiani]

Antonio,
I understand what you say, thanks.
I'm evaualating pro's and con's of all methods to "attach" storage to VMware (and not only to it...):
If possible, I use FC that works at its best without many efforts of configuration.
As an alternative to FC, I'm looking at iSCSI (with MPIO as failover/load-sharing option) and NFS (with network level solutions for failover/load-sharing).
I'm trying to avoid any prejudiced position and reading blogs of guru like:
http://virtualgeek.typepad.com/