/etc/ovs-vswitchd.conf should always be there. Nevertheless, it is not
nice to entirely break vswitch if it is accidentally deleted. This commit
makes /etc/init.d/vswitch create an empty configuration file if it is
missing.
Bug #1821.
In-band control needs to know the IP and port of the controller, so that
it can set up the correct flows to talk to that controller. Until now,
the rconn code has only made this available when a connection was actually
in progress. This means that, say, ARP packets will not be allowed through
when the rconn backs off. The same is true of packets sent by switches
that access the controller through this one.
This commit makes the rconn cache the remote IP and port and local IP
across connection attempts, improving the situation. In particular, it
reduces the overall amount of time that it takes to connect in my own
simple test case from over 10 seconds to about 2 seconds.
TCP vconns were reporting indeterminate remote IP and remote port, which
prevented in-band control from working for TCP vconns.
The code that this fixes is implemented differently on the citrix branch
and thus the bug was not present there.
Previously, in-band control was L2-based. This worked well when the
controller was on the same network segment as the switch. However, many
configurations are not set up this way. These changes allow a switch and
controller to be on different subnets.
This set of changes also fixes some problems related to passing DHCP
traffic as described in Bug #1618.
A full description of the reasoning and supported configurations of
in-band will be forthcoming.
The ability to match the IP addresses in ARP packets allows for fine-grained
control of ARP processing. Some forthcoming changes to allow in-band
control to operate over L3 requires this support if we don't want to
allow overly broad rules regarding ARPs to always be white-listed.
Unfortunately, OpenFlow does not support this sort of processing yet, so
we must treat OpenFlow ARP rules as having wildcarded those L3 fields.
In-band control sets up a bunch of invisible flows that allow the switch
and controller to communicate over OpenFlow. The rules may have been a
bit too permissive, since it allowed any traffic to reach the
connection's interface. This set of changes tries to tighten that to
only OpenFlow traffic and ARPs.
The method the status callback was using to retrieve the local and
remote MAC addresses pushed back the refresh timer. If this were done
frequently, it could prevent in-band control from updating its rules.
The hash table used until now in the kernel datapath for storing the flow
table provides only two slots that a given flow can occupy. If both of
those slots are already full, for a given flow, then that flow cannot be
added at all and its packets must be handled entirely in userspace, taking
a performance hit. The code does attempt to compensate for this by making
the flow table rather large: 8 slots per flow actually in the flow table.
In practice, this is usually good enough, but some of the tests that we
have run show bad enough performance degradation or even timeouts of
various kinds that we want to implement something better.
This commit replaces the existing hash table by one with a completely
different design in which buckets are flexibly sized and can accept any
number of collisions. By use of suitable levels of indirection, this
design is both simple and RCU-compatible. I did consider other schemes,
but none of the ones that I came up with shared both of those two
properties.
This commit also adds kerneldoc comments for all of the flow table
non-static functions and data structures.
This has been lightly tested for correctness. It has not been tested for
performance.
Bug #1656. Bug #1851.
The code on one side of this #if fork was difficult to test until Xen
upgraded to a new enough kernel that it would exercise it. Later Xen
kernels are now available and this code path has been tested, at least to
some extent, so remove the warning.
Thanks to Ian Campbell <Ian.Campbell@citrix.com> for pointing out the
warning.
Some distributions automatically set /proc/sys/kernel/core_uses_pid to 1
and others leave it at its default setting of 0. That means that, with the
core_pattern that corekeeper was setting, on the former distributions the
PID would be included in core names and on the latter the PID would be
omitted. For consistency, this commit forces the PID to be in the core
file name in either case (note that putting %p in core_pattern causes
the core_uses_pid setting to be disregarded).
CC: Martin Casado <casado@nicira.com>
There is no value in sending out NetFlow messages when the byte counter
(hence, packet counter) is 0. This does not often happen, but it can in
corner cases where a flow gets installed but never sees any traffic before
it is uninstalled.
CC: Peter Balland <peter@nicira.com>
If all of the ports specified as mirror selection criteria actually do not
exist, then until now the bridge would mirror all incoming packets (on
specified VLAN(s), if any). This matches the behavior that occurs if no
mirror selection ports were specified at all, and so it makes a certain
amount of logical sense.
But it is far more likely that the user simply misspelled a port name, or
specified the name of a port that does not always exist. In fact we have
seen this behavior in practice when the controller has not caught up to
the switch's current configuration. So this commit changes the bridge to
instead disable a mirror if ports are specified and none of those ports
exist.
Bug #1904.
compose_dsts() was updating the VLAN of packets sent to VLAN mirrors
before it changed the VLAN value, but of course it's the final VLAN value
that actually matters.
Thanks to Reid for his good work tracking this one down.
Bug #1898.
This bug was introduced in the merge from the citrix branch in commit
8fef8c71 "Merge citrix into master."
Thanks to Reid for characterizing the problem.
Bug #1907.
NetBSD defines NTOHL and NTOHS macros that are used differently than how
they are defined in the test-classifier.c. This commit renames the local
definition so there's no conflict.
OpenFlow has a maximum messages size of 65536 bytes, but management
messages can be greater than that. The management protocol's Extended
Data message is used to get around that limitation. This commit cleans
up some problems with our implementation and adds some additional
sanity-checking to received messages.
Related to vNetManager Bug #1843.
Under heavy VM network load, we have observed that ovs-vswitchd can be
starved for CPU time, which prevents flows from being set up. This can
in turn cause connections to XAPI in Dom0 to time out (among other issues).
It is probably not necessary to renice netback all the way to priority 0
as done in this commit. That is simply the value that we have tested. QA
has not reported any ill side-effects of this choice of value (yet). One
reasonable alternative, should any problems be noticed, would be to leave
netback at its default -5 priority and simply boost ovs-vswitchd's priority
to say -6 or -7.
Bug #1656.
Bug NIC-19, which reported that "brctl show" did not format its output in
the way expected by Citrix QA scripts, was believed fixed by commit
35c979bff4 "vswitchd: Support creating fake bond device interfaces."
Unfortunately, this commit was not tested on a XenServer before it was
committed. Due to differences in the actual test environment and the
XenServer environment, which have different versions of the bridge-utils
package that contains brctl, that commit did not fix the problem observed
by Citrix QA. In particular, the XenServer brctl uses sysfs to obtain
the information displayed by "brctl show", but the previous commit only
fixed up the information output by the bridge ioctls.
The natural way to fix this problem would be to fix up the sysfs support
as well. I started out along that path, but became bogged down in all
the details of the kernel sysfs.
This commit takes an alternate approach, by introducing a wrapper around
the system brctl binary that implements "brctl show" itself and delegates
all other functionality to the original binary (in a different location).
This will not fix tools that do not call into brctl, but to the best of
my knowledge there are no such tools used in the Citrix QA process.
Thanks to Justin and Reid for much feedback.
Bug NIC-19.
Commit 2bb451b69 "xenserver: Rename network devices to match MAC addresses
of physical PIFs" started renaming network devices so that they match
the MAC address that we expect them to have. This worked OK at the time.
Commit 35c979bff "vswitchd: Support creating fake bond device interfaces"
later started creating fake bond devices to make the Citrix QA scripts
happier.
Unfortunately these commits interact badly: the bond devices created by
the latter commit are sometimes chosen as the physical devices to be
renamed over the physical PIF device names. This is because we do allow
datapath internal ports to be chosen as "physical devices" as a last
resort. This commit reverses this decision, eliminating that possibility.
This probably won't become a problem unless somehow we encounter a physical
Ethernet card driver that lacks a queue, but that is unlikely since the
performance would be awful.
Commit c874dc6d6b "secchan: Fix behavior when a network device is renamed."
fixed a crash in the datapath when network devices within a datapath were
renamed. However, this missed the case where the device that was renamed
was a datapath's internal port: these devices have their br_port members
set to NULL, so we have to determine that they belong to a datapath another
way. This commit does so.
This commit also changes the initialization order in dp_dev_create().
Otherwise, dp_device_event() will dereference null when it is called via
register_netdevice(), because the newly created device is a datapath device
but its members are not yet initialized.
This was a somewhat difficult merge since there was a fair amount of
superficially divergent development on the two branches, especially in the
datapath.
This has been build-tested against XenServer 5.5.0 and XenServer 5.7.0
build 15122. It has been booted and connected to XenCenter on 5.5.0.
The merge revealed a couple of outstanding bugs, which will be fixed on
citrix and then merged back into master.
This allows the Citrix host installer to also write the dbcache on upgrade
which enables the management interface to come up on a slave after upgrade.
CP-1148.
Drop records for PIFs,bonds,VLANs etc for other hosts at the point at
which we fetch the records from xapi rather than filtering everytime
we iterate through the lists.
CP-1148.
Currently interface-reconfigure stores a copy of the XAPI database using
python's pickling functionality. Since the XenServer host installer also needs
to write this file (so it is present after slave upgrade) we would like to
switch to something more explicitly under our control.
Begin by factoring out XAPI interactions.
The PCRE_INFO_OKPARTIAL feature used by ovs-switchui was only introduced
in PCRE 7.2, so we need to check for that version or later, instead of
just for PCRE.
Thanks to Ian Campbell <Ian.Campbell@citrix.com> for reporting the problem.
For newer kernels the checksum setup is done at the point the skb is
received in netback or netfront so there is no more need to sprinkle
skb_checksum_setup calls throughout the kernel.
