i was wondering if the routing mechanism for LACP (source / destination MAC, source+destination MAC, source / destination IP, source+destination IP) has to be the same within
- one LACP trunk* between two devices
- multiple LACP trunks* but one logical path across multiple devices
also: when using auto LACP, does a negotiation happen so the devices automatically use the same routing strategie? what's the worst that could happen if the routing mechanisms don't fit?
*I'm using the term "trunk" here in the means of "grouping multiple physical cables for the goal of redundancy and higher troughput"
No, there is no reason for the hashing algorithms to match on each side. LACP has no knowledge nor concern about the remote hashing strategy. LACP peers don't negotiate hashing because they don't care how their peer is balancing traffic. There is no sanity checking that an inbound frame came in the "right" interface.
You need to think of LACP as a "verification mechanism" of link aggregation.
You will not achieve any better performance whether you use a static LAG or whether you use an LACP LAG. What you will get is faster failover, and some intelligence that is checking to make sure that the links are functional before introducing them into the LAG.
Now... depending on your TRAFFIC.... would directly answer your question on which is better. Each participant in the link can use the different methods (IP src/dest, MAC src/dest) to choose how to EGRESS the traffic. Ideally both ends of the link will do it the same, but they don't have to.
NetApp has a WONDERFUL document on this, covering multiple different scenarios but let me get straight to the chase:
1) You're going to want to have a separate LACP bond to each VIF, one to each NetApp head.
2) You should configure static LAGs on the ESXi side if you're running 5.0 or earlier, and LACP enabled LAGs if you're running 5.1 or later.
Once you hit the limitations of 1GbE on that NetApp, you either need to step to 10GbE cards, or get a more powerful filer.
EDIT: Here's the link to the documentation, there may be a revision out now that 5.1 http://media.netapp.com/documents/tr-3749.pdf