Hello,
I have a colleague who is creating an openvswitch configuration consisting
of an
eth0, a vlan eth0.300 and two OVS bridges: br-ex and br-fixed. The system
uses
openvswitch-2.1.2 and linux kernel version 3.12.X
Initially, eth0 and eth0.300 are configured with the following addresses:
eth0 192.168.124.81
eth0.300 192.168.126.2
Ultimately, eth0 and eth0.300 will become ports of br-ex and br-fixed,
however,
it is not known in advance, which interface will be added to which bridge.
Further, it's not known which interface/bridge combo will be configured
first.
All that is certain, is that the interfaces will be added to different
bridges.
What we see when the eth0.300/br-X is configured first, is a subsequent
failure during
configuration of eth0/br-Y.
We perform the following steps:
# ovs-vsctl add-br br-ex
# ip addr flush dev eth0.300
# ip addr add 192.168.126.2/24 dev br-ex
# ovs-vsctl add-port br-ex eth0.300
Up to this point, we are able to access 192.168.126.0/24 and
192.168.124.0/24
Continuing:
# ovs-vsctl add-br br-fixed
# ip addr flush dev eth0
# ip addr add 192.168.124.81/24 dev br-fixed
# ovs-vsctl add-port br-fixed eth0
And here we see the problem. Specifically:
/var/log/openvswitch/ovs-vswitchd.log:
2015-09-15T23:14:24.638Z|00023|dpif|WARN|system@ovs-system: failed to add
eth0 as port: File exists
Digging into the openvswitch datapath module, we find:
datapath/vport-netdev.c:netdev_create()
...
err = netdev_master_upper_dev_link(netdev_vport->dev,
get_dpdev(vport->dp));
...
netdev_master_upper_dev_link() is a kernel API which returns -EEXISTS from:
net/core/dev.c:__netdev_upper_dev_link()
...
if (__netdev_find_adj(dev, upper_dev, &dev->all_adj_list.upper))
return -EEXIST;
...
Thus, since ovs bridge ports get enslaved under ovs-system, regardless to
which
actual bridge they are added, a case of eth0 and eth0.300 vlan trip the
adjacency
checks in newer kernel version. Older kernel versions did not show this
error
as the datapath contains:
openvswitch-2.1.2/datapath/linux/compat/include/linux/netdevice.h:
...
#if LINUX_VERSION_CODE < KERNEL_VERSION(3,9,0)
/* XEN dom0 networking assumes dev->master is bond device
* and it tries to access bond private structure from dev->master
* ptr on receive path. This causes panic. Therefore it is better
* not to backport this API.
**/
static inline int netdev_master_upper_dev_link(struct net_device *dev,
struct net_device *upper_dev)
{
return 0;
}
static inline void netdev_upper_dev_unlink(struct net_device *dev,
struct net_device *upper_dev)
{
}
#endif
...
There is a 'workaround' we've employed, and that is when hitting this error,
to re-enslave eth0.300. This causes both eth0 and eth0.300 to be correctly
added to their respective bridges _and_ to be enslaved under ovs-system.
Clearly
this is exploiting a bit of a flaw, but it allows my colleague to proceed
on.
Aside from providing these data points to interested parties, I was hoping
I might get some feedback as to:
1. Whether this use case is at all valid - please note that another such
question
was posted to the mailer:
http://openvswitch.org/pipermail/discuss/2014-June/014219.html
2. What a suitable, ovs accepted, workaround/approach would be to solving
this problem.
Thanks in advance,
Karol
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
