]> git.ipfire.org Git - thirdparty/kernel/stable.git/commit
net: bridge: fdb: don't flush ext_learn entries
authorNikolay Aleksandrov <nikolay@nvidia.com>
Mon, 28 Sep 2020 15:30:02 +0000 (18:30 +0300)
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Wed, 14 Oct 2020 09:55:59 +0000 (11:55 +0200)
commitd1a1891a586561b3085bf92d6dfbc0698000cb01
tree40c2f4f78b5f59ffc7957351cc4b44546a3f5c33
parent54d2034e1d130d90b729ddd75d58bd1ebf8bff81
net: bridge: fdb: don't flush ext_learn entries

commit f2f3729fb65c5c2e6db234e6316b71a7bdc4b30b upstream.

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@nvidia.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
net/bridge/br_fdb.c