[Rdo-list] partially broken VLAN tagging support

Perry Myers pmyers at redhat.com
Thu Nov 14 15:24:26 UTC 2013


On 11/14/2013 10:20 AM, Matthew Mosesohn wrote:
> BZ made
> https://bugzilla.redhat.com/show_bug.cgi?id=1030501
> 
> We can reproduce in virtual hardware, but it's not the real thing.
> We'll have access to some broadcom hardware tomorrow and recreate our
> environment.

Thanks!

Perry

> On Thu, Nov 14, 2013 at 6:38 PM, Perry Myers <pmyers at redhat.com> wrote:
>> On 11/14/2013 08:55 AM, Thomas Graf wrote:
>>> 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/kernel-2.6.32-358.123.2.openstack.el6.x86_64.rpm
>>>>
>>>>
>>>> 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.
>>
>> Thanks Thomas.
>>
>> Matty, just in case there is an actual bug behind this, can you please
>> file a bug here, specifically on the kernel component?
>>
>> https://bugzilla.redhat.com/enter_bug.cgi?product=RDO




More information about the dev mailing list