[ovs-build] Canceled: openvswitch/ovs#3989 (branch-2.7 - 4bfb0b5)
Travis CI
builds at travis-ci.org
Wed Feb 1 14:16:48 UTC 2017
Build Update for openvswitch/ovs
-------------------------------------
Build: #3989
Status: Canceled
Duration: 2 hours, 39 minutes, and 43 seconds
Commit: 4bfb0b5 (branch-2.7)
Author: Mickey Spiegel
Message: ovn: Introduce distributed gateway port and "chassisredirect" port binding
Currently OVN distributed logical routers achieve reachability to
physical networks by passing through a "join" logical switch to a
centralized gateway router, which then connects to another logical
switch that has a localnet port connecting to the physical network.
This patch adds logical port and port binding abstractions that allow
an OVN distributed logical router to connect directly to a logical
switch that has a localnet port connecting to the physical network.
In this patch, this logical router port is called a "distributed
gateway port".
The primary design goal of distributed gateway ports is to allow as
much traffic as possible to be handled locally on the hypervisor
where a VM or container resides. Whenever possible, packets from
the VM or container to the outside world should be processed
completely on that VM's or container's hypervisor, eventually
traversing a localnet port instance on that hypervisor to the
physical network. Whenever possible, packets from the outside
world to a VM or container should be directed through the physical
network directly to the VM's or container's hypervisor, where the
packet will enter the integration bridge through a localnet port.
However, due to the implications of the use of L2 learning in the
physical network, as well as the need to support advanced features
such as one-to-many NAT (aka IP masquerading), where multiple
logical IP addresses spread across multiple chassis are mapped to
one external IP address, it will be necessary to handle some of the
logical router processing on a specific chassis in a centralized
manner. For this reason, the user must associate a chassis with
each distributed gateway port.
In order to allow for the distributed processing of some packets,
distributed gateway ports need to be logical patch ports that
effectively reside on every hypervisor, rather than "l3gateway"
ports that are bound to a particular chassis. However, the flows
associated with distributed gateway ports often need to be
associated with physical locations. This is implemented in this
patch (and subsequent patches) by adding "is_chassis_resident()"
match conditions to several logical router flows.
While most of the physical location dependent aspects of distributed
gateway ports can be handled by restricting some flows to specific
chassis, one additional mechanism is required. When a packet
leaves the ingress pipeline and the logical egress port is the
distributed gateway port, one of two different sets of actions is
required at table 32:
- If the packet can be handled locally on the sender's hypervisor
(e.g. one-to-one NAT traffic), then the packet should just be
resubmitted locally to table 33, in the normal manner for
distributed logical patch ports.
- However, if the packet needs to be handled on the chassis
associated with the distributed gateway port (e.g. one-to-many
SNAT traffic or non-NAT traffic), then table 32 must send the
packet on a tunnel port to that chassis.
In order to trigger the second set of actions, the
"chassisredirect" type of southbound port_binding is introduced.
Setting the logical egress port to the type "chassisredirect"
logical port is simply a way to indicate that although the packet
is destined for the distributed gateway port, it needs to be
redirected to a different chassis. At table 32, packets with this
logical egress port are sent to a specific chassis, in the same
way that table 32 directs packets whose logical egress port is a
VIF or a type "l3gateway" port to different chassis. Once the
packet arrives at that chassis, table 33 resets the logical egress
port to the value representing the distributed gateway port. For
each distributed gateway port, there is one type "chassisredirect"
port, in addition to the distributed logical patch port
representing the distributed gateway port.
A "chassisredirect" port represents a particular instance, bound
to a specific chassis, of an otherwise distributed port. A
"chassisredirect" port is associated with a chassis in the same
manner as a "l3gateway" port. However, unlike "l3gateway" ports,
"chassisredirect" ports have no associated IP or MAC addresses,
and "chassisredirect" ports should never be used as the "inport".
Any pipeline stages that depend on port specific IP or MAC addresses
should be carried out in the context of the distributed gateway
port's logical patch 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. distributed gateway ports), flows specifying a
"chassisredirect" port as the outport will be added as part of that
capability.
Signed-off-by: Mickey Spiegel <mickeys.dev at gmail.com>
Signed-off-by: Ben Pfaff <blp at ovn.org>
View the changeset: https://github.com/openvswitch/ovs/compare/c3bfa9972f22...4bfb0b5dca36
View the full build log and details: https://travis-ci.org/openvswitch/ovs/builds/197123529
--
You can configure recipients for build notifications in your .travis.yml file. See https://docs.travis-ci.com/user/notifications
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openvswitch.org/pipermail/ovs-build/attachments/20170201/677ddab8/attachment-0001.html>
More information about the build
mailing list