Currently ovn-controller doesn't explicitly handle ECMP route next-hop related events (addition/removal to/from a route).

In most cases that's fine, however, for ECMP symmetric reply, the next-hop mac addresses end up being stored in conntrack record labels/marks.  These become stale when the next-hop is not used anymore (the ECMP path is removed in the NB database).

A previous attempt to handle such events through learn() flows https://bugzilla.redhat.com/show_bug.cgi?id=2096233 introduced a performance regression and essentially got reverted (https://github.com/ovn-org/ovn/commit/23fdc5fe43b3147538ab124d0f8fcd5d2c13ba25)

A proper solution might be to store ECMP symmetric reply next-hop records in the Southbound database and manage their lifecycle (including flushing conntrack entries whose label includes old next-hop mac addresses) in ovn-controller.

This depends on OVS exposing an openflow API to filter conntrack flush operations based on ct_label/ct_mark contents: https://issues.redhat.com/browse/FDP-55