On 2 June 2016 at 13:23, Ben Pfaff <b...@ovn.org> wrote: > 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 <g...@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? >
Thank you! ovn-architecture may be a place to fit it in. I will try to do that as part of a separate patch. > > > 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. > > I made the change above and replaced a mention of 'non-distributed router' to a 'a Gateway router (which is centralized)' and applied it. > > + 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 <b...@ovn.org> > _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
