[ovs-dev] [RFC v4 0/5] ovn: add distributed NAT capability

[Mickey Spiegel]

Currently OVN supports NAT functionality by connecting each distributed
logical router to a centralized "l3gateway" router that resides on a
single chassis.  NAT is only carried out in the "l3gateway" router.

This patch set introduces NAT capability in the distributed logical
router itself, avoiding the need to pass through a transit logical
switch and a second logical router, and in many cases avoiding the need
to pass through a centralized chassis.

NAT functionality is associated with the logical router gateway port.
In order to support one-to-many SNAT (aka IP masquerading), where
multiple private IP addresses spread across multiple chassis are mapped
to a single public IP address, it will be necessary to handle some of
the logical router processing on a specific chassis in a centralized
manner.  Some NAT flows are handled in a distributed manner on all
chassis (following the local "patch" port as is normally done for
distributed logical routers), while other NAT flows are handled on a
centralized "redirect-chassis".

North/south DNAT and SNAT are working, including some automated tests.
There is another patch required to get east/west NAT working, which
be produced very soon:

1. Add egress loopback capability, along with associated
   flags.egress_loopback.  When flags.egress_loopback is set, at the
   end of the egress pipeline, instead of the packet being sent out the
   outport, the packet is forced back to the beginning of the ingress
   pipeline with inport = outport.  All other registers are cleared, as
   if the packet just arrived on that inport.
   This capability is needed in order to implement some of the
   east/west NAT flows.
   Note: The existing flags.loopback allows a packet to go from the end
   of the ingress pipeline to the beginning of the egress pipeline with
   outport = inport, which is different.

Other possible to do items include:

2. The NAT flows patch lifts the restriction that conntrack zones are
   only assigned to datapaths for gateway routers.  Given recent
   changes to ovn-controller, a hypervisor only sees the datapaths
   for which there is a port resident on this chassis, or datapaths
   reachable from ports resident on this chassis.  Is that good
   enough?  Or should conntrack zone assignment for datapaths be
   restricted further, perhaps only to logical router datapaths?
3. The current automated test for NAT flows is single node, so it does
   not cover the distributed functionality.  Full coverage requires a
   multi-node test with conntrack NAT capability, either in the kernel
   or userspace.  Is this possible?
   Multi-node tests have been added for the chassisdirect patch,
   testing non-NAT aspects of the distributed router gateway port.
4. Consider how to generalize distributed versus centralized handling
   of non-NAT traffic being output on the distributed gateway port.
   If MAC learning is used in the upstream network, then the
   distributed gateway port’s MAC address must be restricted to the
   redirect-chassis by using the chassisredirect port.  In the
   presence of dynamic protocols such as BGP EVPN, non-NAT traffic
   could be handled in a distributed manner.
5. Gratuitous ARP for NAT addresses needs to be updated for
   distributed NAT.
6. Add load balancing on the redirect chassis of an otherwise
   distributed logical router.

Are any of 2 through 5 necessary for this patch set to be accepted?

v3 -> v4
Rebased to pick up recent changes to ovn-controller, including a fix
to the localnet issue where VIFs had to be added on a chassis in order
to cause the localnet port to be instantiated.
The chassisredirect port logic was rewritten to avoid creating an
ofport.  Besides streamlining the code significantly, this fixed the
problem when the distributed port name was longer than 12 characters.
Restricted IPv6 ND replies for the router IP address to the redirect
chassis, similar to IPv4 ARP restrictions.
Added specific gateway redirect flows for unresolved ethernet
destination, so that ARP requests generated by the router are sent
through the redirect chassis regardless of NAT rules.
Relaxed checks in chassisredirect tests so that they are independent
of register assignments.
Renamed ovn-northd.c "l3gateway_port" to "l3dgw_port" in order to
avoid overlaps with gateway router terminology.

v2 -> v3
Reordered the first two patches.
Moved non-NAT specific flows from patch 5 to patch 2.
Added automated tests for is_chassis_resident (which is ready for
review) and chassisredirect patches.
Added flows to limit ICMP echo replies for router IPs on the gateway
interface, so that they are only generated on the redirect-chassis.

Mickey Spiegel (5):
  ovn: add is_chassis_resident match expression component
  ovn: Introduce "chassisredirect" port binding
  ovn: move load balancing flows after NAT flows
  ovn: avoid snat recirc only on gateway routers
  ovn: distributed NAT flows

 include/ovn/actions.h           |   3 +
 include/ovn/expr.h              |  22 +-
 ovn/controller/binding.c        |   8 +
 ovn/controller/lflow.c          |  49 ++-
 ovn/controller/lflow.h          |   5 +-
 ovn/controller/ovn-controller.c |  15 +-
 ovn/controller/physical.c       |  63 ++++
 ovn/lib/actions.c               |  15 +-
 ovn/lib/expr.c                  | 155 ++++++++-
 ovn/northd/ovn-northd.8.xml     | 347 +++++++++++++++++++-
 ovn/northd/ovn-northd.c         | 678 ++++++++++++++++++++++++++++++++--------
 ovn/ovn-nb.ovsschema            |  13 +-
 ovn/ovn-nb.xml                  |  70 ++++-
 ovn/ovn-sb.xml                  |  35 +++
 ovn/utilities/ovn-trace.c       |  21 +-
 tests/ovn.at                    | 291 ++++++++++++++++-
 tests/system-ovn.at             | 155 +++++++++
 tests/test-ovn.c                |  15 +-
 18 files changed, 1782 insertions(+), 178 deletions(-)

-- 
1.9.1