Oops, just sent the email when your one scrabbled to my inbox. https://lists.linux-foundation.org/pipermail/bridge/2009-July/006626.html I applied that ebtables rule to the chain but no packages got to the vlan interface (eth0.30) anymore. Michael Nicolas de Pesloüan wrote: > Michael Tremer wrote: >> >> In this mail on >> http://www.mail-archive.com/bridge@xxxxxxxxxxxxxx/msg01440.html >> there is the following sentence: "- Add native support for an untagged >> vlan. Currently an untagged vlan can be implimented using ebtables or > > similar." >> >> Do you know how to do this? > > For as far as I remember, the right way to do it with ebtables is : > > brctl addbr br0 > vconfig add eth0 30 > brctl addif br0 eth0.30 > brctl addif br0 eth0 > > ebtables --table broute -A BROUTING --protocol 802_1Q --vlan-id 30 > --jump DROP > > Normally, a DROP target in BROUTING let the frame being ROUTED. The > exact behavior is "give it to upper layer", which is IP in most case. > But, for a 802.1q tagged frame, the upper layer is "remove the 802.1q > header and give it again to lower layer, on the right interface". > > So this ebtables entry deny the bridge the opportunity to eat frames > having a 802.1q vlan id = 30, giving the opportunity to the vlan stack > to remove the vlan header and give it to eth0.30... > > Not tested, because I don't have a bridge available right now, but > this should work. > > Of course, if you add several eth0.X interfaces to the bridge, you > should add the corresponding ebtables entry. For very special > configuration, --in-interface eth0 might be necessary too. > > Just thinking about it, the --vlan-id 30 might be useless. Juste > having --protocol 802_1Q might be enough for simple configuration. > Just try and told us. > > HTH. > > Nicolas. _______________________________________________ Bridge mailing list Bridge@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/bridge
