Re: VLAN filtering/VLAN aware bridge problems

[Vlad Yasevich <vyasevich@gmail.com>]

On 11/13/2013 02:28 AM, Stefan Priebe - Profihost AG wrote:
> Am 13.11.2013 00:25, schrieb Vlad Yasevich:
>> On 11/12/2013 04:31 PM, Stefan Priebe wrote:
>>> sorry for the very late response.
>>>
>>> Am 10.09.2013 16:11, schrieb Vlad Yasevich:
>>>> On 08/30/2013 11:01 AM, Stefan Priebe - Profihost AG wrote:
>>>>> Yes
>>>>>
>>>>
>>>> Can you apply this patch and see if this fixes your problem.
>>>>       http://patchwork.ozlabs.org/patch/273841/
>>>>
>>>> In my attempts to reproduce your problem I didn't configuring filtering
>>>> on the upper bridge, but that is what could have been causing
>>>> your problem.  I'll attempt it and let you know.
>>>
>>> Even with the complete patchset which was merged upstream it doesn't
>>> work ;-(
>>>
>>> What's wrong there and / or how can i debug?
>>
>> Can you provide the filtering settings for both bridges you use?
>
> I don't filter at all right now it's compiled in but not enabled - but i
> have these problems since these patches were included.
>
> It only start to work if i set the eth0 and eth1 (slaves of the bond) to
> promisc mode. So the problem seems to be that the ethernet devices do
> not accept the VLAN tagged packages.

That doesn't make much sense. If the filtering is not enabled, then
this code isn't in use.  It will not try to set any vlan filtering
so you should be running with essentially stock bridge.

Bridge sets promisc mode on all its ports, so your bond device should
be in promisc mode.  Bonding code sets different set of slaves into
promisc mode depending on the mode you use.  Which mode do you have
your bond configured in?
Does, dmesg tell you if devices have entered promisc mode?

-vlad

>
> Stefan
>
>> Thanks
>> -vlad
>>
>>>
>>> Stefan
>>>
>>>> -vlad
>>>>
>>>>
>>>>> Stefan
>>>>>
>>>>> This mail was sent with my iPhone.
>>>>>
>>>>> Am 30.08.2013 um 16:13 schrieb Vlad Yasevich <vyasevic@redhat.com>:
>>>>>
>>>>>> On 08/30/2013 03:24 AM, Stefan Priebe - Profihost AG wrote:
>>>>>>> Am 29.08.2013 22:45, schrieb Vlad Yasevich:
>>>>>>>> On 08/29/2013 08:50 AM, Stefan Priebe - Profihost AG wrote:
>>>>>>>
>>>>>>>>> The packets never reach the TAP device.
>>>>>>>>>
>>>>>>>>> Here is an output of ip a l (vlan 3021):
>>>>>>>>
>>>>>>>> Can you provide output of brctl show?
>>>>>>>
>>>>>>> Sure:
>>>>>>> # brctl show
>>>>>>> bridge name     bridge id               STP enabled     interfaces
>>>>>>> vmbr0           8000.00259084dea8       no              bond0
>>>>>>>                                                           tap320i0
>>>>>>> vmbr1           8000.00259084deaa       no              bond1
>>>>>>> vmbr1v3021              8000.00259084deaa       no
>>>>>>> tap320i1
>>>>>>>                                                           vmbr1.3021
>>>>>>
>>>>>> so let me see if I can understand this configuration.
>>>>>>
>>>>>>            vmbr1v3021 (bridge)
>>>>>>             /          \
>>>>>>         tap320i1       vmbr1.3021 (vlan)
>>>>>>                            \
>>>>>>                            vmbr1 (bridge)
>>>>>>                               \
>>>>>>                              bond1
>>>>>>                                 \
>>>>>>                               eth X
>>>>>>
>>>>>>
>>>>>> Is that right? Is this the setup that has the problem you are
>>>>>> describing?
>>>>>>
>>>>>> Thanks
>>>>>> -vlad
>>>>>>
>>>>>>>> On the off chance that you are actually trying to configure vlan
>>>>>>>> filtering, can you give this patch a try (net-2.6 tree):
>>>>>>>>
>>>>>>>> Author: Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp>
>>>>>>>> Date:   Tue Aug 20 17:10:18 2013 +0900
>>>>>>>>
>>>>>>>>       bridge: Use the correct bit length for bitmap functions in the
>>>>>>>> VLAN
>>>>>>>> code
>>>>>>>>
>>>>>>>> I don't think it made it to stable yet.
>>>>>>>
>>>>>>> I addd that patch and now the vlan stuff works at least on the host
>>>>>>> node. But my tap devices still don't work.
>>>>>>>
>>>>>>> I also tried to attach the tap device on top of a vlan attached to
>>>>>>> bond1
>>>>>>> but then gvrp does not work anymore. The kernel announces gvrp once
>>>>>>> and
>>>>>>> then does not answer the query packets from the switch.
>>>>>>>
>>>>>>> Stefan
>>>>>>
>>>>
>>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>