[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <20200928.124823.1821386447234078357.davem@davemloft.net>
Date: Mon, 28 Sep 2020 12:48:23 -0700 (PDT)
From: David Miller <davem@...emloft.net>
To: razor@...ckwall.org
Cc: netdev@...r.kernel.org, idosch@...dia.com, roopa@...dia.com,
bridge@...ts.linux-foundation.org, nikolay@...dia.com
Subject: Re: [PATCH net] net: bridge: fdb: don't flush ext_learn entries
From: Nikolay Aleksandrov <razor@...ckwall.org>
Date: Mon, 28 Sep 2020 18:30:02 +0300
> From: Nikolay Aleksandrov <nikolay@...dia.com>
>
> When a user-space software manages fdb entries externally it should
> set the ext_learn flag which marks the fdb entry as externally managed
> and avoids expiring it (they're treated as static fdbs). Unfortunately
> on events where fdb entries are flushed (STP down, netlink fdb flush
> etc) these fdbs are also deleted automatically by the bridge. That in turn
> causes trouble for the managing user-space software (e.g. in MLAG setups
> we lose remote fdb entries on port flaps).
> These entries are completely externally managed so we should avoid
> automatically deleting them, the only exception are offloaded entries
> (i.e. BR_FDB_ADDED_BY_EXT_LEARN + BR_FDB_OFFLOADED). They are flushed as
> before.
>
> Fixes: eb100e0e24a2 ("net: bridge: allow to add externally learned entries from user-space")
> Signed-off-by: Nikolay Aleksandrov <nikolay@...dia.com>
Applied and queued up for -stable, thank you.
Powered by blists - more mailing lists