Date: Sun, 23 Aug 2020 15:43:11 +0000 From: bugzilla-noreply@freebsd.org To: net@FreeBSD.org Subject: [Bug 246660] Sporadic LACP Lagg Flap Message-ID: <bug-246660-7501-Swf2QsGuZy@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-246660-7501@https.bugs.freebsd.org/bugzilla/> References: <bug-246660-7501@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=246660 --- Comment #2 from nonesuch@longcount.org --- Alex I have a span port setup on each switch going into a tap / agg switch that feeds a corvil packet capture box. From the corvil I can pull the traffic by mac and look at what was going on using wireshark going back about 3 weeks. Second thing I did was capture the details from net.link.lagg.lacp.debug = 1. Looking a the two sources i can see the Freebsd side of things seams to miss a beat, by slowing down somehow . I am not exactly sure how or why this is happening. So far I have two ideas why this is going on. In 11 something the sysctl net.link.lagg.default_use_flowid was changed from a default of 1 to 0 . I suspect this can be causing the issue. Setting use flowid to 1 appears to keep all of the arp, lacp and non ip protocols on queue 0 . This prioritizes the traffic enough to make the kernel lcap bits respond fast enough. Here is the post about the lacp change. Maybe we can ping someone from Multiplay . https://www.mail-archive.com/svn-src-all@freebsd.org/msg155156.html -- You are receiving this mail because: You are the assignee for the bug.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-246660-7501-Swf2QsGuZy>