[PATCH/RFC] disallow vlan devices on top of a logical bridge device

[PATCH/RFC] disallow vlan devices on top of a logical bridge device

[Bart De Schuymer]

Hi all,

The patch below disables making vlan devices on top of bridge
devices, f.e. br0.12 would be impossible.
I'm no vlan expert, but I don't see the use for this and allowing it
will make the bridge-nf code hairy if we want to let {ip,arp}tables see
{IP,ARP} traffic that is embedded in a vlan header.
Also, situations like eth0.15 being a bridge port of br0.16 seem
unwanted (to me).
Dave, please apply, unless someone more knowledgeable (than me) about
this disagrees.

cheers,
Bart

--- linux-2.6.0-test4/net/bridge/br_if.c.old	2003-08-30 13:51:26.000000000 +0200
+++ linux-2.6.0-test4/net/bridge/br_if.c	2003-08-30 14:38:58.000000000 +0200
@@ -98,6 +98,8 @@ static struct net_bridge *new_nb(const c
 	if (!dev)
 		return NULL;
 
+	dev->features |= NETIF_F_VLAN_CHALLENGED;
+	
 	br = dev->priv;
 	br->dev = dev;
 

Re: [PATCH/RFC] disallow vlan devices on top of a logical bridge device

[Bart De Schuymer]

On Saturday 30 August 2003 15:04, Bart De Schuymer wrote:
> Also, situations like eth0.15 being a bridge port of br0.16 seem
> unwanted (to me).

That should be: eth0.15 being a bridge port of br0, and sending locally 
generated traffic through br0.15.

cheers,
Bart

Re: [PATCH/RFC] disallow vlan devices on top of a logical bridge device

[Ben Greear]

Bart De Schuymer wrote:
> Hi all,
> 
> The patch below disables making vlan devices on top of bridge
> devices, f.e. br0.12 would be impossible.
> I'm no vlan expert, but I don't see the use for this and allowing it
> will make the bridge-nf code hairy if we want to let {ip,arp}tables see
> {IP,ARP} traffic that is embedded in a vlan header.
> Also, situations like eth0.15 being a bridge port of br0.16 seem
> unwanted (to me).
> Dave, please apply, unless someone more knowledgeable (than me) about
> this disagrees.

I have never tried to do this, so I don't have a problem with this patch.

However, I'm forwarding this to the vlan mailing list, as I know there
are folks there who use vlans and bridging a lot....  For those who
care, please speak up if you need this functionality for some reason...

Ben

> 
> cheers,
> Bart
> 
> --- linux-2.6.0-test4/net/bridge/br_if.c.old	2003-08-30 13:51:26.000000000 +0200
> +++ linux-2.6.0-test4/net/bridge/br_if.c	2003-08-30 14:38:58.000000000 +0200
> @@ -98,6 +98,8 @@ static struct net_bridge *new_nb(const c
>  	if (!dev)
>  		return NULL;
>  
> +	dev->features |= NETIF_F_VLAN_CHALLENGED;
> +	
>  	br = dev->priv;
>  	br->dev = dev;
>  
> 


-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

Re: [VLAN] Re: [PATCH/RFC] disallow vlan devices on top of a logical bridge device

[Peter Stuge]

On Sat, Aug 30, 2003 at 12:46:22PM -0700, Ben Greear wrote:
> Bart De Schuymer wrote:
> >The patch below disables making vlan devices on top of bridge
> >devices, f.e. br0.12 would be impossible.
> >I'm no vlan expert, but I don't see the use for this and allowing it
> >will make the bridge-nf code hairy if we want to let {ip,arp}tables see
> >{IP,ARP} traffic that is embedded in a vlan header.

I think being able to make a br0.12 is a very good thing, but if it isn't
working properly all the way through *tables, I'd say it's better to take
the possibility away. When someone needs br0.12 bad enough she or he can
deal with the bridge-nf code as well.


> >Also, situations like eth0.15 being a bridge port of br0.16 seem
> >unwanted (to me).

Not neccessarily, since Linux can be connected to multiple "VLAN domains"
(is there a proper term for it?) - that is, all of the VLANs on one
interface could be completely separate from all VLANs on another interface,
making eth0.15 a bridge port of br0.16 only logical.

Admittedly large setups, though.


> However, I'm forwarding this to the vlan mailing list, as I know there
> are folks there who use vlans and bridging a lot....  For those who
> care, please speak up if you need this functionality for some reason...

If {i,ar}ptables doesn't deal with VLANs on bridge ports there's no point in
keeping it, IMHO.


//Peter

Re: [PATCH/RFC] disallow vlan devices on top of a logical bridge device

[Krzysztof Halasa]

Bart De Schuymer <bdschuym@pandora.be> writes:

> The patch below disables making vlan devices on top of bridge
> devices, f.e. br0.12 would be impossible.
> I'm no vlan expert, but I don't see the use for this

There could be some - I'm not using such setup, but I can imagine
doing trunk bridging.
This is sometimes used with dumb (non-VLAN but 1518 bytes-capable)
switches. With Linux, it might be used as well, especially if someone
wants STP to manage trunks and not VLANs (with many VLANs it may
make perfect sense)
-- 
Krzysztof Halasa, B*FH

Re: [PATCH/RFC] disallow vlan devices on top of a logical bridge device

[David S. Miller]

On Sat, 30 Aug 2003 15:04:03 +0200
Bart De Schuymer <bdschuym@pandora.be> wrote:

> The patch below disables making vlan devices on top of bridge
> devices, f.e. br0.12 would be impossible.

I don't think disallowing this merely for the sake of
implementation convenience is such a good idea.  And
from other people's comments, such setups might even
be useful.

Re: [PATCH/RFC] disallow vlan devices on top of a logical bridge device

[Stephen Hemminger]

On Sat, 30 Aug 2003 20:30:43 -0700
"David S. Miller" <davem@redhat.com> wrote:

> On Sat, 30 Aug 2003 15:04:03 +0200
> Bart De Schuymer <bdschuym@pandora.be> wrote:
> 
> > The patch below disables making vlan devices on top of bridge
> > devices, f.e. br0.12 would be impossible.
> 
> I don't think disallowing this merely for the sake of
> implementation convenience is such a good idea.  And
> from other people's comments, such setups might even
> be useful.


Bridge of a VLAN makes sense and is done.
VLAN of a bridge might be done by someone for redundancy or testing.

Don't apply the patch, can't see the harm in allowing either case.

Re: [PATCH/RFC] disallow vlan devices on top of a logical bridge device

[Bart De Schuymer]

On Tuesday 02 September 2003 17:28, Stephen Hemminger wrote:
> Bridge of a VLAN makes sense and is done.
> VLAN of a bridge might be done by someone for redundancy or testing.
>
> Don't apply the patch, can't see the harm in allowing either case.

OK. But isn't br0.15 supposed to work like this: all vlan tagged traffic with 
tag different from 15 is discarded, all non-tagged traffic is given to br0. 
This is how it works with a vlan on top of physical devices like eth0 if I 
read the code correctly, but it doesn't currently work like that for vlan on 
top of 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.
This is why I think a vlan device on top of br0 in Linux is currently useless.

cheers,
Bart

Re: [PATCH/RFC] disallow vlan devices on top of a logical bridge device

[Krzysztof Halasa]

Bart De Schuymer <bdschuym@pandora.be> writes:

> OK. But isn't br0.15 supposed to work like this: all vlan tagged traffic
> with 
> tag different from 15 is discarded, all non-tagged traffic is given to br0.

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.

> 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.
-- 
Krzysztof Halasa, B*FH

Re: [PATCH/RFC] disallow vlan devices on top of a logical bridge device

[Bart De Schuymer]

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

Re: [PATCH/RFC] disallow vlan devices on top of a logical bridge device

[Krzysztof Halasa]

Bart De Schuymer <bdschuym@pandora.be> writes:

> 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.

Right.
 
> 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.

Right. The bridge just bridges the packet based on dest MAC.

> 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.

I would rather expect that br0 bridges all ethernet frames. br0.15 should
behave like a "static VLAN" port on VLAN-aware switch. This is basically
what VLAN-aware switches do with trunk and single VLAN ports (let alone
VLAN filtering which isn't implemented here).

If you have just one trunk port, don't add it (eth0) to the bridge.
Add eth0.15 to the bridge instead.
-- 
Krzysztof Halasa, B*FH

Re: [PATCH/RFC] disallow vlan devices on top of a logical bridge device

[Eran Mann]

Bart De Schuymer wrote:

> 
> OK. But isn't br0.15 supposed to work like this: all vlan tagged traffic with 
> tag different from 15 is discarded, all non-tagged traffic is given to br0. 
> This is how it works with a vlan on top of physical devices like eth0 if I 
> read the code correctly, but it doesn't currently work like that for vlan on 
> top of 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.
> This is why I think a vlan device on top of br0 in Linux is currently useless.
> 
> cheers,
> Bart
> 
Actually this behavior (bridge all VLANs for non-local traffic, allow 
incoming traffic only from configured VLANs) is exactly what you 
typicaly want in a bridged VLAN-aware LAN. Assume for instance that an 
enterprise has N departments and a VLAN (or a few) for each dept. You 
want only guys from the MIS or IT department to be able to manage the 
bridges, not all the departments. being able to configure br0.x in such 
a setup would save you a lot of configuration. Otherwise you'd have to
- configure all the N VLANs on all the physical ports.
- define ebtable rules on each non MIS VLAN, on each physical port, to 
block access to the bridge management.
- define bridging between all the devices.

Also if you want to run spanning-tree than you have a slight problem, 
since the STP code is not VLAN aware, and would send BPDUs on the VLAN 
devices as if they were normal ports, so you need to setup a br

Regards,
	Eran.