On Fri, Jan 6, 2017 at 3:20 PM, Ben Pfaff <b...@ovn.org> 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 <mickeys....@gmail.com> > > 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. Mickey _______________________________________________ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
