| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
| |
Signed-off-by: Ben Pfaff <blp@ovn.org>
Acked-by: Mickey Spiegel <mickeys.dev@gmail.com>
|
| |
|
|
|
|
|
| |
This feature is useful for centralized gateways.
Signed-off-by: Ben Pfaff <blp@ovn.org>
Acked-by: Mickey Spiegel <mickeys.dev@gmail.com>
|
| |
|
|
|
|
|
|
|
| |
This isn't used yet by the actions code, but an upcoming commit will
introduce a user. This commit just adjusts ovn-trace to use this common
type instead of its own local type.
Signed-off-by: Ben Pfaff <blp@ovn.org>
Acked-by: Mickey Spiegel <mickeys.dev@gmail.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Until now, formatting the "next" action has always required including
the table number, because the action struct didn't include enough context
so that the formatter could decide whether the table number was the next
table or some other table. This is more or less OK, but an upcoming commit
will add a "pipeline" field to the "next" action, which means that the same
policy there would require that the pipeline always be printed. That's a
little obnoxious because 99+% of the time, the pipeline to be printed is
the same pipeline that the flow is in and printing it would be distracting.
So it's better to store some context to help with formatting. This commit
begins adopting that policy for the existing table number field.
Signed-off-by: Ben Pfaff <blp@ovn.org>
Acked-by: Mickey Spiegel <mickeys.dev@gmail.com>
|
| |
|
|
|
|
|
|
|
| |
These actions aren't very similar but until now they both had the same
action structure. These structures are going to diverge in an upcoming
commit, so separate them now.
Signed-off-by: Ben Pfaff <blp@ovn.org>
Acked-by: Mickey Spiegel <mickeys.dev@gmail.com>
|
| |
|
|
|
| |
Signed-off-by: Ben Pfaff <blp@ovn.org>
Acked-by: Mickey Spiegel <mickeys.dev@gmail.com>
|
| |
|
|
|
|
|
|
|
|
|
| |
In some cases multiple kinds of OVN action share the same structure. In
all of these cases, a given kind of structure is freed one particular way
(it would be confusing if this were not the case), so there's no benefit
in having per-action free functions. Therefore, this commit switches to
a free function per structure type.
Signed-off-by: Ben Pfaff <blp@ovn.org>
Acked-by: Mickey Spiegel <mickeys.dev@gmail.com>
|
| |
|
|
|
|
|
|
|
| |
The common case is that "next" advances to the next table, but it can
jump to any table.
Reported-by: Mickey Spiegel <mickeys.dev@gmail.com>
Signed-off-by: Ben Pfaff <blp@ovn.org>
Acked-by: Mickey Spiegel <mickeys.dev@gmail.com>
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Before this commit, the OVN action parser would accept "arp {};" and then
the formatter would format it back as "arp { drop; };", but the parser
didn't accept the latter. There were basically two choices: make the
parser accept "arp { drop; };" or make the formatter output "arp {};"
(or both). This patch does (only) the former, and adds a test to avoid
regression.
Signed-off-by: Ben Pfaff <blp@ovn.org>
Acked-by: Mickey Spiegel <mickeys.dev@gmail.com>
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Without this change, lexer_force_match(lex, LEX_T_END) mostly works, except
that in the failure case it emits an error that says "expecting `$'",
which is a surprising error message.
Arguably, lexer_force_end() could be removed entirely, but I don't see a
real problem with the existing arrangement.
Signed-off-by: Ben Pfaff <blp@ovn.org>
Acked-by: Mickey Spiegel <mickeys.dev@gmail.com>
|
| |
|
|
|
|
|
|
|
|
|
|
| |
OVN logical actions are supposed to be padded to a multiple of 8 bytes,
but the code for parsing "arp" and "nd_na" actions didn't do this properly.
The result was that it worked OK if one of these actions was the last one
in a sequence of logical actions, but failed badly if they were in the
middle. This commit fixes the problem, adds assertions to make it harder
for the problem to recur, and adds a test.
Signed-off-by: Ben Pfaff <blp@ovn.org>
Acked-by: Mickey Spiegel <mickeys.dev@gmail.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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@gmail.com>
Signed-off-by: Ben Pfaff <blp@ovn.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch introduces a new match expression component
is_chassis_resident(). Unlike match expression comparisons,
is_chassis_resident is not pushed down to OpenFlow. It is a
conditional that is evaluated in the controller during expr_simplify(),
when it is replaced by a boolean expression. The is_chassis_resident
conditional evaluates to "true" when the specified string identifies a
port name that is resident on this controller chassis, i.e., the
corresponding southbound database Port_Binding has a chassis column
that matches this chassis. Otherwise it evaluates to "false".
This allows higher level features to specify flows that are only
installed on some chassis rather than on all chassis with the
corresponding datapath.
Suggested-by: Ben Pfaff <blp@ovn.org>
Signed-off-by: Mickey Spiegel <mickeys.dev@gmail.com>
Acked-by: Ben Pfaff <blp@ovn.org>
Signed-off-by: Ben Pfaff <blp@ovn.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Utilities like ovs-vsctl have the ability to bootstrap
CA certificate. It looks useful for ovn-nbctl to have
the same ability too. One could connect over to OVN NB
database over SSL for transactions without having to
copy over the certificate being used by ovsdb-server
backing OVN NB.
Signed-off-by: Gurucharan Shetty <guru@ovn.org>
Acked-by: Lance Richardson <lrichard@redhat.com>
Acked-by: Ben Pfaff <blp@ovn.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
ovn-controller accepts the option --bootstrap-ca-cert. With this
commit, ovn-ctl will let user pass a value for that via
--ovn-controller-ssl-bootstrap-ca-cert option.
Bootstrapping is useful for ovn-controller as you don't have to
copy the controller's certificate (self-signed or otherwise) to every host.
Signed-off-by: Gurucharan Shetty <guru@ovn.org>
Acked-by: Ben Pfaff <blp@ovn.org>
Acked-by: Lance Richardson <lrichard@redhat.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit uses the $PACKAGE_VERSION automake variable to construct a
release and version info combination which sets the library name to be:
libfoo-$(OVS_MAJOR_VERSION).so.$(OVS_MINOR_VERSION).0.$(OVS_MICRO_VERSION)
where formerly, it was always:
libfoo.so.1.0.0
This allows releases of Open vSwitch libraries to reflect which specific
versions they came with, and sets up a psuedo ABI-versioning scheme. In
this fashion, future releases of Open vSwitch could be installed
alongside older releases, allowing 3rd party utilities linked against
previous versions to continue to function.
ex:
$ ldd /path/to/utility
linux-vdso.so.1 (0x00007ffe92cf6000)
libopenvswitch-2.so.6 => /lib64/libopenvswitch-2.so.6 (0x00007f733b7a3000)
libssl.so.10 => /lib64/libssl.so.10 (0x00007f733b530000)
...
Note the library name and version information.
Signed-off-by: Aaron Conole <aconole@redhat.com>
Signed-off-by: Ben Pfaff <blp@ovn.org>
|
| |
|
|
|
|
|
|
| |
This patch adds a description of logical routers and logical patch ports,
including gateway routers, to ovn/ovn-architecture.7.xml.
Signed-off-by: Mickey Spiegel <mickeys.dev@gmail.com>
Signed-off-by: Ben Pfaff <blp@ovn.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently in OVN, when a logical switch port of type "router" is
created, the MAC and optionally IP addresses of the peer logical
router port must be specified again as the addresses of the logical
switch port.
This patch allows the logical switch port's addresses to be
specified as the string "router", rather than explicitly copying the
logical router port's MAC and optionally IP addresses. The router
addresses are used to populate the logical switch's destination
lookup, and to populate op->lsp_addrs in ovn-northd.c, which in turn
is used to generate logical switch ARP and ND replies. Since ipam
already looks at logical router ports, the only ipam modification
necessary is to skip logical switch ports with addresses "router".
Signed-off-by: Mickey Spiegel <mickeys.dev@gmail.com>
Acked-by: Ben Pfaff <blp@ovn.org>
Signed-off-by: Ben Pfaff <blp@ovn.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When one adds a new table to a database schema, it's easy to forget to
add the table to the list of tables in the *ctl.c program. When this
happens, the database commands for that program don't work on that table
at all, even for commands like "list" and "create" that don't need any
special help. This patch fixes that problem, by making sure that
db-ctl-base always has the complete list of tables.
Previously, each ctl_table_class pointed directly to the corresponding
ovsdb_idl_table_class. With this patch, there are instead two parallel
arrays, one of ovsdb_idl_table_classes and the other of ctl_table_classes.
This change accounts for the bulk of the change to the db-ctl-base code.
Signed-off-by: Ben Pfaff <blp@ovn.org>
Acked-by: Lance Richardson <lrichard@redhat.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
ovn-controller implements traversal from one OVN logical network to another
using the Open vSwitch "clone" action. The "clone" action preserves
connection tracking state, which is confusing for passing from one logical
datapath to another because this state is only relevant for a single
logical datapath and does not make sense in the new one. This commit
fixes a problem sometimes seen by ensuring that the connection tracking
state is cleared when these traversals happen.
Reported-by: Numan Siddique <nusiddiq@redhat.com>
Reported-at: https://mail.openvswitch.org/pipermail/ovs-dev/2017-January/326948.html
Fixes: f1a8bd06d58f ("ovn-controller: Drop most uses of OVS patch ports.")
Tested-by: Dong Jun <dongj@dtdream.com>
|
| |
|
|
|
|
|
|
|
|
| |
The range of "PRIORITY" for "ovn-nbctl acl-add " command is 1 to 65534 in
ovn-nbctl.8.xml",When configuring this command, it indicates that "
priority must in range 0...32767".The range of priority is inconsistent
in "ovn-nbctl.8.xml" and "ovn-nbctl.c".
Signed-off-by: zhaojingjing <zhao.jingjing1@zte.com.cn>
Signed-off-by: Ben Pfaff <blp@ovn.org>
|
| |
|
|
|
|
|
|
| |
When configuring the wrong tag for "ovn-nbctl lsp-add" command，
it shows "invalid tag". The range of the tag is not known.
Signed-off-by: zhaojingjing <zhao.jingjing1@zte.com.cn>
Signed-off-by: Ben Pfaff <blp@ovn.org>
|
| |
|
|
|
|
|
|
|
| |
We've used sparse "bitwise" annotations to make ofp_ports into a different
type, so this is required to avoid a sparse warning.
Fixes: 714651c7db6a ("ovn-controller: Introduce "inject-pkt" ovs-appctl command.")
Signed-off-by: Ben Pfaff <blp@ovn.org>
Acked-by: Justin Pettit <jpettit@ovn.org>
|
| |
|
|
|
|
|
|
|
|
| |
"enum ofp_version" is unsigned in the System V ABI used by Linux, so
it will never be less than 0, so an rconn with an unnegotiated version will
never be found properly. This fixes the problem.
Fixes: 714651c7db6a ("ovn-controller: Introduce "inject-pkt" ovs-appctl command.")
Signed-off-by: Ben Pfaff <blp@ovn.org>
Acked-by: Justin Pettit <jpettit@ovn.org>
|
| |
|
|
|
|
|
|
|
| |
Add the ability to inject a packet into the connected Open vSwitch
instance. This is primarily useful for testing when a test requires
side-effects from an actual packet, so ovn-trace won't do.
Signed-off-by: Justin Pettit <jpettit@ovn.org>
Acked-by: Ben Pfaff <blp@ovn.org>
|
| |
|
|
|
|
|
| |
This more closely follows our coding standards.
Signed-off-by: Justin Pettit <jpettit@ovn.org>
Acked-by: Ben Pfaff <blp@ovn.org>
|
| |
|
|
|
|
|
|
| |
Other functions in the main loop will need access to address sets in a
future commit.
Signed-off-by: Justin Pettit <jpettit@ovn.org>
Acked-by: Ben Pfaff <blp@ovn.org>
|
| |
|
|
|
|
|
|
| |
Macro is a very generic term, but the arguments are only ever address
sets, so rename for clarity.
Signed-off-by: Justin Pettit <jpettit@ovn.org>
Acked-by: Ben Pfaff <blp@ovn.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add support for SSL connections to OVN northbound and/or
southbound databases.
To improve security, the NB and SB ovsdb daemons no longer
have open ptcp connections by default. This is a change in
behavior from previous versions, users wishing to use TCP
connections to the NB/SB daemons can either request that
a passive TCP connection be used via ovn-ctl command-line
options (e.g. via OVN_CTL_OPTS/OVN_NORTHD_OPTS in startup
scripts):
--db-sb-create-insecure-remote=yes
--db-nb-create-insecure-remote=yes
Or configure a connection after the NB/SB daemons have been
started, e.g.:
ovn-sbctl set-connection ptcp:6642
ovn-nbctl set-connection ptcp:6641
Users desiring SSL database connections will need to generate certificates
and private key as described in INSTALL.SSL.rst and perform the following
one-time configuration steps:
ovn-sbctl set-ssl <private-key> <certificate> <ca-cert>
ovn-sbctl set-connection pssl:6642
ovn-nbctl set-ssl <private-key> <certificate> <ca-cert>
ovn-nbctl set-connection pssl:6641
On the ovn-controller and ovn-controller-vtep side, SSL configuration
must be provided on the command-line when the daemons are started, this
should be provided via the following command-line options (e.g. via
OVN_CTL_OPTS/OVN_CONTROLLER_OPTS in startup scripts):
--ovn-controller-ssl-key=<private-key>
--ovn-controller-ssl-cert=<certificate>
--ovn-controller-ssl-ca-cert=<ca-cert>
The SB database connection should also be configured to use SSL, e.g.:
ovs-vsctl set Open_vSwitch . \
external-ids:ovn-remote=ssl:w.x.y.z:6642
Acked-by: Ben Pfaff <blp@ovn.org>
Signed-off-by: Lance Richardson <lrichard@redhat.com>
Signed-off-by: Ben Pfaff <blp@ovn.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Enable operations (including "list") on DHCP_Options and DHCPv6_Options
tables via ovn-sbctl. These are currently the only OVN_Southbound
tables that ovn-sbctl does not support.
Example:
$ ovn-sbctl -f table list DHCPv6_Options
_uuid code name type
------------------------------------ ---- ------------- ------
8646bb15-5e88-4432-a21a-4e22a2976482 23 dns_server "ipv6"
564e98e9-ee23-447b-a7c5-c36ca05059fa 24 domain_search str
8c6cb059-5bb5-4ef8-960b-f002c769589e 2 server_id mac
525e8fc6-7921-48eb-8bd3-fe5cb5dd0142 5 ia_addr "ipv6"
Signed-off-by: Lance Richardson <lrichard@redhat.com>
Signed-off-by: Ben Pfaff <blp@ovn.org>
|
| |
|
|
|
|
|
|
|
|
|
| |
Sometimes seeing the OpenFlow flows that back a given logical flow can
provide additional insight. This commit adds a new --ovs option to
ovn-trace that makes it connect to Open vSwitch over OpenFlow and retrieve
and print the OpenFlow flows behind each logical flow encountered during
a trace.
Signed-off-by: Ben Pfaff <blp@ovn.org>
Acked-by: Justin Pettit <jpettit@ovn.org>
|
| |
|
|
|
|
|
|
|
|
|
| |
This makes it easy to find the logical flow that generated a particular
OpenFlow flow, by running "ovn-sbctl dump-flows <cookie>".
Later, this can be refined (and automated for "ofproto/trace"), but this
is still a significant advance.
Signed-off-by: Ben Pfaff <blp@ovn.org>
Acked-by: Justin Pettit <jpettit@ovn.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There are currently five users of the table formatting library,
all of which default to "list" except for ovsdb-client which
defaults to "table". The library current default is "table",
and the table.man man page fragment only considers ovs-vsctl
to use something other than "table" as a default.As a result,
the man pages for ovn-sbctl and vtep-ctl are currently incorrect
(these options aren't documented in the ovn-nbctl man page, which
will need to be addressed in a future patch).
Fix by making the library default format "list" and handling
ovsdb-client as the exception.
Signed-off-by: Lance Richardson <lrichard@redhat.com>
Signed-off-by: Ben Pfaff <blp@ovn.org>
|
| |
|
|
|
| |
Signed-off-by: Justin Pettit <jpettit@ovn.org>
Acked-by: Ben Pfaff <blp@ovn.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently the ovn-northd monitor process and the ovn-northd process
have the same name, e.g. ps -ef | grep northd shows (edited for space):
... ovn-northd --detach --monitor --log-file=ovn-northd.log --pidfile
... ovn-northd --detach --monitor --log-file=ovn-northd.log --pidfile
With the call to ovs_cmdl_proctitle_init() added, we have:
... ovn-northd: monitoring pid 15662 (healthy)
... ovn-northd --detach --monitor --log-file=ovn-northd.log --pidfile
Signed-off-by: Lance Richardson <lrichard@redhat.com>
Signed-off-by: Ben Pfaff <blp@ovn.org>
|
| |
|
|
|
|
|
|
|
| |
Add support for managing remote connections, including
SSL configuration, to southbound db schema, and add necessary
commands to ovn-sbctl.
Signed-off-by: Lance Richardson <lrichard@redhat.com>
Signed-off-by: Ben Pfaff <blp@ovn.org>
|
| |
|
|
|
|
|
|
|
| |
Add support for managing remote connections, including
SSL configuration, to northbound db schema, and add necessary
commands to ovn-nbctl.
Signed-off-by: Lance Richardson <lrichard@redhat.com>
Signed-off-by: Ben Pfaff <blp@ovn.org>
|
| |
|
|
|
|
|
|
|
|
|
|
| |
In commit 475f0a2c it introduced a priority 150 flow for filtering
the sending of traffic received from vxlan tunnels back out tunnels.
However, it added the flow for every remote port processing, which
results in continuous logs about duplicated flows. We only need to
install this flow once per physical_run() loop iteration.
Signed-off-by: Han Zhou <zhouhan@gmail.com>
Acked-by: Darrell Ball <dball@vmware.com>
Signed-off-by: Ben Pfaff <blp@ovn.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
With recent OVN commits, the logic for a chassis to claim
or release a logical port was consolidated. This is a
good thing. However, there was a logic change that
resulted in VLOG_INFO being generated every time on the
ovn-controller. This patch changes the logic so that
VLOG_INFO is only generated when there is a change, for
example when the chassis claims an lport the first time.
Signed-off-by: Mickey Spiegel <mickeys.dev@gmail.com>
Signed-off-by: Ben Pfaff <blp@ovn.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The gateway router was using the ct_next action to
reassemble packets. But ct_next action by default would
use the zone allocated for a logical port and in case of
gateway routers that value was zero. This would make
the flow use the default zone of zero. This had some
unintended consequences as the zone used to track packets
and the zone used to eventually commit it (DNAT zone)
was different. As a result, a packet would never have ct.est set.
With this commit, when ct_next action is used in a gateway
router, we use the DNAT zone. This is similar to the
strategy used in commit c2e954a117a8 (ovn-controller: Datapath
based conntrack zone for load-balancing.)
Signed-off-by: Gurucharan Shetty <guru@ovn.org>
Acked-by: Ben Pfaff <blp@ovn.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Until now, ovn-controller has replicated all of the southbound database
(through the IDL). This is inefficient, especially in a large OVN setup
where many logical networks are not present on an individual hypervisor.
This commit improves on the situation somewhat, by making ovn-controller
replicate (almost) only the port bindings, logical flows, and multicast
groups that are actually relevant to the particular hypervisor on which
ovn-controller is running. This is easily possible by replicating the
patch ports from the Port_Binding table and using these relationships to
determine connections between datapaths.
This patch is strongly influenced by earlier work from the CCed developers.
I am grateful for their assistance.
CC: Darrell Ball <dlu998@gmail.com>
CC: Liran Schour <LIRANS@il.ibm.com>
Signed-off-by: Ben Pfaff <blp@ovn.org>
Acked-by: Liran Schour <lirans@il.ibm.com>
Acked-by: Mickey Spiegel <mickeys.dev@gmail.com>
|
| |
|
|
|
|
|
|
|
| |
This sset has always just contained the names of logical ports that are
local to the current hypervisor, but the name 'all_lports' implied that it
contained the name of every logical port.
Signed-off-by: Ben Pfaff <blp@ovn.org>
Acked-by: Mickey Spiegel <mickeys.dev@gmail.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Until now, ovn-controller has implemented OVN logical patch ports and
l3gateway ports in terms of OVS patch ports. It is a hassle to create and
destroy ports, and it is also wasteful compared to what the patch ports
actually buy us: the ability to "save and restore" a packet around a
recursive trip through the flow table. The "clone" action can do that too,
without the need to create a port. This commit takes advantage of the
clone action for that purpose, getting rid of most of the patch ports
previously created by ovn-controller.
Signed-off-by: Ben Pfaff <blp@ovn.org>
Acked-by: Mickey Spiegel <mickeys.dev@gmail.com>
|
| |
|
|
|
| |
Signed-off-by: Ben Pfaff <blp@ovn.org>
Acked-by: Mickey Spiegel <mickeys.dev@gmail.com>
|
| |
|
|
|
|
|
| |
These functions will have an additional user in an upcoming commit.
Signed-off-by: Ben Pfaff <blp@ovn.org>
Acked-by: Mickey Spiegel <mickeys.dev@gmail.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
On a particular hypervisor, ovn-controller only needs to handle ports
and datapaths that have some relationship with it, that is, the
ports that actually reside on the hypervisor, plus all the other ports on
those ports' datapaths, plus all of the ports and datapaths that are
reachable from those via logical patch ports. Until now, ovn-controller
has done a poor job of limiting what it deals with to this set. This
commit improves the situation.
This commit gets rid of the concept of a "patched_datapath" which until now
was used to represent any datapath that contained a logical patch port.
Previously, the concept of a "local_datapath" meant a datapath with a VIF
that resides on the local hypervisor. This commit extends that concept to
include any other datapath that can be reached from a VIF on the local
hypervisor, which is a simplification that makes the code easier to
understand in a few places.
CC: Gurucharan Shetty <guru@ovn.org>
Signed-off-by: Ben Pfaff <blp@ovn.org>
Acked-by: Mickey Spiegel <mickeys.dev@gmail.com>
|
| |
|
|
|
|
|
| |
This will have its first real user in an upcoming commit.
Signed-off-by: Ben Pfaff <blp@ovn.org>
Acked-by: Mickey Spiegel <mickeys.dev@gmail.com>
|
| |
|
|
|
|
|
|
|
| |
The coding style says to do this.
The actual caller doesn't pass a null pointer.
Signed-off-by: Ben Pfaff <blp@ovn.org>
Acked-by: Mickey Spiegel <mickeys.dev@gmail.com>
|
| |
|
|
|
|
|
|
|
| |
It seems like a good idea to check for and warn about all kinds of
duplicates, and to avoid segfaulting if a datapath column is empty.
(However, the database schema should prevent both issues.)
Signed-off-by: Ben Pfaff <blp@ovn.org>
Acked-by: Mickey Spiegel <mickeys.dev@gmail.com>
|
| |
|
|
|
|
|
| |
This will allow binding_run() to use them in an upcoming commit.
Signed-off-by: Ben Pfaff <blp@ovn.org>
Acked-by: Mickey Spiegel <mickeys.dev@gmail.com>
|
