This series advertises distributed dnat_and_snat NAT entries (floating
IPs) over BGP-EVPN as Type-2 MAC+IP routes, gated by a new 'nat' token of
the provider Logical_Switch 'dynamic-routing-redistribute' option.

Verified in a lab deployment: a distributed floating IP is published in
the SB Advertised_MAC_Binding table, programmed into the EVPN advertise
interface by ovn-controller, advertised as a Type-2 route by FRR, and
reachable from an EVPN peer.

v5 -> v6:
 - Rebase on main; v5 failed to apply because of the SB schema and NEWS
   changes from the merged EVPN ARP/ND suppression series.  The
   Advertised_MAC_Binding 'type' column now bumps the schema version to
   21.10.0 (on top of 21.9.0), and the NEWS entry sits next to the new
   EVPN suppression one.  No functional change from v5.

v4 -> v5 (all from Ales' review, thanks!):
 - Add a 'type' column ("ip"/"nat") to Advertised_MAC_Binding so that
   ovn-controller advertises each row based on the matching redistribute
   token.  The controller now walks the table in a single pass (instead
   of once in the FDB collector and once in the IP collector), and a
   floating IP comes out as a Type-2 route with the 'nat' token alone,
   without also enabling 'ip'/'fdb'.
 - en-advertised-mac-binding-sync no longer triggers a plain recompute on
   en_northd/en_lr_nat.  It uses a northd change handler gated on the
   tracked switches and tracked NAT routers, and reads lr_nat purely as
   input data (engine_noop_handler).
 - Drop the engine input comments on the plain handlers (a comment is
   kept only on the engine_noop_handler input).
 - Extend the NAT 'dynamic-routing-advertise' documentation to mention it
   also controls the Type-2 advertisement.

On the v4 review note about splitting out a "fix for existing behavior":
I looked into it and could not find one.  With the previous
engine_noop_handler on en_northd, toggling the LS 'ip' token (or
dynamic-routing-vni) and the per-port 'dynamic-routing-advertise' option
already take effect, because those changes also update the SB
Port_Binding rows that this node already depends on.  Only a NAT change
does not touch a Port_Binding here, which is why the node now needs the
tracked-NAT signal.  So there is no separate pre-existing fix to split
out; the new handler exists purely to gate the NAT recompute.

Chanyeol Yoon (2):
  northd: Advertise distributed NAT IPs over EVPN.
  controller: Advertise EVPN MAC bindings by type.

 .../topics/dynamic-routing/architecture.rst   |  12 ++
 NEWS                                          |   6 +
 controller/neighbor.c                         |  81 +++++++---
 lib/ovn-util.c                                |   3 +
 lib/ovn-util.h                                |   3 +-
 northd/en-advertised-route-sync.c             | 142 ++++++++++++++++--
 northd/en-advertised-route-sync.h             |   3 +
 northd/inc-proc-northd.c                      |   7 +-
 ovn-nb.xml                                    |  27 ++++
 ovn-sb.ovsschema                              |   6 +-
 ovn-sb.xml                                    |  19 +++
 tests/ovn-inc-proc-graph-dump.at              |   3 +-
 tests/ovn-northd.at                           |  98 ++++++++++++
 13 files changed, 372 insertions(+), 38 deletions(-)


base-commit: 31e11ad650b096738e17e4ddde4c2f5f2c5e6bd5
-- 
2.54.0 (Apple Git-156)

_______________________________________________
dev mailing list
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Reply via email to