On 11/14/2013 01:26 PM, Matthew Mosesohn wrote:
Hi RDO list,
There are some serious issues with VLAN tagging in
OVS with the current RDO kernel posted here:
http://repos.fedorapeople.org/repos/openstack/openstack-grizzly/epel-6/ke...
The issue is that tagged frames get dropped somewhere at the network
stack and never actually make it out to the network. These should work
natively with this kernel, but we're seeing serious issues. The two
specific drivers affected are e1000e and bnx. This applies on just
about any 10gigE hardware.
I cannot confirm this. The majority of 10Ge cards work fine in our
lab with kernel-2.6.32-358.123.2.openstack.
According to this doc, they should work
natively without the OVS VLAN splintering hack:
https://access.redhat.com/site/articles/289823
The cards listed on that page have been successfully verified in
our lab. Please ensure that your network is configured properly.
OVS will take care of the tagging but it will f.e. not do MVRP.
Can you confirm that your switch is configured properly, i.e.
VLANs configured manually or port in trunk mode?
There's an old patch we're looking at that may help a bit,
but it
doesn't apply cleanly.
http://openvswitch.org/pipermail/discuss/2011-April/005026.html .
We're looking at this code segment in net/8021q/vlan_core.c and are
trying to understand why vlan_gro_common changed parameters:
EXPORT_SYMBOL(vlan_dev_vlan_
id);
static gro_result_t
vlan_gro_common(struct napi_struct *napi, struct vlan_group *grp,
unsigned int vlan_tci, struct sk_buff *skb)
I'm told that enabling the OVS splinter mode sometimes causes unwanted
behavior and we want to avoid activating it. I was wondering if anyone
can comment on this issue and if there's anyone working on a relevant
fix.
I don't know who told you that enabling splinters causes unwanted
behaviour. It is perfectly fine to do so and a known good workaround
for buggy drivers.
All it causes is install a traditional VLAN device on top of physical
uplinks to trigger VLAN membership in the driver.