An OpenFlow controller is normally associated with a bridge. It was
possible to define a default controller in the Open_vSwitch table that
would be used if one was not associated with a bridge. This was seldom
used and mostly just caused confusion. This commit removes that
support, so an OpenFlow controller must always be associated with a
bridge.
Add an argument to the function to create a learning switch, which
defines default flows to be pushed down to connecting switches. It does
nothing to enforce that they remain intact. It only pushes flows on
switch connection.
An upcoming commit will add the ability to load OpenFlow rules into
ovs-controller. Break out string-to-openflow parsing so that
ovs-ofctl and ovs-controller can use the same code.
Until now, the collection of vlog modules supported by a given OVS program
was not specific to that program. That means that, for example, even
though ovs-dpctl does not have anything to do with jsonrpc, it still has
a vlog module for it. This is confusing, at best.
This commit fixes the problem on some systems, in particular on ones that
use GCC and the GNU linker. It uses the feature of the GNU linker
described in its manual as:
If an orphaned section's name is representable as a C identifier then
the linker will automatically see PROVIDE two symbols: __start_SECNAME
and __end_SECNAME, where SECNAME is the name of the section. These
indicate the start address and end address of the orphaned section
respectively.
Systems that don't support these features retain the earlier behavior.
This commit also fixes the annoyance that modifying lib/vlog-modules.def
causes all sources files that #include "vlog.h" to recompile.
Adding a macro to define the vlog module in use adds a level of
indirection, which makes it easier to change how the vlog module must be
defined. A followup commit needs to do that, so getting these widespread
changes out of the way first should make that commit easier to review.
Since the timeval module now initializes itself on-demand, there is no
longer any need to initialize it explicitly, or to provide an interface to
do so.
Before, ovs-controller always sent packets using OFPAT_OUTPUT, which always
uses the default OpenFlow queue. To help me debug the Open vSwitch QoS
implementation, I want to be able to send packets on other queues, so
this commit adds that feature.
The compiler pointed out two variables that it thought were used
without being initialized. The first was just a spurious warning
but the second could result in an unitialized pointer being freed.
This fixes both of those issues.
It's pretty risky to allow record names to be abbreviated. If eth1 through
eth20 all exist, and then someone deletes eth1, then until now an ovs-vsctl
command that mentioned eth1 would actually use eth10. This is too much of
a caveat to let loose on unsuspecting scripts, so this commit removes that
functionality.
The existing ovsdb_idl_txn_read() was somewhat difficult and expensive to
use, because it always made a copy of the data in the column. This was
necessary at the time it was introduced, because there was no way for it
to return a "default" value for columns that had not yet been populated
without allocating data and hence requiring the caller to free it.
Now that ovsdb_datum_default() exists, this is no longer required. This
commit introduces a pair of new functions, ovsdb_idl_read() and
ovsdb_idl_get(), that return a pointer to existing data and do not do any
copying. It also transitions all of ovsdb_idl_txn_read()'s callers to
the new interfaces.
Without this setting, the certificate authorities that ovs-pki creates will
not allow two switches or two controllers to have the same name. This
causes problem in testing, since it's often convenient to test with short,
common names like "tmp".
(If you need to fix a PKI that you already created, in addition to
modifying ca.cnf you will need to make the same change to index.txt.attr.)
CC: Pierre Ettori <pettori@nicira.com>
The wait-until command to be added to ovs-vsctl in an upcoming commit
doesn't really want to wait for partial matches: if I'm waiting for br1
to be created I really don't want to be fooled by br10. So this commit
adds infrastructure to avoid such partial matches.
The wait-until command to be added in an upcoming commit needs to support
!=, <, >, <=, and >= operators in addition to =, so this commit adds that
infrastructure.
The "wait-until" command to be introduced in an upcoming commit needs to
be able to tell the ovs-vsctl main loop to try again later, since the
condition that it is looking for has not yet been satisfied. This commit
adds the infrastructure for this. (It's being broken out into a separate
commit because it modifies scattered code in ovs-vsctl.c and thus might
be easier to review this way.)
ovs-vswitchd doesn't declare its QoS capabilities in the database yet,
so the controller has to know what they are. We can add that later.
The linux-htb QoS class has been tested to the extent that I can see that
it sets up the queues I expect when I run "tc qdisc show" and "tc class
show". I haven't tested that the effects on flows are what we expect them
to be. I am sure that there will be problems in that area that we will
have to fix.
The main purpose of the vconn code is to ship OpenFlow messages across
network connections. Over time a large number of utility functions related
to OpenFlow messages have also crept into vconn.c, but that's really
logically separate. This commit breaks those functions out into a new
file.
This makes it easy to create a bunch of records that are all related to
each other in a single ovs-vsctl invocation. It adds an example to the
ovs-vsctl manpage.
When the "create" command is used, post_create() calls
ovsdb_idl_txn_get_insert_uuid(), which asserts that the transaction
completed successfully. This makes it clear that postprocess functions
should only run when the transaction completes successfully. (Currently
post_create() is the only postprocess function.)
Until now, log messages about OpenFlow connections have named the target
of the connection, e.g. "tcp:1.2.3.4:5555", but they have not named the
datapath. Most often, every datapath has the same target, so this can
make it difficult to tell which connection is going wrong. Usually, that
isn't important, because all connections with the same target will have the
same problems, but it's probably better to be more informative.
This commit changes the log messages to include the datapath name, so that
"tcp:1.2.3.4:5555" becomes, e.g., "xenbr0<->tcp:1.2.3.4:5555".
Requested-by: Keith Amidon <keith@nicira.com>
The 'name' argument to these functions is actively unhelpful, because none
of the callers provided a better name than the one provided by
vconn_get_name(). So drop it.
The most recent revision of the netdev library added may_create
and may_open flags to explicitly state the intent of the caller as
to whether the device should already be in use. This was simply
a sanity check for users of the netdev library and the configuration.
At this point the netdev library and its users are well behaved and
should no longer need to be checked. Additional checks have also
been added for incorrect configuration that mean the netdev library
is no longer the primary line of defense.
These flags themselves create problems because it is not always
easy for a library to know what the state of devices should be.
This is particularly a problem for ovs-openflowd, which expects
ports to be added by ovs-dpctl. Fixing this either requires that
the checks are so permissive to be useless or ugly hacks to get
around them. Since they are no longer needed, just remove the
checks.
This commit restores the previous behavior of ovs-openflowd to
not require that ports be specified on the command line or
cleaned up after use.
Bug #2652
CC: Natasha Gude <natasha@nicira.com>
CC: Jean Tourrilhes <jt@hpl.hp.com>
CC: 蒲彦 <yan.p.bjtu@gmail.com>
This makes "ovs-ofctl snoop" and anything else that connects to the
switch's "snoop" socket typically more useful in the presence of multiple
controllers, since the "master" connection is the one with the most
interesting traffic.
Suggested-by: Justin Pettit <jpettit@nicira.com>
The "snoop" command does roughly the same thing as "monitor", but it is
easier to use in the common case where one just wants to look at the
OpenFlow controller connection for a bridge. Instead of, for example,
ovs-ofctl monitor unix:/var/run/openvswitch/br0.snoop
one merely types
ovs-ofctl snoop br0
Add the "emer-reset" command, which is used to clear the configuration of
items likely to have been configured by the manager. This will leave
the core networking configuration as it was.
With this commit, Open vSwitch permits a bridge to have any number of
OpenFlow controllers. When multiple controllers are configured, Open
vSwitch connects to all of them simultaneously. Details of configuration
are in the vswitch schema documentation.
OpenFlow 1.0 does not specify how multiple controllers coordinate in
interacting with a single switch, so more than one controller should be
specified only if the controllers are themselves designed to coordinate
with each other.
An upcoming commit will provide a simple means for coordination between
multiple controllers.
Feature #2495.
Many ofproto settings are controller-related. Upcoming commits will add
to ofproto the ability to support multiple controllers, so it is important
to be able to refer to controller settings as a group. Hence, this commit
bundles them into a new "struct ofproto_controller".
Add a tun_id field which contains the ID of the encapsulating tunnel
on which a packet was received (0 if not received on a tunnel). Also
add an action which allows the tunnel ID to be set for outgoing
packets. At this point there aren't any tunnel implementations so
these fields don't have any effect.
The matching is exposed to OpenFlow by overloading the high 32 bits
of the cookie as the tunnel ID. ovs-ofctl is capable of turning
on this special behavior using a new "tun-cookie" command but this
command is intentially undocumented to avoid it being used without
a full understanding of the consequences.
