[ovs-dev] [PATCH v7 3/7] ovn: Introduce "chassisredirect" port binding

Mickey Spiegel mickeys.dev at gmail.com
Fri Jan 6 23:52:15 UTC 2017


On Fri, Jan 6, 2017 at 3:47 PM, Mickey Spiegel <mickeys.dev at gmail.com>
wrote:

>
>
> On Fri, Jan 6, 2017 at 3:20 PM, Ben Pfaff <blp at 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.dev at 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.
>

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


More information about the dev mailing list