Tim, Ah crap. I should've read the OP first. Definitely some scenario lost in quote-trimming... On Fri, Dec 12, 2014 at 02:03:12PM -0600, Tim Nelson wrote: > Greetings- > > I have an interesting situation that requires bridging some VLAN > enabled interfaces together on a Debian 7.x x86 system. On the host, > there is a single physical interface passing traffic natively (eth0), > and two tagged VLANs also passing traffic (eth0.2 and eth0.3). > > The use case is that I need to bridge eth0 with eth0.2, allowing layer > two traffic to pass seamlessly between interfaces, and still leave > eth0.3 in a usable state. The switch this system is connected to is > 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). This sounds a bit like an IP address / routing rule conflict. Did you set eth0 and eth0.2 0.0.0.0 and promiscuous? Did you assign one IP address to the bridge? Would you mind sending the output of: # ip addr show and # route -n ? > It has been suggested to use ebtables to filter the VLANs from the > eth0 interface on the bridge, yet allow operation to the system > interface eth0.2/eth0.3. I found a very specific reference on the > ebtables site for this scenario [1], usage suggested (modified to fit > my environment): > > ebtables -t broute -A BROUTING -i eth0 -p 802_1Q --vlan-id 3 -j DROP > ebtables -t broute -A BROUTING -i eth0 -p 802_1Q --vlan-id 2 -j DROP > > If my understanding of the ebtables usage as a brouter, and the > kernel's interaction between all components involved, this should > work. However, as noted, no change in operation is observed. Yes, based on your description of the network you are going to need the above rules. thx, Jason. -- To unsubscribe from this list: send the line "unsubscribe netfilter" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
