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 Vervloesem
Storage Consultant

Neoria NV
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.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.net
http://www.teaparty.net/mailman/listinfo/toasters