With this patch, instead of updating an interface's link_state once
every 5 seconds, it's updated immediately when changed. To avoid
stressing the database, these updates are rate limited to once per
second.
In some cases, a controller may want to take an interface down for
forwarding purposes, but avoid completely deconfiguring CFM and
thus lose all connectivity monitoring. The new 'cfm_opstate'
setting is a way to achieve this behavior.
When an Interface record is invalid (for example, when the interface that
it specifies does not exist and cannot be created), ovs-vswitchd would
leave any pre-existing data in its columns, except that it would set the
ofport column to -1 to indicate the error. This was sometimes confusing
because, for example, the lacp_current field could still be set to "true"
if LACP has previously been active and up-to-date.
This commit changes ovs-vswitchd to reset all such data to its default
values when an interface is invalid.
Bug #7450.
Reported-by: Duffie Cooley <dcooley@nicira.com>
Bug #7491.
Reported-by: Ethan Jackson <ethan@nicira.com>
Release Notes #7500.
Reported-by: Keith Amidon <keith@nicira.com>
Synthetic interfaces don't have database records so it doesn't make
sense to update them. In some situations this could cause a
segmentation fault.
Reported-by: Paul Ingram <paul@nicira.com>
Bug #7278.
There is no need to have vport attribute MTU (OVS_VPORT_ATTR_MTU) as
linux net-dev-ioctl can be used to get/set MTU for linux device.
Following patch removes OVS_VPORT_ATTR_MTU from datapath protocol.
This patch also adds netdev_set_mtu interface. So that MTU adjustments
can be done from OVS userspace. get_mtu() interface is also changed, now
get_mtu() returns EOPNOTSUPP rather than returning 0 and setting *pmtu
to INT_MAX in case there is no MTU attribute for given device.
Signed-off-by: Pravin B Shelar <pshelar@nicira.com>
Acked-by: Jesse Gross <jesse@nicira.com>
Commit 3a48ace3 "bridge: Make bridge_pick_local_hw_addr() easier to reason"
didn't initialize 'ea' before trying to compare against it. We need to
check that an address has been found.
Found by valgrind.
A controller may want to know which MPIDs are reachable from an
interface configured with CFM. This patch regularly writes this
information to the database.
Bug #7014.
The new extended mode introduced in this patch will be used for
features which break wire compatibility with 802.1ag compliant
implementations.
Bug #7014.
According to the 802.1ag specification, users should be able to
configure the CFM module with a list of remote endpoints with which
the local endpoint should have connectivity. Commit 93b8df3853
"cfm: Remove Maintenance_Point and Monitor tables." changed the
behavior so that only one remote endpoint could be specified. This
commit takes it further, by disallowing specification of any
remote endpoints.
Due to this change, the semantics of the fault flag are slightly
different. Before, a fault was triggered if any of the configured
remote endpoints were unreachable (or with RDI), or if any
unconfigured remote endpoints were reachable. Now a fault is
triggered if no remote endpoints are reachable at all, or if
reachable endpoints have set their RDI.
Bug #7014.
This patch no longer rate limits database updates due to CFM
changes. Due to recent changes, the fault status of CFM only
changes once per 3.5 tx_interval seconds. There doesn't seem to be
a good reason to add an additional rate limit on top of this.
The use of eth_addr_is_multicast() to see if a reasonable address was
found always caused me momentary confusion. This commit uses a flag
instead, and also saves a bit of unnecessary array reading and writing.
Currently, a NORMAL action bridge drops reserved-multicast-mac addresses;
01-80-c2-00-00-[f0:ff]. A node that does not implement STP should have an
option to forward such frames.
This commit proposes to have a configuration option to allow forwarding of
BPDU class frames. To ensure backward compatibility, this option is
disabled by default.
This config can be set using bridge's other-config column, for e.g
ovs-vsctl set bridge br0 other-config:forward-bpdu=true
Changing this option can revalidate all flows in a software-OVS
implementation (ofproto-dpif)
--------
unit tests:
------------
make config changes, test runtime behavior
-- test runtime behavior --
continuously send packets to br0 with dest-mac=01:80:c2:00:00:00
ovs-dpctl dump-flows br0
ovs-vsctl set bridge br0 other-config:forward-bpdu=true
ovs-dpctl dump-flows br0
ovs-vsctl set bridge br0 other-config:forward-bpdu=false
ovs-dpctl dump-flows br0
ovs-vsctl set bridge br0 other-config:forward-bpdu=true
ovs-dpctl dump-flows br0
ovs-vsctl remove bridge br0 other-config forward-bpdu=true
ovs-dpctl dump-flows br0
--result--
ovs-dpctl dump-flows br0
in_port(1),eth(src=00:0c:29:d1:39:42,dst=01:80:c2:00:00:00), packets:29550, bytes:1773000, used:0.004s, actions:drop
ovs-vsctl set bridge br0 other-config:forward-bpdu=true
ovs-dpctl dump-flows br0
in_port(1),eth(src=00:0c:29:d1:39:42,dst=01:80:c2:00:00:00), packets:8209, bytes:492540, used:0.000s, actions:2,0
ovs-vsctl set bridge br0 other-config:forward-bpdu=false
ovs-dpctl dump-flows br0
in_port(1),eth(src=00:0c:29:d1:39:42,dst=01:80:c2:00:00:00), packets:19, bytes:1140, used:0.000s, actions:drop
ovs-vsctl set bridge br0 other-config:forward-bpdu=true
ovs-dpctl dump-flows br0
in_port(1),eth(src=00:0c:29:d1:39:42,dst=01:80:c2:00:00:00), packets:29, bytes:1740, used:0.000s, actions:2,0
ovs-vsctl remove bridge br0 other-config forward-bpdu=true
ovs-dpctl dump-flows br0
in_port(1),eth(src=00:0c:29:d1:39:42,dst=01:80:c2:00:00:00), packets:0, bytes:0, used:never, actions:drop
Bug #6624
Reported-by: Niklas Andersson <nandersson@nicira.com>
Until now, each call to netdev_open() for a particular network device
had to either specify a set of network device arguments that was either
empty or (for devices that already existed) equal to the existing device's
configuration. Unfortunately, the definition of "equality" in the latter
case was mostly done in terms of strict equality of string-to-string maps,
which caused problems in cases where, for example, one set of arguments
specified the default value of an optional argument explicitly and the
other omitted it.
The netdev interface does have provisions for defining equality other ways,
but this had only been done in one case that was especially problematic in
practice. One way to solve this particular problem would be to carefully
define equality in all the problematic cases.
This commit takes another approach based on the realization that there is
really no need to do any comparisons. Instead, it removes configuration
at netdev_open() time entirely, because almost all of netdev_open()'s
callers are not interested in creating and configuring a netdev. Most of
them just want to open a configured device and use it. Therefore, this
commit stops providing any configuration arguments to netdev_open() and the
provider functions that it calls. Instead, a caller that does want to
configure a device does so after it opens it, by calling
netdev_set_config().
This change allows us to simplify the netdev interface a bit. There is no
longer any need to implement argument comparisons. As a result, there is
also no need for "struct netdev_dev" to keep track of configuration at all.
Instead, the network devices that have configuration keep track of it in
their own internal form.
This new interface does mean that it becomes possible to accidentally
create and try to use an unconfigured netdev that requires configuration.
Bug #6677.
Reported-by: Paul Ingram <paul@nicira.com>
The Open vSwitch tree only has one user of the ability for a netdev to
receive packets from a network device. Thus, this commit simplifies the
common-case use of the netdev interface by replacing the "ethertype" option
from "struct netdev_options" by a new netdev_listen() call.
The only user of netdev_listen() wants to receive all packets from a
network device, so this commit also removes the ability to restrict the
received packets to a particular protocol. (This ability was once used by
the Open vSwitch integrated DHCP client, but that code has been removed.)
This commit also simplifies and improves the implementation of the code
in netdev-linux that started listening to a network device. Before, I had
not figured out how to avoid receiving all packets on all devices before
binding to a particular device, but I took a closer look at the kernel code
and figured it out.
I've tested that the userspace datapath (dpif-netdev), the only user of
netdev_recv(), still works after this change.
Virtual ports such as GRE tunnels don't exist until after the port is
added to the datapath, so without this change adding such a port yields
a warning like the following:
netdev|WARN|failed to retrieve MTU for network device gre0: No such device
vswitchd/INTERNALS explains the incompatibility:
2. When Open vSwitch forwards a multicast or broadcast packet to a
link in the SLB bond other than the active slave, the remote
switch will forward it to all of the other links in the SLB
bond, including the active slave. Without special handling,
this would mean that Open vSwitch would forward a second copy of
the packet to each switch port (other than the bond), including
the port that originated the packet.
Open vSwitch deals with this case by dropping packets received
on any SLB bonded link that have a source MAC+VLAN that has been
learned on any other port. (This means that SLB as implemented
in Open vSwitch relies critically on MAC learning. Notably, SLB
is incompatible with the "flood_vlans" feature.)
We could go farther than this and automatically change the bonding mode to
a safer one (e.g. active-backup) when flood_vlans are enabled. However,
that would still leave the SLB fallback for LACP modes in place; perhaps
active-backup would have to be the fallback for LACP modes when flood_vlans
are enabled.
Allow setting the number of flows present in the flow hash
at which point eviction of entries from the kernel flow hash
will begin to occur.
The value may be set using a bridge's other-config column.
e.g.
ovs-vsctl set bridge br3 other-config:flow-eviction-threshold=10000
default is 1000, reflecting constant value previously used.
Increasing this value can result in reduced CPU usage and
packet loss in situations where the number of active flows
is significantly larger than 1000.
Once in a while someone reports a problem caused by running multiple
ovs-vswitchd processes at the same time. This fixes the problem by
requiring ovs-vswitchd to obtain a database lock before taking any actions.
Queue 0 is documented as the "default queue" used when a packet is not
directed to any specific queue. Many qdiscs drop packets not directed to a
queue if the default queue is not configured. This is therefore likely to
be a misconfiguration, so warn about it.
Bug #5583.
Updates to status-related columns in the Controller table can be lost if there
are multiple bridges with different sets of controllers. This commit fixes this
behavior by first accumulating status for all controllers on all bridges, then
making one pass over all rows in the Controller tables, updating the status of
each.
Bug #6185.
Reported-by: Michael Hu <mhu@nicira.com>
If the netdev_open() fails then iface->netdev will be NULL and
iface_refresh_stats() will cause a null pointer dereference in
netdev_get_stats().
Fixes a problem introduced by commit 1101a0b47 "bridge: Populate interface
status/statistics as soon as a port is added."
Reported-by: Aaron Rosen <arosen@clemson.edu>
Currently there's a lag of up to five seconds before the status and statistics
columns in the Interface table are populated when a port is first added to a
bridge. This may confuse systems that expect those columns to be populated
right away.
Bug #6145.
Most hypervisors have no use for this column, so populating it just wastes
CPU time. It can still be enabled explicitly via other-config.
CC: Peter Balland <peter@nicira.com>
CC: David Tsai <dtsai@nicira.com>
Bug #5961.
NIC-397.
This pointer arithmetic caused a warning on sparc. One alternative would
be to add a cast through "void *", but it seems at least as reasonable to
just use a few macros to do direct assignments.
In an effort to make CFM easier to understand and configure, this
patch removes the Maintenance_Point and Monitor tables from the
database. As a consequence, users will only be able to configure
one remote maintenance point. Furthermore, before this patch each
remote maintenance point maintained its own separate fault flag in
the database. This flag is no longer reported, users will need to
infer the fault status from the global CFM fault flag.
These settings added complexity to the database and CFM module
interface with negligible benefit. This patch removes them in such
a way that they can easily be re-added in the (unlikely) event that
we need them in the future.
This patch moves the cfm/show unixctl show command from the bridge
to the CFM module. This is more in line with how LACP does it, and
will make future patches easier to implement.
This patch moves miimon logic from the bond module to netdev-linux.
This greatly simplifies the bonding code while adding minimal
complexity to netdev-linux. The bonding code is so high level, it
really has no business worrying about how precisely slave status is
determined.
I know already that this breaks the statsfixes that were implemented by the
following commits:
827ab71c97f "ofproto: Datapath statistics accounted twice."
6f1435fc8f7 "ofproto: Resubmit statistics improperly account during..."
These were already broken in a previous merge. I will work on a fix.
The recent merge of "master" added a new bond_stable_ids member to
struct ofproto_bundle_settings, but neglected to initialize it. This fixes
the problem.
Found and verified using valgrind.
In some circumstances the bridge can't find a stable physical Ethernet
address to use, so until now it has just picked a random Ethernet address.
In these circumstances, therefore, the bridge Ethernet address would change
from one ovs-vswitchd run to another. But OVS does have a stable
identifier for a bridge: its UUID. This commit changes to use that as the
default bridge Ethernet address.
The datapath ID is sometimes derived from the bridge Ethernet address, so
this change also makes the bridge Ethernet address more stable.
CC: Natasha Gude <natasha@nicira.com>
Bug #5594.
