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