From: Michael Tremer <michael.tremer@ipfire.org>
To: "Nicolas de Pesloüan" <nicolas.2p.debian@free.fr>
Cc: bridge@lists.linux-foundation.org
Subject: Re: [Bridge] Bridging untagged and tagged VLANs
Date: Wed, 22 Jul 2009 22:47:06 +0200 [thread overview]
Message-ID: <4A677ACA.3060100@ipfire.org> (raw)
In-Reply-To: <4A677703.4060507@free.fr>
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@lists.osdl.org/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.
next prev parent reply other threads:[~2009-07-22 20:47 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-07-21 21:52 [Bridge] Bridging untagged and tagged VLANs Michael Tremer
2009-07-21 22:59 ` richardvoigt
2009-07-22 8:51 ` Benny Amorsen
2009-07-22 8:55 ` Benny Amorsen
2009-07-22 3:49 ` Simon Barber
2009-07-22 7:35 ` Michael Tremer
2009-07-22 20:30 ` Nicolas de Pesloüan
2009-07-22 20:47 ` Michael Tremer [this message]
2009-07-22 21:14 ` Nicolas de Pesloüan
2009-07-23 7:54 ` Michael Tremer
2009-07-22 20:41 ` Michael Tremer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4A677ACA.3060100@ipfire.org \
--to=michael.tremer@ipfire.org \
--cc=bridge@lists.linux-foundation.org \
--cc=nicolas.2p.debian@free.fr \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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.