Replaced all instances of Nicira Networks(, Inc) to Nicira, Inc.
Feature #10593
Signed-off-by: Raju Subramanian <rsubramanian@nicira.com>
Signed-off-by: Ben Pfaff <blp@nicira.com>
Most callers of mac_learning_flush() need to revalidate all flows
anyway, but this update forces new callers of mac_learning_flush()
to think about whether or not they need to explicitly handle
revalidation. Also, it's theoretically more efficient when there
are lots of flows but the learning table is empty, (e.g. bridges
that don't use the NORMAL action).
Signed-off-by: Ethan Jackson <ethan@nicira.com>
When a bit is set in flood_vlans, that VLAN must be flooded, but the logic
here was reversed in the case where there were any flooded VLANs at all.
Thus, if a single VLAN was configured to be flooded, all VLANs except that
one were actually flooded.
The common case where no VLANs were to be flooded was handled correctly.
Reported-by: David Tsai <dtsai@nicira.com>
The mac-learning implementation used a free list to keep track of
statically allocated table entries. This made the code slightly
more difficult to understand than the more straightforward heap
based strategy implemented by this patch.
The mac-learning 'secret' parameter is intended to prevent an
attacker from turning the mac learning table into a linked list by
using a known hash function to choose perfectly bad mac entries.
However, this parameter was not taken into account in most cases.
Found by inspection.
The mac-learning code predates the hmap data structure in OVS. For
this reason, it rolled it's own hmap-like bucket concept. This
patch converts it to use an hmap which makes the code slightly
simpler and easier to understand.
These new semantics are less efficient in the case where the flood_vlans
actually changed, but that should be very rare.
There are no advantages to this change on its own, but upcoming commits
will add multiple layers between the code supplying the flood_vlans and
actually calling mac_learning_set_flood_vlans(). Consistency in this
multilayered interface seems valuable, and the rest of it does not transfer
ownership from the caller to the callee.
In an upcoming commit I want to store a pointer in MAC learning entries
in the bridge, instead of an integer port number. The MAC learning library
has other clients, and the others do not gracefully fit this new model, so
in fact the data will have to become a union. However, this does not fit
well with the current mac_learning API, since mac_learning_learn()
currently initializes and compares the data. It seems better to break up
the API so that only the client has to know the data's format and how to
initialize it or compare it. This commit makes this possible.
This commit doesn't change the type of the data stored in a MAC learning
entry yet.
As a side effect this commit has the benefit that clients that don't need
gratuitous ARP locking don't have to specify any policy for it at all.
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.
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.
Normally we filter out packets received on a bond if we have
learned the source MAC as belonging to another port to avoid packets
sent on one slave and reflected back on another. The exception to
this is gratuitous ARPs because they indicate that the host
has moved to another port. However, this can result in an additional
problem on the switch that the host moved to if the gratuitous ARP is
reflected back on a bond slave. In this case, we incorrectly relearn
the slave as the source of the MAC address. To solve this, we lock the
learning entry for 5 seconds after receiving a gratuitous ARP against
further updates caused by gratuitous ARPs on bond slaves.
Bug #2516
Reported-by: Ian Campbell <ian.campbell@citrix.com>
RSPAN does not work properly unless MAC learning for the VLAN is
disabled on all switches between the origin and monitoring point.
This allows learning to be disabled on a given VLAN so vSwitch can
acts as an intermediate switch.
Feature #2136
The vswitchd bonding code needs to iterate through the table entries to
be able to send out gratuitous learning packets when bond slaves go down.
It might be best to create an abstract interface to the MAC learning table,
but this commit does the simpler thing and exposes the data structures in
the header file.
