On 17 August 2016 at 14:11, Mickey Spiegel <mickeys....@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@openvswitch.org > http://openvswitch.org/mailman/listinfo/dev > _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev