What's the feature?

FDP-1387 added support for learning remote FDBs that are advertised through BGP-EVPN by remote peers.

However, it's possible OVN receives traffic from remote hosts (through EVPN VTEPs) whose MAC address was not advertised through an EVPN route.

Currently, in OVN 25.09, ovn-controller will not dynamically learn the mapping between the external host MAC (source) and EVPN VTEP the traffic was received on.  Which means that whenever OVN has to forward traffic to those destinations it will flood it (unknown unicast flooding) to all EVPN VTEPs it learned for that broadcast domain (logical switch).

This is tracked upstream through the following TODO item:

https://github.com/ovn-org/ovn/blob/dee71c367e3a362811e517596708ba0c30dc4398/TODO.rst?plain=1#L161-L162

For regular L2 fabric integration (through regular Logical Switches) OVN supports FDB learning and will dynamically learn the mac + logical port mapping and use it in order to reduce unknown unicast traffic flooding (if configured).

OVN should expose configuration to enable a similar way of FDB learning for EVPN-enabled logical switches.  Potentially through a NB.Logical_Switch.other_config:dynamic-routing-unknown-fdb-learning=true|false option.  (Note: the option name is just a suggestion, there might be better alternatives).

Potential implementation-relevant note: OVN's L2 EVPN implementation is such that FDB entries that were advertised by BGP peers are learnt by ovn-controllers and only kept in-memory.  That's because each individual chassis will likely have to use different VTEPs for reaching the remote MACs.  The new dynamic FDB learning feature will probably have to behave in a similar way.  The difference with pure logical switch FDB learning in this case is that ovn-controller will have to take care of aging the EVPN dynamic FDB entries itself (instead of ovn-northd doing that).

The already existing NB.Logical_Switch.other_config:dynamic-routing-fdb-prefer-local=true|false option will have to also apply to dynamically learned FDB entries.  That is, if prefer-local=true, all FDB entries learnt from EVPN (either advertised by peers or dynamically learnt) should have a higher preference in the switching decision.  If prefer-local=false, OVN known (LSP mac addresses) or learnt (SB.FDB) mappings should be preferred over FDB entries learnt from EVPN (advertised by peers or dynamically learnt).

Why is it needed?

It reduces the amount of traffic in the fabric when OVN has to forward packets through EVPN switches towards remote MACs that are not explicitly advertised by EVPN peers.

Who will benefit? 

(Future) Users of the OVN EVPN support, i.e. OpenStack and potentially OpenShift.