Unbalanced LACP link

[Vitalii Duk]

It worked fine, but today I've got one more error:
Mar 29 01:03:08 router kernel: igb1: Interface stopped DISTRIBUTING,
possible flapping
Mar 29 01:08:02 router kernel: igb2: Interface stopped DISTRIBUTING,
possible flapping
Mar 29 01:08:02 router kernel: igb3: Interface stopped DISTRIBUTING,
possible flapping
Mar 29 01:11:01 router kernel: igb1: Interface stopped DISTRIBUTING,
possible flapping
Mar 29 01:11:01 router kernel: igb0: Interface stopped DISTRIBUTING,
possible flapping
Mar 29 01:13:11 router kernel: igb0: Interface stopped DISTRIBUTING,
possible flapping
Mar 29 01:13:16 router kernel: igb1: Interface stopped DISTRIBUTING,
possible flapping
Mar 29 01:13:42 router kernel: igb2: Interface stopped DISTRIBUTING,
possible flapping
Mar 29 01:13:46 router kernel: igb3: Interface stopped DISTRIBUTING,
possible flapping

On 19 March 2015 at 19:51, hiren panchasara <hiren at strugglingcoder.info>
wrote:

> On 03/17/15 at 12:34P, Adrian Chadd wrote:
> > On 17 March 2015 at 11:33, Jason Wolfe <nitroboost at gmail.com> wrote:
> > > On Mon, Mar 16, 2015 at 2:43 AM, Hans Petter Selasky <hps at selasky.org>
> wrote:
> > >> On 03/16/15 10:37, Vitalii Duk wrote:
> > >>>
> > >>> I've changed use_flowid to 0 and it helped! But isn't it setting
> > >>> significant? In a description it says "Shift flowid bits to prevent
> > >>> multiqueue collisions".
> > >>
> > >>
> > >> Hi,
> > >>
> > >> Maybe your ethernet hardware is not properly setting the m_flowid ...
> > >>
> > >> --HPS
> > >>
> > >
> > > Flip use_flowid back to 1 and try setting
> > > net.link.lagg.default_flowid_shift / net.link.lagg.X.flowid_shift to 0
> > > as Hiren suggested.  r260179 added this shift, which has caused us
> > > balancing issues with the i350/igb.
> > >
> > > https://svnweb.freebsd.org/base?view=revision&revision=260179
> > >
> > > Based on Adrian's comment about igb/ixgbe not setting the 'full
> > > flowid' under normal conditions, does that mean this shift should be 0
> > > by default to ensure we don't break balancing for devices that only
> > > set the CPU/MSIX queue?
> >
> > Or we can just see if there's anything wrong with putting the full 32
> > bit RSS flowid in received packets that have them.
>
> It'd be nice to have but for now I am proposing following to fix a known
> broken case because of an optimization:
> https://reviews.freebsd.org/D2098
>
> Cheers,
> Hiren
>