This task is tracking the test case writing activities to cover the feature request described below.

What's the feature?

Currently OVN's L2 EVPN integration doesn't support externally learned FDB records that
are reachable through multiple VTEPs (multi-homed / ECMP). ovn-controller monitors the L2 VRF linux bridge FDB table but only installs records that are reachable through a single remote VTEP.

Why is it needed?

In multi-homed EVPN deployments (with some of the L2 addresses reachable at the same cost) it's important that other parts of the L2 EVPN domain can reach the multi-homed workloads on all paths, enabling load sharing across paths.
 

Who will benefit? 

Users that care about All-Active Layer-2 multihoming (ECMP) for EVPN, i.e., ovn-kubernetes, OpenStack.

A sample configuration is available through the following script:
https://github.com/dceara/ovn/blob/5fa75935c60c01d47291253572ab587ae09b1e33/tutorial/bgp/setup-l2-multihoming.sh

This simulates the following topology:

               +---- evpn-host2  ---+
               |                    |
evpn-host1 ----+                    +--- simulated-multi-homed-workloads
               |                    |
               +---- evpn-host3  ---+

With BGP EVPN sessions between host1 <> host2 and host1 <> host3. Host1 learns the multi-homed FDBs via both other EVPN speakers and installs FDB entries in the kernel in the following form:

# Check "ECMP" FDB on host1:
podman exec $h1 bridge fdb show static | grep 00:00:33:22:11:10
00:00:33:22:11:10 dev vxlan-10 vlan 1 extern_learn master br-10 
00:00:33:22:11:10 dev vxlan-10 extern_learn master br-10 
00:00:33:22:11:10 dev vxlan-10 nhid 536870913 self extern_learn

# Check "ECMP" nexthops on host1:
$ podman exec $h1 ip nexthop
id 268435458 via 20.0.0.2 scope link fdb
id 268435460 via 20.0.0.3 scope link fdb
id 536870913 group 268435458/268435460 fdb
id 536870915 group 268435458/268435460 fdb