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

Guru Shetty guru at ovn.org
Mon Oct 3 20:40:27 UTC 2016


On 17 August 2016 at 14:11, Mickey Spiegel <mickeys.dev at gmail.com> wrote:

> 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".
>
> This patch set is being sent out early to solicit feedback on the
> approach.  There are two required patches that have not yet been
> started:
>
> 1. Add match conditions that restrict a logical flow to a specified
>    chassis, and that restrict a logical flow to the chassis where a
>    specific logical port is resident.  These match conditions should be
>    evaluated in controller/lflow.c, preventing the flow from being sent
>    down to ofctl if the match conditions are not met.
>
> 2. 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.
>
> Mickey Spiegel (2):
>   ovn: Introduce "chassisredirect" port binding
>   ovn: distributed NAT flows
>

I was mainly waiting for 2.6 release to get to anything that is not 2.6
related. There has been quite a bit of changes with respect to incremental
processing, to make a good review on this. (I am also going on a vacation
for a couple of weeks starting next.). If this is still of interest, would
you mind re-spinning it?


>
>  ovn/controller/binding.c            | 151 +++++++++++-
>  ovn/controller/ovn-controller.8.xml |  15 ++
>  ovn/controller/ovn-controller.c     |   8 +-
>  ovn/controller/physical.c           |  73 +++++-
>  ovn/controller/physical.h           |   2 +
>  ovn/northd/ovn-northd.8.xml         | 292 ++++++++++++++++++++++-
>  ovn/northd/ovn-northd.c             | 461 ++++++++++++++++++++++++++++++
> +-----
>  ovn/ovn-nb.ovsschema                |  13 +-
>  ovn/ovn-nb.xml                      |  66 +++++-
>  ovn/ovn-sb.xml                      |  35 +++
>  10 files changed, 1028 insertions(+), 88 deletions(-)
>
> --
> 1.9.1
>
> _______________________________________________
> dev mailing list
> dev at openvswitch.org
> http://openvswitch.org/mailman/listinfo/dev
>



More information about the dev mailing list