Open vSwitch has never properly supported IEEE 802.1D Spanning Tree
Protocol (STP), but it has various bits and pieces that claim to support
it. This commit deletes them, to reduce the amount of dead code in the
tree. We can always reintroduce it later if it proves to be a good idea.
Bug #1175.
The kernel and user datapaths have code that assumes that 802.1Q headers
are used only inside Ethernet II frames, not inside SNAP-encapsulated
frames. But the kernel and user flow_extract() implementations would
interpret 802.1Q headers inside SNAP headers as being valid VLANs. This
would cause packet corruption if any VLAN-related actions were to be taken,
so change the two flow_extract() implementations only to accept 802.1Q as
an Ethernet II frame type, not as a SNAP-encoded frame type.
802.1Q-2005 says that this is correct anyhow:
Where the ISS instance used to transmit and receive tagged frames is
provided by a media access control method that can support Ethernet
Type encoding directly (e.g., is an IEEE 802.3 or IEEE 802.11 MAC) or
is media access method independent (e.g., 6.6), the TPID is Ethernet
Type encoded, i.e., is two octets in length and comprises solely the
assigned Ethernet Type value.
Where the ISS instance is provided by a media access method that
cannot directly support Ethernet Type encoding (e.g., is an IEEE
802.5 or FDDI MAC), the TPID is encoded according to the rule for
a Subnetwork Access Protocol (Clause 10 of IEEE Std 802) that
encapsulates Ethernet frames over LLC, and comprises the SNAP
header (AA-AA-03) followed by the SNAP PID (00-00-00) followed by
the two octets of the assigned Ethernet Type value.
All of the media that OVS handles supports Ethernet Type fields, so to me
that means that we don't have to handle 802.1Q-inside-SNAP.
On the other hand, we *do* have to handle SNAP-inside-802.1Q, because this
is actually allowed by the standards. So this commit also adds that
support.
I verified that, with this change, both SNAP and Ethernet packets are
properly recognized both with and without 802.1Q encapsulation.
I was a bit surprised to find out that Linux does not accept
SNAP-encapsulated IP frames on Ethernet.
Here's a summary of how frames are handled before and after this commit:
Common cases
------------
Ethernet
+------------+
1. |dst|src|TYPE|
+------------+
Ethernet LLC SNAP
+------------+ +--------+ +-----------+
2. |dst|src| len| |aa|aa|03| |000000|TYPE|
+------------+ +--------+ +-----------+
Ethernet 802.1Q
+------------+ +---------+
3. |dst|src|8100| |VLAN|TYPE|
+------------+ +---------+
Ethernet 802.1Q LLC SNAP
+------------+ +---------+ +--------+ +-----------+
4. |dst|src|8100| |VLAN| LEN| |aa|aa|03| |000000|TYPE|
+------------+ +---------+ +--------+ +-----------+
Unusual cases
-------------
Ethernet LLC SNAP 802.1Q
+------------+ +--------+ +-----------+ +---------+
5. |dst|src| len| |aa|aa|03| |000000|8100| |VLAN|TYPE|
+------------+ +--------+ +-----------+ +---------+
Ethernet LLC
+------------+ +--------+
6. |dst|src| len| |xx|xx|xx|
+------------+ +--------+
Ethernet LLC SNAP
+------------+ +--------+ +-----------+
7. |dst|src| len| |aa|aa|03| |xxxxxx|xxxx|
+------------+ +--------+ +-----------+
Ethernet 802.1Q LLC
+------------+ +---------+ +--------+
8. |dst|src|8100| |VLAN| LEN| |xx|xx|xx|
+------------+ +---------+ +--------+
Ethernet 802.1Q LLC SNAP
+------------+ +---------+ +--------+ +-----------+
9. |dst|src|8100| |VLAN| LEN| |aa|aa|03| |xxxxxx|xxxx|
+------------+ +---------+ +--------+ +-----------+
Behavior
--------
--------------- --------------- -------------------------------------
Before After
this commit this commit
dl_type dl_vlan dl_type dl_vlan Notes
------- ------- ------- ------- -------------------------------------
1. TYPE ffff TYPE ffff no change
2. TYPE ffff TYPE ffff no change
3. TYPE VLAN TYPE VLAN no change
4. LEN VLAN TYPE VLAN proposal fixes behavior
5. TYPE VLAN 8100 ffff 802.1Q says this is invalid framing
6. 05ff ffff 05ff ffff no change
7. 05ff ffff 05ff ffff no change
8. LEN VLAN 05ff VLAN proposal fixes behavior
9. LEN VLAN 05ff VLAN proposal fixes behavior
Signed-off-by: Ben Pfaff <blp@nicira.com>
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.
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.
It's more convenient if clients don't have to initialize modules
explicitly.
The most important part of this change is to initialize the default
log levels statically. Previously, by initializing log levels only
from vlog_init(), all the log levels appeared to be VLL_EMER (0) if
vlog_init() was accidentally not called at all. This was not intended
behavior, so this commit fixes it.
This commit also fixes up a few test programs whose tests accidentally
depended on this behavior, by making them explicitly turn off log
messages that were implicitly turned off before.
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.
This test tends to break when run with lcov profiling since the lcov
wrapper script can't synchronize access to profiling data across all the
ovs-vsctl instances running in parallel.
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 \" escape is not part of POSIX, but it is a common extension. The
dash shell's built-in "printf" implementation does not include this
extension, which caused the testsuite to be generated incorrectly if it
is used as the default shell (as it is on newer versions of Debian and
Ubuntu).
However, there's no reason to use a backslash here at all, so just omit
it.
These new functions are more forgiving than the corresponding functions
without "_unique". The goal is to be more tolerant of data provided by
IDL clients, which will happen in a followup patch.
Until now, "monitor" has only allowed the client to choose the kinds of
changes that will be monitored on a per-table basis. However, it makes
sense to be able to choose operations on a per-column basis. The
immediate need for this is to make sure that the final statistics of
deleted Interface records are known at time of deletion, even though the
intermediate values of the statistics are not important.
CC: Jeremy Stribling <strib@nicira.com>
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.
I noticed that when I run "make check" inside an Emacs compile-mode buffer,
the "daemon --detach closes standard fds" and "daemon --detach --monitor closes
standard fds" tests failed. Investigation showed that Emacs ignores
SIGPIPE in the compile subprocess, which caused the "yes" process in these
tests to emit the message "yes: Broken pipe" and exit with status 1 instead
of dying from SIGPIPE.
This commit changes these tests to allow either behavior.
While I was looking at the rconn code for connection backoff and retry, I
noticed that ovs-vswitchd was logging the following on each connection
attempt:
Jun 11 15:17:41|00020|vconn_stream|ERR|send: Connection refused
The "send:" part didn't make much sense. The configured controller was not
actually running, so the vconn code should not have been able to connect
at all, so the message should have been about a connection failing, not
about sending on a completed connection failing.
Investigation showed that different parts of the library have different
ideas about return value semantics. vconn_open() and stream_open() both
return 0 if a connection succeeded or if one is in progress, but some of
its callers thought that it returned 0 if the connection succeeded and
EAGAIN if the connection was in progress. This commit fixes up the callers
that had the wrong idea, by making them instead all vconn_connect() or
stream_connect() to determine whether the connection is complete.
Commit 97f7803 made this test nondeterministic: depending on the ordering
of the random row UUIDs, the error message might mention one of two
different nonexistent rows that are referenced. This commit fixes the
problem by accepting either one of the two correct rows.
Previous related fixes took a different approach, of instead making the
test deterministic. But now I think that that is not as good an idea,
because we need to be able to test that OVSDB works whether the query is
deterministic or not.
(Of course, every OVSDB test is nondeterministic, since the UUIDs are
random. This test was just more nondeterministic than most.)
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.
We now use a time source that provides nanosecond granularity.
However, our test uses gettimeofday() for comparision, which has
microsecond granularity. In some cases this can lead to different
values depending on the rounding. This allows us to be off by one
to prevent intermittent test failures.
Most of the timekeeping needs of OVS are simply to measure intervals,
which means that it is sensitive to changes in the clock. This commit
replaces the existing clocks with monotonic timers. An additional set
of wall clock timers are added and used in locations that need absolute
time.
Bug #1858
Many of the classifier tests take time exponential in the number of fields,
because the existing compare_classifiers() iterates over 2^n_fields
possibilities. This is very slow.
This commit fixes the problem by only testing a fixed number of random
possibilities instead of all of them. This makes it much, much faster.
The \x escape is not part of POSIX, but it is a common extension. The
dash shell's built-in "printf" implementation does not include this
extension, which caused the testsuite to be generated incorrectly if it
is used as the default shell (as it is on newer versions of Debian and
Ubuntu).
This commit fixes the problem by using standard octal escapes instead.
Reported-by: Joan Cirer <joan@ev0.net>
This patch fixed the following compile warning:
tests/test-ovsdb.c: In function 'do_evaluate_conditions':
tests/test-ovsdb.c:744: warning: format '%2d' expects type 'int', but argument 2 has type 'size_t'
tests/test-ovsdb.c: In function 'do_execute_mutations':
tests/test-ovsdb.c:850: warning: format '%2d' expects type 'int', but argument 2 has type 'size_t'
tests/test-ovsdb.c: In function 'do_query':
tests/test-ovsdb.c:972: warning: format '%2d' expects type 'int', but argument 2 has type 'size_t'
tests/test-ovsdb.c: In function 'do_query_distinct':
tests/test-ovsdb.c:1105: warning: format '%2d' expects type 'int', but argument 2 has type 'size_t'
tests/test-ovsdb.c: In function 'parse_uuids':
tests/test-ovsdb.c:1600: warning: format '%d' expects type 'int', but argument 2 has type 'size_t'
Signed-off-by: Wei Yongjun <yjwei@cn.fujitsu.com>
The "monitor" command goes to some trouble to write its output in a
predictable order, so that test programs can reliably compare it against
expectations. This commit fixes up one part that was missing, which is
that the columns were not being ordered predictably (it depended on
hash order, which differs between big-endian and little-endian systems).
It also updates the test suite to expect the new order.
This test examines the OVSDB database log and checks that it contains what
it should for specified transactions. However, the database log ordering
differs between big-endian and little-endian architectures because it is
written out in hash order. We don't want to incur the expense of always
sorting the log as we write it out, so instead this commit fixes the
problem by sorting the log as it reads it, using the "test-json" program.
One part of the "weak references" test inserts invalid all-zeros weak
references into two columns and expects to get an error message mentioning
one of them. Unfortunately the one that actually gets mentioned depends
on hash ordering and thus differs between big-endian and little-endian
machines. This commit fixes the problem by only putting an invalid
reference in a single column, instead of two of them.
The formatting of OVSDB syntax errors differed between big-endian and
little-endian systems, which caused the "database multiplexing
implementation" test to fail on SPARC. This commit fixes the problem by
always outputting JSON in syntax errors in deterministic (sorted) order.
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.
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.
This change makes it possible to separate opening a stream from blocking on
connection completion. This avoids some code redundancy in an upcoming
commit.
Otherwise bridges can end up with a generated MAC address using Nicira OID
which has an impact when using DHCP on that devices.
tests/interface-reconfigure.at updated by Ben Pfaff.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Signed-off-by: Ben Pfaff <blp@nicira.com>
Until now the names of the external_ids keys used for Bridge records have
implied that they are specific to XenServer, because they begin with "xs-".
They are more generic in intent, however, so this commit removes the "xs-"
prefix and explains them more generically.
This finishes the renaming process started in commit c0f9490 "vswitchd:
Make names of Interface external_ids generic."
CC: Ian Campbell <ian.campbell@citrix.com>
Signed-off-by: Ben Pfaff <blp@nicira.com>
ovsdb-server should be able to obtain its SSL configuration from the
database that it is serving out, instead of having to specify it on the
command line. This commit makes it so.
The trivial test classifier had the same bug as the real classifier
when replacing matching flows. This caused it to not find the
original bug and then break when the bug was fixed.
If the database grows fairly large, and we've written a fair number of
transactions to it, and it's been a while since the database was compacted,
then (after the next commit) compact the database.
Also, compact the database online if the "ovsdb-server/compact" command is
issued via unixctl. I suspect that this feature will rarely if ever be
used in practice, but it's easier to test than compacting automatically.
Bug #2391.
This variant of the ovsdb execution tests runs each transaction against a
separately started ovsdb-server. The idea is that this should help to
ferret out any differences between what ovsdb-server has in memory and what
actually gets committed to disk. There should not be any such differences,
but we need to test for that.
