Skip site navigation (1)Skip section navigation (2)
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=3D246660

--- 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 =
=3D 1.=20
Looking a the two sources i can see the Freebsd side of things seams to mis=
s a
beat, by slowing down somehow . I am not exactly sure how or why this is
happening.=20=20=20

  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 .=20
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.=20

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

--=20
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>