[ovs-dev] [PATCH v3 2/5] ovn: Introduce l3 gateway router.

[Ben Pfaff]

On Thu, May 19, 2016 at 01:02:31PM -0700, Gurucharan Shetty wrote:
> Currently OVN has distributed switches and routers. When a packet
> exits a container or a VM, the entire lifecycle of the packet
> through multiple switches and routers are calculated in source
> chassis itself. When the destination endpoint resides on a different
> chassis, the packet is sent to the other chassis and it only goes
> through the egress pipeline of that chassis once and eventually to
> the real destination.
> 
> When the packet returns back, the same thing happens. The return
> packet leaves the VM/container on the chassis where it resides.
> The packet goes through all the switches and routers in the logical
> pipleline on that chassis and then sent to the eventual destination
> over the tunnel.
> 
> The above makes the logical pipeline very flexible and easy. But,
> creates a problem for cases where you need to add stateful services
> (via conntrack) on switches and routers.
> 
> For l3 gateways, we plan to leverage DNAT and SNAT functionality
> and we want to apply DNAT and SNAT rules on a router. So we ideally need
> the packet to go through that router in both directions in the same
> chassis. To achieve this, this commit introduces a new gateway router which is
> static and can be connected to your distributed router via a switch.
> 
> To make minimal changes in OVN's logical pipeline, this commit
> tries to make the switch port connected to a l3 gateway router look like
> a container/VM endpoint for every other chassis except the chassis
> on which the l3 gateway router resides. On the chassis where the
> gateway router resides, the connection looks just like a patch port.
> 
> This is achieved by the doing the following:
> Introduces a new type of port_binding record called 'gateway'.
> On the chassis where the gateway router resides, this port behaves just
> like the port of type 'patch'. The ovn-controller on that chassis
> populates the "chassis" column for this record as an indication for
> other ovn-controllers of its physical location. Other ovn-controllers
> treat this port as they would treat a VM/Container port on a different
> chassis.
> 
> Signed-off-by: Gurucharan Shetty <guru at ovn.org>

The commit mesagee description above is really good.  Do you think that
it would be appropriate to include it, or some variant, somewhere in the
documentation as introductory or tutorial material?

> diff --git a/ovn/ovn-sb.xml b/ovn/ovn-sb.xml
> index efd2f9a..741228c 100644
> --- a/ovn/ovn-sb.xml
> +++ b/ovn/ovn-sb.xml
> @@ -1220,7 +1220,12 @@ tcp.flags = RST;
>        which <code>ovn-controller</code>/<code>ovn-controller-vtep</code> in
>        turn finds out by monitoring the local hypervisor's Open_vSwitch
>        database, which identifies logical ports via the conventions described
> -      in <code>IntegrationGuide.md</code>.
> +      in <code>IntegrationGuide.md</code>. (The exceptions are for

Instead of "of <code>type</code> 'gateway' here";
> +      <code>Port_Binding</code> records of <code>type</code> 'gateway',
I would write "with <code>type</code> of <code>gateway</code>", so that
we are consistent about fonts.

> +      whose locations are identified by <code>ovn-northd</code> via
> +      the <code>options:gateway-chassis</code> column in this table.
> +      <code>ovn-controller</code> is still responsible to populate the
> +      <code>chassis</code> column.)
>      </p>

Acked-by: Ben Pfaff <blp at ovn.org>