Re: [PATCH] net: bridge: vxlan: Protocol field in bridge fdb

On Tue, Jun 09, 2026 at 06:55:10PM -0400, Patrice Brissette wrote:
> I'm following up on the status of this patch series. This feature is
> critical for our EVPN Multihoming deployments, and the corresponding
> FRRouting work is currently blocked pending support for this
> functionality.
> 
> Has there been any progress on this effort, or has someone else picked
> it up?

No. Assumption was that the author will follow up on the feedback.

> What are the next steps?

Before I answer this, I have some questions / comments below.

> 
> For reference, the proposed work includes:
> 
> Adding support for a protocol field to bridge and VXLAN FDB entries.
> 
> Allowing the protocol field to identify the source of an FDB update,
> for example:
> 
> Zebra for control-plane-originated entries
> 
> HW for data-plane-learned entries (e.g., ASIC-learned MACs)

Note that entries installed by the kernel (as opposed to user space)
will always be programmed with RTPROT_KERNEL, regardless of the data
path in which they were learned (software / hardware).

> 
> Extending iproute2 to support configuration and display of this new field.
> 
> The primary use case is EVPN Multihoming with ARP/ND synchronization
> for hosts that are multihomed to a set of routers. In this
> environment, the same MAC address may be learned locally by hardware
> when the host is directly attached, or installed by the control plane
> when the entry is synchronized through BGP, as commonly occurs in
> all-active scenarios.
> 
> The protocol field allows FRRouting to distinguish
> control-plane-installed entries from hardware-learned entries,
> enabling correct MAC mobility handling, ES peer synchronization, and
> proper processing of MAC ownership changes.

Can't this be achieved by using "activity_notify"?

See:

https://git.kernel.org/pub/scm/network/iproute2/iproute2-next.git/commit/?id=e041178ba6bc2af0a1148145ee303c9db79fb4cb
https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git/commit/?id=5e88777a382480d0b1f7eafb6d0fb680ec7a40bb

When an FDB entry is learned on an ES, install it with "activity_notify
norefresh":

es1# bridge fdb replace 00:aa:bb:cc:dd:ee dev bond1 master static activity_notify norefresh
es1# # bridge -d fdb get 00:aa:bb:cc:dd:ee br br1
00:aa:bb:cc:dd:ee dev bond1 activity_notify master br1 static

It will transition to "inactive" after the aging time elapsed:

es1# bridge -d fdb get 00:aa:bb:cc:dd:ee br br1
00:aa:bb:cc:dd:ee dev bond1 activity_notify inactive master br1 static

And install it as "activity_notify inactive" when synchronizing it to
other ES peers:

es2# bridge fdb add 00:aa:bb:cc:dd:ee dev bond1 master static activity_notify inactive
es2# bridge -d fdb get 00:aa:bb:cc:dd:ee br br1
00:aa:bb:cc:dd:ee dev bond1 activity_notify inactive master br1 static

Then entry will become active if later it is refreshed / learned by the
data path:

es2# bridge -d fdb get 00:aa:bb:cc:dd:ee br br1
00:aa:bb:cc:dd:ee dev bond1 activity_notify master br1 static