At startup, the vswitch needs to delete datapaths that are not configured
by the administrator. Until now this was done by knowing the possible
names of Linux datapaths. This commit cleans up by allowing each
datapath class to enumerate its existing datapaths and their names.
Commit f4b96c92c "vswitch: Disallow bridges named "dpN" or "nl:N"" disabled
naming bridges "dpN" because the vswitchd code made the bad assumption that
the bridge's local port has the same name as the bridge, which was not
true (at the time) for bridges named dpN. Now that assumption has been
eliminated, so this commit eliminates the restriction too.
This change is also a cleanup in that it eliminates one form of the
vswitch's dependence on specifics of the dpif implementation.
Soon we will allow for multiple datapath implementations. By allowing
the datapath to choose the port numbers, we possibly simplify some datapath
implementations, and the datapath's clients don't have to guess (or to
check) what port numbers are free, so this seems like a better way to go.
dpif_id() is often used in error messages, e.g. "dp%u: screwed up". But
soon we will be generalizing the concept of a datapath, so it is better
to have a function that returns a full name, e.g. "%s: screwed up".
Accordingly, this commit replaces dpif_id() by a new function dpif_name()
that does so.
The 'minor' member of struct dpif is used for two different purposes:
for printing in log messages and for encapsulating in NetFlow messages.
The needs in each case are different, so we should break up these uses.
This commit does half of that, by introducing a new function to retrieve
NetFlow ids and using it where appropriate.
With multiple kinds of datapaths, code should not just use
"dp%u" along with dpif_minor() to print a datapath name, because not all
datapaths can sensibly be named that way. We want to use a function
with a name like dpif_get_name() to retrieve a datapath name for printing
to the user, in which case the existing dpif_get_name() function would be
confusing. So rename the existing one to something more explicit.
When vSwitch does discovery, it is supposed to update resolv.conf by
default. The way configuration parameters were being read, it would
disable this update by default.
In vSwitch, the minimum probe interval is supposed to be 5 seconds, but
that was not enforced. If no interval was specified in the config file,
a value of 0 was being used, which would cause probes to never be sent
and the rconn not to move out of its ACTIVE state.
Possible fix to Bug #1466.
If a user moves from one controller to another, we did not remove the
cacert. This prevents the switch from connecting to the new controller.
To ease confusion, we now delete the cacert when the user changes or
removes the controller in xsconsole.
Note: This commit has a minor security issue, since we do not remove
trust for the old certificate until the switch is restarted. In
general, users should only be connected to trusted servers, so the
impact should be low. Fixes this would require larger changes to the
vconn-ssl code, which we don't want to do so late in the release cycle.
Bug #1457
When a managment connection is configured and then removed, putting it
back causes the management connection to never be reestablished. The
management code checks whether the configuration file has changed before
it attempts to reconfigure itself. If the only thing that changed was
the lack of a management connection, then it tore down the connection
but didn't update its view of the configuration. When the same
manager IP is configured, the cached version matches the new version, so
no changes are made. This commit clears the cached version, so that a
removing and then adding the manager will be detected as a change.
Bug #1448
XenServer Tools version 5.0.0 destroys and recreates network devices with
the same name on boot of (at least) Windows VMs. We had a race such that
ovs-brcompatd would delete the new device from the vswitchd configuration
file (not the old one). This commit fixes that problem.
Bug #1429.
When we receive an OpenFlow management protocol Config Update, we
immediately force the switch to reconfigure itself. This is
functionally correct, but it can cause long delays before return control
back to the switch. We now keep track of whether there were any changes
and then only force a reconfigure once per management run.
The SHA-1 library that we used until now was taken from RFC 3174. That
library has no clearly free license statement, only a license on the text
of the RFC. This commit replaces this library with a modified version of
the code from the Apache Portable Runtime library from apr.apache.org,
which is licensed under the Apache 2.0 license, the same as the rest of
Open vSwitch.
The 'packet' argument to process_flow() is allowed to be null, but some of
the code was assuming that it was always non-null, which caused a segfault
while revalidating ARP flows.
Bug #1394.
The TCP and SSL vconn implementations had a lot of common code to make
and accept TCP connections, which this commit factors out into common
functions in socket-util.c.
Also adds the ability to bind ptcp and pssl vconns to a particular IP
address instead of the wildcard address.
The controller discovery code has always had the capability to whitelist
only certain types of controller locations. Until now, we have only taken
advantage of this when SSL is enabled (so that all OpenFlow connections are
authenticated with SSL if SSL is configured).
However, it occurs to me that making the section of connections entirely
unrestricted is too permissive. An attacker could make the vswitch connect
to an arbitrary Unix domain socket, for example. I don't have a
description of how this is an exploitable security vulnerability, but it
seems entirely too lax.
So: this commit changes the default to allowing only TCP connections to
controller in the non-SSL case.
OpenFlow uses a 16-bit field to describe the message length, which
limits messages to a maximum 65535 bytes. Some of the messages passed
by the management protocol may be larger than this, so a general
Extended Data message has been added to management protocol. It
encapsulates a single giant OpenFlow-like message, and breaks it into
however many vaild smaller ones are required.
When a resource update message is generated by vSwitch, it creates a
couple of svec objects that need to be explicitly destroyed. This
wasn't happening, so memory would leak after each resource update. This
commit properly destroys them after use.
As long as bonding has been implemented, the vswitch has refused to learn
from multicast packets that arrive on a bond slave if it has already
learned any other port for that source MAC, because it is likely that we
sent the packet out ourselves and are only now receiving a copy of it on
our active slave.
This is entirely correct, but it does not go far enough. In fact, the
bridge needs to entirely drop such packets. Otherwise, a host whose MAC
is assigned to a slave other than the active slave will receive a second
copy of multicast packets that it sends out the bond, and other ports
will receive two copies of every multicast packet sent by such a host.
This commit implements this new policy, which simplifies the code at the
same time.
Bug #1387.
The man page for ovs-vswitchd.conf explains how ingress policing works.
However, what "ingress" means is a bit confusing depending on the
perspective. For vSwitch, it's from the switch's perspective. This
means on a PIF, it's the rate traffic comes into the box. On a VIF,
it's the rate traffic can be *transmitted* from a VM. This commit
clarifies the man page a bit.
Thanks to Johan for pointing out the problem.
The controller needs to know various things about virtual interfaces as
they move about the network. This commit sends the VIF, virtual
machine, and network UUIDs associated with the VIF, as well as its MAC
address over the management channel.
Feature #1324
When a bond slave goes down, all of the MACs that were on it are migrated
to another slave, but this is not apparent to the switch that the bond is
connected to until each MAC sends out a packet. This causes incoming
traffic for a given MAC to be dropped until the MAC sends out a packet.
This is not usually a problem, because traffic is not ordinarily one-way,
and we can't avoid losing some packets in some cases, but we can do a
little better by sending out a gratuitous learning packet on the new slave
as soon as we know about it, and that is what this commit implements.
Bug #1290.
Whether a bond slave is enabled should be based on whether the device's
PHY sees carrier, not based on whether the device is configured up or down.
(Note that a device that is configured down will always see "no carrier").
Otherwise a device that is up but has no carrier will initially be enabled,
which does not make sense.
This has no effect on interfaces that are not bond slaves, because the
"enabled" setting is used only by bond slaves.
Bug #1247.
This commit sends information about Xen UUIDs to the controller through
the management connection. Specifically, it sends the XenServer UUID
and a list of network UUIDs associated with each datapath.
