On Fri, Jan 6, 2017 at 3:47 PM, Mickey Spiegel <[email protected]> wrote:
> > > On Fri, Jan 6, 2017 at 3:20 PM, Ben Pfaff <[email protected]> wrote: > >> On Fri, Jan 06, 2017 at 12:00:30PM -0800, Mickey Spiegel wrote: >> > Currently OVN handles all logical router ports in a distributed manner, >> > creating instances on each chassis. The logical router ingress and >> > egress pipelines are traversed locally on the source chassis. >> > >> > In order to support advanced features such as one-to-many NAT (aka IP >> > masquerading), where multiple private IP addresses spread across >> > multiple chassis are mapped to one public IP address, it will be >> > necessary to handle some of the logical router processing on a specific >> > chassis in a centralized manner. >> > >> > The goal of this patch is to develop abstractions that allow for a >> > subset of router gateway traffic to be handled in a centralized manner >> > (e.g. one-to-many NAT traffic), while allowing for other subsets of >> > router gateway traffic to be handled in a distributed manner (e.g. >> > floating IP traffic). >> > >> > This patch introduces a new type of SB port_binding called >> > "chassisredirect". A "chassisredirect" port represents a particular >> > instance, bound to a specific chassis, of an otherwise distributed >> > port. 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 do not treat this port >> > as a local port. >> > >> > A "chassisredirect" port should never be used as an "inport". When an >> > ingress pipeline sets the "outport", it may set the value to a logical >> > port of type "chassisredirect". This will cause the packet to be >> > directed to a specific chassis to carry out the egress logical router >> > pipeline, in the same way that a logical switch forwards egress traffic >> > to a VIF port residing on a specific chassis. At the beginning of the >> > egress pipeline, the "outport" will be reset to the value of the >> > distributed port. >> > >> > For outbound traffic to be handled in a centralized manner, the >> > "outport" should be set to the "chassisredirect" port representing >> > centralized gateway functionality in the otherwise distributed router. >> > For outbound traffic to be handled in a distributed manner, locally on >> > the source chassis, the "outport" should be set to the existing "patch" >> > port representing distributed gateway functionality. >> > >> > Inbound traffic will be directed to the appropriate chassis by >> > restricting source MAC address usage and ARP responses to that chassis, >> > or by running dynamic routing protocols. >> > >> > Note that "chassisredirect" ports have no associated IP or MAC >> addresses. >> > Any pipeline stages that depend on port specific IP or MAC addresses >> > should be carried out in the context of the distributed port. >> > >> > Although the abstraction represented by the "chassisredirect" port >> > binding is generalized, in this patch the "chassisredirect" port binding >> > is only created for NB logical router ports that specify the new >> > "redirect-chassis" option. There is no explicit notion of a >> > "chassisredirect" port in the NB database. The expectation is when >> > capabilities are implemented that take advantage of "chassisredirect" >> > ports (e.g. NAT), the addition of flows specifying a "chassisredirect" >> > port as the outport will also be triggered by the presence of the >> > "redirect-chassis" option. Such flows are added for NB logical router >> > ports that specify the "redirect-chassis" option. >> > >> > Signed-off-by: Mickey Spiegel <[email protected]> >> >> chassisredirect ports seem incredibly similar to vif ports. Is the only >> difference that the output port is changed at the beginning of the >> egress pipeline? That's something that could be implemented in the >> logical egress pipeline with 'outport = "...";'. We do say that the >> outport isn't supposed to be modified in an egress pipeline, but nothing >> enforces that and if it's actually useful then we could just change the >> documentation. >> > > I don't get the similarity to vif ports. > > I need to create two different ports for each logical router port > specifying a "redirect-chassis". One represents the centralized > instance, for traffic that needs to be centralized. The other > represents the distributed instance, i.e. just take the local patch > port and go to/from the local logical router instance. I wanted the > egress pipeline processing to be the same regardless of whether > the packet arrived at the egress pipeline on the port representing > the centralized instance, or whether the packet arrived at the > egress pipeline on the port representing the distributed instance. > > There is no pipeline processing of the chassisredirect port, > except as the outport in the ingress pipeline. Everything else > happens in tables 32 and 33. > Elaborating a little further. All I need is a way to sometimes tell table 32 to go to a certain chassis, and other times to let table 32 send it to table 33 locally, on a packet by packet basis, with the same outport by the time the packet gets to the egress pipeline. Since table 32 works on a port basis, I created a port representation. Mickey _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
