All of lore.kernel.org
 help / color / mirror / Atom feed
* VLAN filtering/VLAN aware bridge problems
@ 2013-08-29 12:50 Stefan Priebe - Profihost AG
  2013-08-29 20:45 ` Vlad Yasevich
  0 siblings, 1 reply; 11+ messages in thread
From: Stefan Priebe - Profihost AG @ 2013-08-29 12:50 UTC (permalink / raw)
  To: vyasevic; +Cc: David Miller, Linux Netdev List

Hello,

currently i'm running vanilla 3.8.8 kernel with some tap devices using
VLANs on top of a bridge on top of a bond.

This works fine and everything is great.

Now i started to test 3.10.9 and all my VLANs stopped working no matter
i disable or enable CONFIG_BRIDGE_VLAN_FILTERING.

The packets never reach the TAP device.

Here is an output of ip a l (vlan 3021):

ip a l
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,PROMISC,SLAVE,UP,LOWER_UP> mtu 1500 qdisc
mq master bond0 state UP qlen 1000
    link/ether 00:25:90:84:de:a8 brd ff:ff:ff:ff:ff:ff
3: eth4: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 9000 qdisc mq
master bond5 state UP qlen 10000
    link/ether 90:e2:ba:33:45:0c brd ff:ff:ff:ff:ff:ff
4: eth1: <BROADCAST,MULTICAST,PROMISC,SLAVE,UP,LOWER_UP> mtu 1500 qdisc
mq master bond0 state UP qlen 1000
    link/ether 00:25:90:84:de:a8 brd ff:ff:ff:ff:ff:ff
5: eth2: <BROADCAST,MULTICAST,PROMISC,SLAVE,UP,LOWER_UP> mtu 1500 qdisc
mq master bond1 state UP qlen 1000
    link/ether 00:25:90:84:de:aa brd ff:ff:ff:ff:ff:ff
6: eth5: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 9000 qdisc mq
master bond5 state UP qlen 10000
    link/ether 90:e2:ba:33:45:0c brd ff:ff:ff:ff:ff:ff
7: eth3: <BROADCAST,MULTICAST,PROMISC,SLAVE,UP,LOWER_UP> mtu 1500 qdisc
mq master bond1 state UP qlen 1000
    link/ether 00:25:90:84:de:aa brd ff:ff:ff:ff:ff:ff
8: bond0: <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP> mtu 1500 qdisc
noqueue master vmbr0 state UP
    link/ether 00:25:90:84:de:a8 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::225:90ff:fe84:dea8/64 scope link
       valid_lft forever preferred_lft forever
9: bond1: <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP> mtu 1500 qdisc
noqueue master vmbr1 state UP
    link/ether 00:25:90:84:de:aa brd ff:ff:ff:ff:ff:ff
    inet6 fe80::225:90ff:fe84:deaa/64 scope link
       valid_lft forever preferred_lft forever
10: vmbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue
state UP
    link/ether 00:25:90:84:de:a8 brd ff:ff:ff:ff:ff:ff
    inet 178.250.9.30/25 brd 178.250.9.127 scope global vmbr0
       valid_lft forever preferred_lft forever
    inet6 fe80::225:90ff:fe84:dea8/64 scope link
       valid_lft forever preferred_lft forever
11: vmbr1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue
state UP
    link/ether 00:25:90:84:de:aa brd ff:ff:ff:ff:ff:ff
    inet6 fe80::225:90ff:fe84:deaa/64 scope link
       valid_lft forever preferred_lft forever
12: bond5: <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP> mtu 9000 qdisc
noqueue state UP
    link/ether 90:e2:ba:33:45:0c brd ff:ff:ff:ff:ff:ff
    inet 10.255.0.30/24 brd 10.255.0.255 scope global bond5
       valid_lft forever preferred_lft forever
    inet6 fe80::92e2:baff:fe33:450c/64 scope link
       valid_lft forever preferred_lft forever
15: vmbr1.3020@vmbr1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc
noqueue master vmbr1v3020 state UP
    link/ether 00:25:90:84:de:aa brd ff:ff:ff:ff:ff:ff
    inet6 fe80::225:90ff:fe84:deaa/64 scope link
       valid_lft forever preferred_lft forever
16: vmbr1v3020: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue
state UP
    link/ether 00:25:90:84:de:aa brd ff:ff:ff:ff:ff:ff
    inet6 fe80::f036:92ff:fe40:7224/64 scope link
       valid_lft forever preferred_lft forever
19: tap320i0: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc
htb master vmbr0 state UNKNOWN qlen 500
    link/ether fe:fa:14:cc:75:b2 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::fcfa:14ff:fecc:75b2/64 scope link
       valid_lft forever preferred_lft forever
20: tap320i1: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc
htb master vmbr1v3021 state UNKNOWN qlen 500
    link/ether 8a:f3:9b:47:c7:88 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::88f3:9bff:fe47:c788/64 scope link
       valid_lft forever preferred_lft forever
21: vmbr1.3021@vmbr1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc
noqueue master vmbr1v3021 state UP
    link/ether 00:25:90:84:de:aa brd ff:ff:ff:ff:ff:ff
    inet6 fe80::225:90ff:fe84:deaa/64 scope link
       valid_lft forever preferred_lft forever
22: vmbr1v3021: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue
state UP
    link/ether 00:25:90:84:de:aa brd ff:ff:ff:ff:ff:ff
    inet6 fe80::9868:5eff:fe9d:bf56/64 scope link
       valid_lft forever preferred_lft forever

Greets,
Stefan

^ permalink raw reply	[flat|nested] 11+ messages in thread
* Re: VLAN filtering/VLAN aware bridge problems
  2013-08-29 12:50 VLAN filtering/VLAN aware bridge problems Stefan Priebe - Profihost AG
@ 2013-08-29 20:45 ` Vlad Yasevich
  2013-08-30  7:24   ` Stefan Priebe - Profihost AG
  0 siblings, 1 reply; 11+ messages in thread
From: Vlad Yasevich @ 2013-08-29 20:45 UTC (permalink / raw)
  To: Stefan Priebe - Profihost AG; +Cc: David Miller, Linux Netdev List

On 08/29/2013 08:50 AM, Stefan Priebe - Profihost AG wrote:
> Hello,
>
> currently i'm running vanilla 3.8.8 kernel with some tap devices using
> VLANs on top of a bridge on top of a bond.
>
> This works fine and everything is great.
>
> Now i started to test 3.10.9 and all my VLANs stopped working no matter
> i disable or enable CONFIG_BRIDGE_VLAN_FILTERING.

Just enabling config option doesn't turn on the filtering behavior.

>
> The packets never reach the TAP device.
>
> Here is an output of ip a l (vlan 3021):

Can you provide output of brctl show?

>
> ip a l
> 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN
>      link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
>      inet 127.0.0.1/8 scope host lo
>         valid_lft forever preferred_lft forever
>      inet6 ::1/128 scope host
>         valid_lft forever preferred_lft forever
> 2: eth0: <BROADCAST,MULTICAST,PROMISC,SLAVE,UP,LOWER_UP> mtu 1500 qdisc
> mq master bond0 state UP qlen 1000
>      link/ether 00:25:90:84:de:a8 brd ff:ff:ff:ff:ff:ff
> 3: eth4: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 9000 qdisc mq
> master bond5 state UP qlen 10000
>      link/ether 90:e2:ba:33:45:0c brd ff:ff:ff:ff:ff:ff
> 4: eth1: <BROADCAST,MULTICAST,PROMISC,SLAVE,UP,LOWER_UP> mtu 1500 qdisc
> mq master bond0 state UP qlen 1000
>      link/ether 00:25:90:84:de:a8 brd ff:ff:ff:ff:ff:ff
> 5: eth2: <BROADCAST,MULTICAST,PROMISC,SLAVE,UP,LOWER_UP> mtu 1500 qdisc
> mq master bond1 state UP qlen 1000
>      link/ether 00:25:90:84:de:aa brd ff:ff:ff:ff:ff:ff
> 6: eth5: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 9000 qdisc mq
> master bond5 state UP qlen 10000
>      link/ether 90:e2:ba:33:45:0c brd ff:ff:ff:ff:ff:ff
> 7: eth3: <BROADCAST,MULTICAST,PROMISC,SLAVE,UP,LOWER_UP> mtu 1500 qdisc
> mq master bond1 state UP qlen 1000
>      link/ether 00:25:90:84:de:aa brd ff:ff:ff:ff:ff:ff
> 8: bond0: <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP> mtu 1500 qdisc
> noqueue master vmbr0 state UP
>      link/ether 00:25:90:84:de:a8 brd ff:ff:ff:ff:ff:ff
>      inet6 fe80::225:90ff:fe84:dea8/64 scope link
>         valid_lft forever preferred_lft forever
> 9: bond1: <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP> mtu 1500 qdisc
> noqueue master vmbr1 state UP
>      link/ether 00:25:90:84:de:aa brd ff:ff:ff:ff:ff:ff
>      inet6 fe80::225:90ff:fe84:deaa/64 scope link
>         valid_lft forever preferred_lft forever
> 10: vmbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue
> state UP
>      link/ether 00:25:90:84:de:a8 brd ff:ff:ff:ff:ff:ff
>      inet 178.250.9.30/25 brd 178.250.9.127 scope global vmbr0
>         valid_lft forever preferred_lft forever
>      inet6 fe80::225:90ff:fe84:dea8/64 scope link
>         valid_lft forever preferred_lft forever
> 11: vmbr1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue
> state UP
>      link/ether 00:25:90:84:de:aa brd ff:ff:ff:ff:ff:ff
>      inet6 fe80::225:90ff:fe84:deaa/64 scope link
>         valid_lft forever preferred_lft forever
> 12: bond5: <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP> mtu 9000 qdisc
> noqueue state UP
>      link/ether 90:e2:ba:33:45:0c brd ff:ff:ff:ff:ff:ff
>      inet 10.255.0.30/24 brd 10.255.0.255 scope global bond5
>         valid_lft forever preferred_lft forever
>      inet6 fe80::92e2:baff:fe33:450c/64 scope link
>         valid_lft forever preferred_lft forever
> 15: vmbr1.3020@vmbr1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc
> noqueue master vmbr1v3020 state UP
>      link/ether 00:25:90:84:de:aa brd ff:ff:ff:ff:ff:ff
>      inet6 fe80::225:90ff:fe84:deaa/64 scope link
>         valid_lft forever preferred_lft forever
> 16: vmbr1v3020: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue
> state UP
>      link/ether 00:25:90:84:de:aa brd ff:ff:ff:ff:ff:ff
>      inet6 fe80::f036:92ff:fe40:7224/64 scope link
>         valid_lft forever preferred_lft forever
> 19: tap320i0: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc
> htb master vmbr0 state UNKNOWN qlen 500
>      link/ether fe:fa:14:cc:75:b2 brd ff:ff:ff:ff:ff:ff
>      inet6 fe80::fcfa:14ff:fecc:75b2/64 scope link
>         valid_lft forever preferred_lft forever
> 20: tap320i1: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc
> htb master vmbr1v3021 state UNKNOWN qlen 500
>      link/ether 8a:f3:9b:47:c7:88 brd ff:ff:ff:ff:ff:ff
>      inet6 fe80::88f3:9bff:fe47:c788/64 scope link
>         valid_lft forever preferred_lft forever
> 21: vmbr1.3021@vmbr1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc
> noqueue master vmbr1v3021 state UP
>      link/ether 00:25:90:84:de:aa brd ff:ff:ff:ff:ff:ff
>      inet6 fe80::225:90ff:fe84:deaa/64 scope link
>         valid_lft forever preferred_lft forever
> 22: vmbr1v3021: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue
> state UP
>      link/ether 00:25:90:84:de:aa brd ff:ff:ff:ff:ff:ff
>      inet6 fe80::9868:5eff:fe9d:bf56/64 scope link
>         valid_lft forever preferred_lft forever
>

I can only guess that the configuration based on the above data.  Can
you give a diagram of the config.

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.

Thanks
-vlad

> Greets,
> Stefan
>

^ permalink raw reply	[flat|nested] 11+ messages in thread
* Re: VLAN filtering/VLAN aware bridge problems
  2013-08-29 20:45 ` Vlad Yasevich
@ 2013-08-30  7:24   ` Stefan Priebe - Profihost AG
  2013-08-30 14:13     ` Vlad Yasevich
  0 siblings, 1 reply; 11+ messages in thread
From: Stefan Priebe - Profihost AG @ 2013-08-30  7:24 UTC (permalink / raw)
  To: vyasevic; +Cc: David Miller, Linux Netdev List

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


> 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

^ permalink raw reply	[flat|nested] 11+ messages in thread
* Re: VLAN filtering/VLAN aware bridge problems
  2013-08-30  7:24   ` Stefan Priebe - Profihost AG
@ 2013-08-30 14:13     ` Vlad Yasevich
  2013-08-30 15:01       ` Stefan Priebe - Profihost AG
  2013-08-30 15:01       ` Stefan Priebe - Profihost AG
  0 siblings, 2 replies; 11+ messages in thread
From: Vlad Yasevich @ 2013-08-30 14:13 UTC (permalink / raw)
  To: Stefan Priebe - Profihost AG; +Cc: David Miller, Linux Netdev List

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
>

^ permalink raw reply	[flat|nested] 11+ messages in thread
* Re: VLAN filtering/VLAN aware bridge problems
  2013-08-30 14:13     ` Vlad Yasevich
@ 2013-08-30 15:01       ` Stefan Priebe - Profihost AG
  2013-08-30 15:01       ` Stefan Priebe - Profihost AG
  1 sibling, 0 replies; 11+ messages in thread
From: Stefan Priebe - Profihost AG @ 2013-08-30 15:01 UTC (permalink / raw)
  To: vyasevic; +Cc: David Miller, Linux Netdev List

Yes

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
> 

^ permalink raw reply	[flat|nested] 11+ messages in thread
* Re: VLAN filtering/VLAN aware bridge problems
  2013-08-30 14:13     ` Vlad Yasevich
  2013-08-30 15:01       ` Stefan Priebe - Profihost AG
@ 2013-08-30 15:01       ` Stefan Priebe - Profihost AG
  2013-09-10 14:11         ` Vlad Yasevich
  1 sibling, 1 reply; 11+ messages in thread
From: Stefan Priebe - Profihost AG @ 2013-08-30 15:01 UTC (permalink / raw)
  To: vyasevic; +Cc: David Miller, Linux Netdev List

Yes

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
> 

^ permalink raw reply	[flat|nested] 11+ messages in thread
* Re: VLAN filtering/VLAN aware bridge problems
  2013-08-30 15:01       ` Stefan Priebe - Profihost AG
@ 2013-09-10 14:11         ` Vlad Yasevich
  2013-11-12 21:31           ` Stefan Priebe
  0 siblings, 1 reply; 11+ messages in thread
From: Vlad Yasevich @ 2013-09-10 14:11 UTC (permalink / raw)
  To: Stefan Priebe - Profihost AG; +Cc: David Miller, Linux Netdev List

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.

-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
>>

^ permalink raw reply	[flat|nested] 11+ messages in thread
* Re: VLAN filtering/VLAN aware bridge problems
  2013-09-10 14:11         ` Vlad Yasevich
@ 2013-11-12 21:31           ` Stefan Priebe
  2013-11-12 23:25             ` Vlad Yasevich
  0 siblings, 1 reply; 11+ messages in thread
From: Stefan Priebe @ 2013-11-12 21:31 UTC (permalink / raw)
  To: vyasevic; +Cc: David Miller, Linux Netdev List

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?

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
>>>
>

^ permalink raw reply	[flat|nested] 11+ messages in thread
* Re: VLAN filtering/VLAN aware bridge problems
  2013-11-12 21:31           ` Stefan Priebe
@ 2013-11-12 23:25             ` Vlad Yasevich
  2013-11-13  7:28               ` Stefan Priebe - Profihost AG
  0 siblings, 1 reply; 11+ messages in thread
From: Vlad Yasevich @ 2013-11-12 23:25 UTC (permalink / raw)
  To: Stefan Priebe; +Cc: David Miller, Linux Netdev List

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?

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
>>>>
>>

^ permalink raw reply	[flat|nested] 11+ messages in thread
* Re: VLAN filtering/VLAN aware bridge problems
  2013-11-12 23:25             ` Vlad Yasevich
@ 2013-11-13  7:28               ` Stefan Priebe - Profihost AG
  2013-11-13 14:49                 ` Vlad Yasevich
  0 siblings, 1 reply; 11+ messages in thread
From: Stefan Priebe - Profihost AG @ 2013-11-13  7:28 UTC (permalink / raw)
  To: vyasevic; +Cc: David Miller, Linux Netdev List

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.

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
>>>>>
>>>
> 

^ permalink raw reply	[flat|nested] 11+ messages in thread
* Re: VLAN filtering/VLAN aware bridge problems
  2013-11-13  7:28               ` Stefan Priebe - Profihost AG
@ 2013-11-13 14:49                 ` Vlad Yasevich
  0 siblings, 0 replies; 11+ messages in thread
From: Vlad Yasevich @ 2013-11-13 14:49 UTC (permalink / raw)
  To: Stefan Priebe - Profihost AG, vyasevic; +Cc: David Miller, Linux Netdev List

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
>

^ permalink raw reply	[flat|nested] 11+ messages in thread
end of thread, other threads:[~2013-11-13 14:49 UTC | newest]

Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-08-29 12:50 VLAN filtering/VLAN aware bridge problems Stefan Priebe - Profihost AG
2013-08-29 20:45 ` Vlad Yasevich
2013-08-30  7:24   ` Stefan Priebe - Profihost AG
2013-08-30 14:13     ` Vlad Yasevich
2013-08-30 15:01       ` Stefan Priebe - Profihost AG
2013-08-30 15:01       ` Stefan Priebe - Profihost AG
2013-09-10 14:11         ` Vlad Yasevich
2013-11-12 21:31           ` Stefan Priebe
2013-11-12 23:25             ` Vlad Yasevich
2013-11-13  7:28               ` Stefan Priebe - Profihost AG
2013-11-13 14:49                 ` Vlad Yasevich

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.