On Fri, Jan 6, 2017 at 4:11 PM, Ben Pfaff <[email protected]> wrote: > On Fri, Jan 06, 2017 at 03:47:03PM -0800, Mickey Spiegel 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. > > OK, then I'm having trouble following the description. For me, here's > the key paragraphs that led me to my conclusions: > > 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. > > The first paragraph appears to say that a chassisredirect port is a port > on a particular chassis and that its chassis column says what chassis > it's on. OK, that's the same as a vif port, right? >
Yes, the same as vif, l2gateway, or l3gateway in the sense that this port is bound to a chassis. No differences there. > > The second paragraph appears to me to say, first, that packets would > never originate from a chassisredirect port. OK, fine, no problem. > Second, it directly makes an analogy to vif ports, and then says that > the outport changes. No problem. > Two main differences from vif: 1. The outport changes. I want the ct_zone assignments in table 33 and the loopback check in table 34 to be according to the new outport. 2. There is no pipeline processing of this port. This port has no addresses or other configuration. The purpose of the port is to tell table 32 to go to a particular chassis, and then tell table 33 what the real outport should be. I got to this notion because a port is the way to tell table 32 to go to a particular chassis. The first thought was two regular patch ports, but the idea of two patch ports with the same addresses is confusing and dangerous. By changing back to the real patch port right away in the egress pipeline, it avoids those problems. Mickey > I guess that I must be missing important points, but that's why I > interpreted the text as I did. Can you help me figure out why I'm not > following? > > Thanks, > > Ben. > _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
