Users at Nicira have commented that a maximum reconnection time of 15
seconds, which was the default, is too long. This commit cuts it to 8
seconds, on the theory that an administrator is willing to wait that long
before deciding that a change that should restore connectivity did not
work.
The xapi database for PIFs specifies the MAC address that should be used
for bonds, but interface-reconfigure didn't honor it and ovs-vswitchd
didn't have a way to configure it anyhow. This commit fixes both problems.
Bug #1645.
The "fdb/show" unixctl command was showing vswitch-internal port indexes,
which cannot be meaningfully interpreted by software outside vswitchd.
Also, they potentially change every time the vswitchd configuration file
changes. This commit changes it to use a datapath port index instead,
which are both more meaningful and more stable.
To implement "brctl showmacs" for bridge compatibility, brcompatd needs to
be able to extract the MAC learning table from ovs-vswitchd. This provides
a way, and it may be directly useful to switch administrators also.
If a network device takes a few seconds to detect carrier, as some do, then
when bringing up a network device and then immediately adding that device
to a bridge, the bond code would start out with that slave considered down
and apply the full updelay to it before bringing it up. With the 31-second
updelay set by XenServer, this is excessive: we end up having no
connectivity at all for 31 seconds even though there is no reason for it.
This commit makes the bond code disregard the updelay when an interface
comes up on a bond that has no enabled interfaces, and updates the
documentation to match.
Part of bug #1566.
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
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.
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.
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.
