[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bridging and VLANs?

>> The use case is that I need to bridge eth0 with eth0.2, allowing layer 
>> two traffic to pass seamlessly between interfaces, yet still leave 
>> eth0.3 in a usable state. The switch this system is connected to is 
>> for all intents and purposes outside of my control, which is the 
>> reason for the odd network setup. 
>> What I'm finding by simply creating a new bridge br0 with members eth0 
>> and eth0.2 is no connectivity on eth0.2, and slow/quirky connectivity 
>> on eth0 (native connectivity to Debian 7.x host). In doing research, 
>> I've found suggestions of adding the VLAN interfaces to the bridge 
>> direct, resulting in a br0, br0.2, and br0.3, but the results were the 
>> same. Also, it has been suggested to use ebtables to filter the VLANs 
>> at layer 2, but I had no luck there either. 

>The problem probably is that eth0 not only contains the untagged traffic 
>but also the tagged frames for VLAN 2. If you bridge eth0 and eth0.2 you 
>essentially loop the packages from and to VLAN2, because every package 
>"put into" eth0.2 will be seen on eth0 as well and thus bridged again 
>to eth0.2 etc. 
>I don't see any clean solution other than getting rid of the untagged 
>traffic on eth0 and only use tagged frames. Then you could bridge (for 
>example) eth0.10 and eth0.2 and everything should be fine. 
>But if you cannot change anything on the switch, you are out of luck. 

That was my initial thought as well. However, I've been working with 'ebtables' which is essentially the Linux layer 2 filtering subsystem (akin to iptables for layer 3 filtering). I seem to be on the right track, but have now run into further issues with ebtables, and am hoping someone over on the netfilter list can assist.

For posterity, I found the following reported to work (taken from the ebtables documentation [1]):

ebtables -t broute -A BROUTING -i eth0 -p 802_1Q --vlan-id 3 -j DROP

This (theoretically) allows traffic to pass natively from eth0 into the bridge, but force the vlan tagged traffic within the kernel to the interface eth0.3 where tagging/untagging operates correctly. eth0.3 is then added to the bridge for proper operation. In practice the expected results are not positive.

If you have any pointers on ebtables usage in this scenario, I'd love to hear them.

Thank you,


Reply to: