2

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"

omni
  • 313
  • 2
  • 4
  • 16
  • What types of devices are you trying to connect? – ewwhite Feb 01 '13 at 08:33
  • NetApp FAS2040 <--> Cisco Catalyst 2960scg <--> HP ProCurve 6120 g/xg <--> HP Blade-Enclosure <--> VMWare vSphere 5.1. But how does this have any relevance to the LACP standard? – omni Feb 01 '13 at 08:48
  • It's relevant because you indicated specific devices in your question. More information is always better here. – ewwhite Feb 01 '13 at 09:02
  • AFAIK you cannot aggregate Links between/across multiple devices (in your case you cannot make a LACP trunk from NetApp to HP Blade, you need to create several LACP trunks). Maybe i misunderstood the question btw LACP can aggregate ports (link) between 2 devices creating a "trunk" giving redundancy in case of port failure and speed (link aggregation). – eldblz Feb 01 '13 at 09:08
  • yes, i'm aware of that. the question on checkmark 2 was more like "if i have multiple trunks across devices, does it hurt the flow if each of them uses a different routing strategie?". BTW please lets be clear about the terms here: when hp talks about using multiple physical connections for redundancy and speed they call it link aggregaion. when hp talks about using multiple vlans on one physical connection, they're using the term "trunk". cisco uses the term "etherchannel" and means various link aggregation protocols, including cisco only protocols. dont even know if cisco usesthe term trunk – omni Feb 01 '13 at 09:15
  • Will you be [using LACP on the ESXi side](http://serverfault.com/questions/470875/vmware-distributed-vswitches-vds-design-theory-real-use-cases-and-exampl)? – ewwhite Feb 02 '13 at 13:22

2 Answers2

2

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.

Jason Seemann
  • 1,120
  • 6
  • 9
2

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

SpacemanSpiff
  • 8,733
  • 1
  • 23
  • 35