netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Bart De Schuymer <bdschuym@pandora.be>
To: Krzysztof Halasa <khc@pm.waw.pl>
Cc: Stephen Hemminger <shemminger@osdl.org>,
	"David S. Miller" <davem@redhat.com>,
	greearb@candelatech.com, netdev@oss.sgi.com
Subject: Re: [PATCH/RFC] disallow vlan devices on top of a logical bridge device
Date: Tue, 2 Sep 2003 22:02:52 +0200	[thread overview]
Message-ID: <200309022202.52044.bdschuym@pandora.be> (raw)
In-Reply-To: <m3ptijt5ek.fsf@defiant.pm.waw.pl>

On Tuesday 02 September 2003 20:24, Krzysztof Halasa wrote:
> Actually I think non-VLAN15 traffic shouldn't make it to br0.15 in the
> first place, the same with physical ethernet and anything like that.

Obviously. The point is, vlan traffic with tag differing from 15 would be 
dropped if br0 were a physical device and not a logical bridge device.

> > The vlan code only sees tagged packets if the
> > packets are destined for the bridge box itself, so bridged traffic is
> > unaffected.
>
> Sure. Do you mean packets received from ethernet interface (br0 port)?
> They go to br0, of course. I don't see anything special here.
> I understand you don't need VLAN support for trunk bridging. You need
> it for locally accessing VLANs (trunk members) only.

Umm, I probably should stop wasting people's time.
Let me compare eth1.15 with br0.15, eth0 is a port of br0, eth1 is not, 
eth0.xx doesn't exist.

Vlan tagged packet arrives on eth1: the vlan code gets to deal with the packet 
thanks to dev_add_pack(&vlan_packet_type). If the vlan tag differs from 15, 
the packet is dropped. To outsiders, the indev is eth0.15.

Vlan tagged packet arrives on eth0: the bridge code gets to deal with the 
packet. So, to (most) outsiders the indev is br0. The bridge code happily 
forwards the packet, no matter what the vlan tag might be.
I would find it logical if the indev would be br0.15 for vlan traffic over a 
bridge br0 when br0.15 exists, and that only vlan15 traffic gets forwarded.
So, basically, I'd expect br0.15 to act like a bridge, since br0 is a bridge.

cheers,
Bart

  reply	other threads:[~2003-09-02 20:02 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-08-30 13:04 [PATCH/RFC] disallow vlan devices on top of a logical bridge device Bart De Schuymer
2003-08-30 13:21 ` Bart De Schuymer
2003-08-30 19:46 ` Ben Greear
2003-09-05 11:42   ` [VLAN] " Peter Stuge
2003-08-30 21:16 ` Krzysztof Halasa
2003-08-31  3:30 ` David S. Miller
2003-09-02 15:28   ` Stephen Hemminger
2003-09-02 17:32     ` Bart De Schuymer
2003-09-02 18:24       ` Krzysztof Halasa
2003-09-02 20:02         ` Bart De Schuymer [this message]
2003-09-02 21:43           ` Krzysztof Halasa
2003-09-02 23:05       ` Eran Mann

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=200309022202.52044.bdschuym@pandora.be \
    --to=bdschuym@pandora.be \
    --cc=davem@redhat.com \
    --cc=greearb@candelatech.com \
    --cc=khc@pm.waw.pl \
    --cc=netdev@oss.sgi.com \
    --cc=shemminger@osdl.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).