For some time now, Open vSwitch datapaths have internally made a
distinction between adding a vport and attaching it to a datapath. Adding
a vport just means to create it, as an entity detached from any datapath.
Attaching it gives it a port number and a datapath. Similarly, a vport
could be detached and deleted separately.
After some study, I think I understand why this distinction exists. It is
because ovs-vswitchd tries to open all the datapath ports before it tries
to create them. However, changing it to create them before it tries to
open them is not difficult, so this commit does this.
The bulk of this commit, however, changes the datapath interface to one
that always creates a vport and attaches it to a datapath in a single step,
and similarly detaches a vport and deletes it in a single step.
Signed-off-by: Ben Pfaff <blp@nicira.com>
Acked-by: Jesse Gross <jesse@nicira.com>
Until now, the collection of coverage counters 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 mac_learning, it
still has a coverage counter 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 files that include coverage
counters must be listed on COVERAGE_FILES in lib/automake.mk.
This commit also fixes the annoyance that modifying any source file that
includes a coverage counter caused all programs that link against
libopenvswitch.a to relink, even programs that the source file was not
linked into. For example, modifying ofproto/ofproto.c (which includes
coverage counters) caused tests/test-aes128 to relink, even though
test-aes128 does not link again ofproto.o.
This makes it possible to run tests that need access to installation
directories, such as the rundir, without having access to the actual
installation directories (/var/run is generally not world-writable), by
setting environment variables. This is not a good way to do things in
general--usually it would be better to choose the correct directories
at configure time--so for now this is undocumented.
This commit implements a subset of the 802.1ag specification for
Connectivity Fault Management (CFM) using Continuity Check Messages
(CCM). When CFM is configured on an interface CCMs are broadcast
at regular intervals to detect missing or unexpected connectivity.
Since the Nicira Extended Match was specified nicira-ext.h has claimed that
arbitrary masks are allowed, but in fact only certain masks were actually
implemented. This commit implements general masking for the 802.1Q VLAN
TCI field.
Until now, by default the IDL replicated all tables and all columns in the
database, and a few functions made it possible to avoid replicating
selected columns. This commit adds a mode in which nothing is replicated
by default and the client code is responsible for specifying each column
and table that it is interested in. The following commit adds a user for
this mode.
Until now, in-band control traffic has always gone to the default queue,
typically queue 0. It makes sense to be able to assing control traffic to
its own queue, so this commit enables that.
Bug #3653.
None of the existing callers of ofproto_add_flow() want an idle timeout,
but ofproto_add_flow() was giving them a 5-second timeout anyway. I don't
know how this worked properly--in-band will patiently add the flow back
every few seconds anyway, but the bridge doesn't do that.
Also add an explanatory comment to ofproto_add_flow().
I'm retaining the "managers" column in the Open_vSwitch table for now, but
I hope that applications transition to using "manager_options" eventually
so that we could drop it.
CC: Andrew Lambeth <wal@nicira.com>
CC: Jeremy Stribling <strib@nicira.com>
Currently netdev_get_carrier() returns both a carrier status and
an error code. However, usage of the error code was inconsistent:
most callers either ignored it or didn't perform their task if an
error occured, which prevented bond rebalancing. This makes the
handling consistent by translating an error into a down status in
the netdev library.
Bug #3959
Until now, when ovs-vswitchd dropped interfaces because of duplicate names,
it would not write -1 to the ofport column in the OVSDB record for the
interface, which made it appear that the interface was still active (if
it had been before). This commit fixes the problem.
This commit also sets ofport to -1 for interfaces that cannot be created
for other reasons.
In-band control is always enabled when a manager is configured. Some
applications wish to control all the flows within a bridge, and in-band
control can override that wish. Depending on how the network is
configured, this can lead to loops as the in-band control rules try to
learn where to send traffic.
This commit adds a "disable-in-band" key to the "other_config" column of
bridge tables. If set to "true", in-band will be disabled regardless of
manager or controller configuration.
There's no need to have a mask in this action, because both parts of the
TCI are part of the flow structure.
Signed-off-by: Ben Pfaff <blp@nicira.com>
Acked-by: Jesse Gross <jesse@nicira.com>
When bridge.c decides to flood a packet as the result of a "normal"
flow action, it now checks whether each port is configured to
receive flood packets.
Bug #3741
This allows eliminating padding from odp_flow_key, although actually doing
that is postponed until the next commit.
Signed-off-by: Ben Pfaff <blp@nicira.com>
Acked-by: Jesse Gross <jesse@nicira.com>
When userspace and the kernel were using the same structure for flows,
flow_t was a useful way to indicate that a structure was really a userspace
flow instead of a kernel one, but now it's better to just write "struct
flow" for consistency, since OVS doesn't use typedefs for structs
elsewhere.
Acked-by: Jesse Gross <jesse@nicira.com>
Jesse pointed out that port_changed_cb isn't a great interface. It's only
around because, earlier, we had a lousy interface for monitoring netdev
status, so that we needed to pass along information obtained by ofproto
into the bridge. But netdev_monitor is now sufficiently sophisticated that
the bridge can set up an independent netdev_monitor without any important
loss of efficiency. Since this makes the code cleaner, this commit does
so.
Until now, a command that removed and added ports in a single change to
the database, e.g.:
ovs-vsctl del-port br0 vif1.0 -- add-port br0 vif2.0
typically failed, because of this sequence of events:
1. Bridge code removes vif1.0 from br0.
2. Bridge code adds vif2.0 to br0.
3. ofproto_run() receives kernel notification that vif1.0 was deleted, so
it notifies the bridge by calling back to bridge_port_changed_ofhook_cb,
which sees that it has an interface with the specified port number, and
deletes it. Oops--this is where the problem occurs. For completeness:
4. ofproto_run() receives kernel notification that vif2.0 was added, so
it notifies the bridge by calling back to ,
which sees that it has no interface with the specified port number, and
does nothing.
This commit fixes the problem by making bridge_port_changed_ofhook_cb() not
care about ports being dropped. This is a corner case that we shouldn't
work too hard to care about, since it can only happen if an administrator
is meddling with datapaths using ovs-dpctl, and the consequences are simply
that packets directed to that device will take longer to be rerouted to
another device (it will take a while for the MAC learning table to time out
the entry). Basically, the admin gets what he deserves.
Thanks to Jesse Gross for identifying the problem.
Bug #3671.
The previous commit arranged to always open the netdev for bridge ports
within the loop that adds new ports to datapaths. So now the additional
attempt to open them within the following loop is superfluous and
presumably will always fail. This commit drops it and merges two
iterations through bridge ports into a single one, since the first is now
trivial.
Until now, if the type of a bridge port changed in the database, then
ovs-vswitchd would report an error and keep it the same type. This commit
changes the behavior to something more reasonable: the old datapath port is
deleted and replaced by a new datapath port of the correct type.
iface_cfg is also available as iface->cfg, so there's no benefit in also
passing it as a separate parameter.
Also, get rid of the one-liner reconfigure_iface() function that wasn't
helping with anything.
The main advantage of a sparse array over a hash table is that it can be
iterated in numerical order. But the OVS implementation of sparse arrays
is quite expensive in terms of memory: on a 32-bit system, a sparse array
with exactly 1 nonnull element has 512 bytes of overhead. In this case,
the sparse array's property of iteration in numerical order is not
important, so this commit converts it to a hash table to save memory.
Header caching speeds up sending tunneled traffic by bypassing the Linux
IP stack. This also causes it to bypass IPsec processing, which will
break connectivity. This commit disables header caching when IPsec is
enabled.
This is intended to provide controllers enough information to determine
whether a switch is overloaded or busted, to enable them to spread load
fairly across a group of switches.
Feature #2421.
CC: Peter Balland <peter@nicira.com>
All of these changes avoid using the same name for two local variables
within a same function. None of them are actual bugs as far as I can tell,
but any of them could be confusing to the casual reader.
The one in lib/ovsdb-idl.c is particularly brilliant: inner and outer
loops both using (different) variables named 'i'.
Found with GCC -Wshadow.
The current date in milliseconds since the epoch is ~1,282,841,552,000,
which is greater than LONG_MAX of 4,294,967,295 on 32-bit systems, so
no matter what was stored into bond_next_fake_iface_update, it would always
appear to be expired. It really needs to be a 64-bit number. (This was
just a typo really.)
Since XenServer 5.5 requires --fake-proc-net, this probably fixes an
important bug there.
Reported-by: Luiz Henrique Ozaki <luiz.ozaki@gmail.com>
Not replicating unneeded columns has some value in avoiding CPU time and
bandwidth to the database. In ovs-vswitchd, setting cur_cfg as write-only
also have great value in avoiding extra reconfiguration steps. When
ovs-vsctl is used in its default mode this essentially avoids half of the
reconfigurations that ovs-vswitchd currently does. What happens now is:
1. ovs-vsctl updates the database and increments next_cfg.
2. ovs-vswitchd notices the change to the database, reconfigures
itself, then increments cur_cfg to match next_cfg.
3. The database sends the change to cur_cfg back to ovs-vswitchd.
4. ovs-vswitchd reconfigures itself a second time.
By not replicating cur_cfg we avoid step 3 and save a whole reconfiguration
step.
Also, now that the database contains interface statistics, this avoids
reconfiguring every time that statistics are updated.
Commit e96a4d8035 "bridge: Feed flow stats into learning table." started
feeding flow statistics back into the learning table, but it did not
distinguish between flows with and flows without an action that outputs to
OFPP_NORMAL. Flows without such an action are not put into the learning
table initially, because bridge_normal_ofhook_cb() is not called for them,
but since that commit they have been put into the learning table when their
flows are reassessed.
This is inconsistent--flows without OFPP_NORMAL should either be learned
from all the time or never, not sometimes. I can see valid arguments both
ways, but since it was always my intention not to learn from such flows,
this commit disables learning from them.
Problem found by code inspection. I don't know of any observed bug that
this fixes.
Until now, the ovs-vswitchd main loop has refreshed keys and certificates
from their files only when the database changes. This works fine if new
keys and certificates are installed with new file names, because the update
to the database to point to the new files will cause them to be read. But
if the new keys and certificates are copied over the existing files, then
the delay until they are read is indefinite.
This commit fixes the problem by changing the SSL configuration so that it
is rechecked on every trip through the ovs-vswitchd main loop.
Bug #2921.
OpenSSL is picky about the order in which keys and certificates are
changed: you have to change the certificate first, then the key. It
doesn't document this, but deep in the source code, in a function that sets
a new certificate, it has this comment:
/* don't fail for a cert/key mismatch, just free
* current private key (when switching to a different
* cert & key, first this function should be used,
* then ssl_set_pkey */
Brilliant, guys, thanks a lot.
Bug #2921.
Don't act as a learning switch when the fail-mode is "secure" and no
controllers are defined. This allows the bridge to come up in a state
where it won't pass any traffic until a controller has told it to do so.
Configuration of the fail-mode was an attribute of the Controller table.
However, it makes more sense as an attribute of the Bridge table, since
the behavior defines what a bridge should do if it can't connect to
*any* controller. This commit makes the move.
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.
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.
A "feature" that ovs-vswitchd inherited from its previous form of
configuration is that every mirror has a name. Names are not necessarily
meaningful, and there is no reason that they should be unique. But the
existing implementation depends on them being unique within a given
bridge, and if they are not drops one of the duplicates.
This commit drops the uniqueness requirement. Instead, it distinguishes
mirrors based on UUID alone.
This commit does not drop the concept of names for mirrors. There is no
technical reason to retain them, but it is possible that users find them
useful for management reasons. The names appear in log messages related
to mirrors, which may make the messages easier to understand.
Bug #2416.
