All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Nicolas de Pesloüan" <nicolas.2p.debian@free.fr>
To: Michael Tremer <michael.tremer@ipfire.org>
Cc: bridge@lists.linux-foundation.org
Subject: Re: [Bridge] Bridging untagged and tagged VLANs
Date: Wed, 22 Jul 2009 22:30:59 +0200	[thread overview]
Message-ID: <4A677703.4060507@free.fr> (raw)
In-Reply-To: <4A66C14C.4090300@ipfire.org>

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.

  reply	other threads:[~2009-07-22 20:30 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 [this message]
2009-07-22 20:47       ` Michael Tremer
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=4A677703.4060507@free.fr \
    --to=nicolas.2p.debian@free.fr \
    --cc=bridge@lists.linux-foundation.org \
    --cc=michael.tremer@ipfire.org \
    /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.