There is no requirement for the LACP hashing configuration to be the same on both sides. On the whole, it doesn't make any difference if there's a mismatch.
The important thing that a lot of people miss is that LACP distribution policies are controlled by the sending device. There is no negotiation. For example, you can have ONTAP using IP hashing, while the switch is using src-dst-MAC hashing. That might be a bad idea, such as with a routed environment where only 2 MAC addresses are talking, but it doesn't create a compatibility problem.
I've seen a few older switches that really don't like port hashing. I'm not sure exactly what's happening, but it seemed like the architecture of the switch wasn't expecting the same IP/MAC to appear on different multiple ports. It would pass traffic, but the CPU utilization jumped up significantly when any kind of port hashing was being used. Changing to IP solved the problem.
From: toasters-bounces@teaparty.net [mailto:toasters-bounces@teaparty.net] On Behalf Of Vervloesem Wouter Sent: Friday, February 03, 2017 9:15 AM To: NGC-pdg-uow.edu.au pdg@uow.edu.au Cc: toasters@teaparty.net Subject: Re: super secret flags
We don't think the issue was caused by LACP. The difference between a configuration that replicates 'fast' or 'slow' was the distr-func set to IP (fast) or port (slow). In both situations we did use "multimode_lacp" as mode.
Regards,
Wouter Vervloesemhttps://be.linkedin.com/pub/wouter-vervloesem/5/a63/a41 Storage Consultant
Neoria NVhttp://www.neoria.be/ Prins Boudewijnlaan 41 - 2650 Edegem T +32 3 451 23 82 | M +32 496 52 93 61
Op 2 feb. 2017, om 23:06 heeft Peter D. Gray <pdg@uow.edu.aumailto:pdg@uow.edu.au> het volgende geschreven:
On Thu, Feb 02, 2017 at 03:41:19PM +0100, Filip Sneppe wrote:
Hi Jeffrey and others,
I have come across this on a couple of times (First time I encountered this I logged a case for it: 2005111796). Unforunately I have never had the time to troubleshoot this. In case 2005111796, support observed packet loss in the setup with port-based hashing, but we had to destroy our (test/troubleshooting) setup before we could get to the bottom of this. Since then, I have come across this on several occasions. More often than not it was not a real issue since those SnapMirrors ran across WAN links, or SnapMirror runs at night and can take all the time it wants, but on 1Gbps/10Gbps LANs where SM updates need to be fast, it is an issue. However, I found out there is a TR that mentions that SnapMirror performance could be impacted by port-based ifgrps so I've never bothered to open any additional cases for this.
Can anyone else confirm this behavior ?
Is this an LACP ifgrp? We have had no issues with LACP on cluster mode. On 7-mode, we saw many missed LACP packets, but like you never investigated fully because it kept working. One thing our network guys drum into us is that the LACP setting MUST agree at both ends.
Regards, pdg
_______________________________________________ Toasters mailing list Toasters@teaparty.netmailto:Toasters@teaparty.net http://www.teaparty.net/mailman/listinfo/toasters