[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