Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

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"

share|improve this question
    
What types of devices are you trying to connect? –  ewwhite Feb 1 '13 at 8: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? –  masi Feb 1 '13 at 8:48
    
It's relevant because you indicated specific devices in your question. More information is always better here. –  ewwhite Feb 1 '13 at 9: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 1 '13 at 9: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 –  masi Feb 1 '13 at 9:15

2 Answers 2

up vote 2 down vote accepted

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

share|improve this answer
    
Exactly! That's why I asked about the vSphere license level. –  ewwhite Feb 2 '13 at 15:53
    
Good point, do you need vDS to do LACP? –  SpacemanSpiff Feb 2 '13 at 21:19
    
Yep. So basically Enterprise Plus. We just implemented it. –  ewwhite Feb 2 '13 at 22:04

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.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.