See comments inline. >To: dev@openvswitch.org >From: Gurucharan Shetty >Sent by: "dev" >Date: 05/10/2016 08:10PM >Cc: Gurucharan Shetty <g...@ovn.org> >Subject: [ovs-dev] [PATCH 2/5] ovn: Introduce l3 gateway router. > >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.
Completely agree up to this point. >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. Completely agree that you need to go through a common point in both directions in the same chassis. Why does this require a separate gateway router? Why can't it just be a centralized gateway router port on an otherwise distributed router? Looking at the logic for ports on remote chassis in physical.c, I see no reason why that logic cannot work for logical router datapaths just like it works for logical switch datapaths. On logical switches, some ports are distributed and run everywhere, e.g. localnet, and other ports run on a specific chassis, e.g. vif and your proposed "gateway" port. Am I missing something that prevents a mix of centralized and distributed ports on a logical router datapath? We have not tried it yet, but it seems like this would simplify things a lot: 1. Only one router needs to be provisioned rather than a distributed router and a centralized gateway router 2. No need for static routes between the distributed and centralized gateway routers 3. No need for transit logical switches, transit subnets, or transit flows 4. Less passes through datapaths, improving performance You can then pin DNAT and SNAT logic to the centralized gateway port, for traffic to physical networks. East/west traffic to floating IPs still requires additional logic on other ports, as proposed in Chandra's floating IP patch. We want to get to a point where SNAT traffic goes through a centralized gateway port, but DNAT traffic goes through a distributed patch port. This would achieve parity with the OpenStack ML2 OVS DVR reference implementation, in terms of traffic subsets that are centralized versus distributed. >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. Completely agree that this is the right way to go. >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. I like this logic. My only concern is whether the logical switch port for this functionality should really be called 'gateway', since this may get confused with L2 gateway. Some possibilities: 'patch2l3gateway', 'localpatch', 'chassispatch'. Holding off on more specific comments until we resolve the big picture stuff. Mickey _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
