Thread (35 messages) 35 messages, 6 authors, 2012-12-20

Re: [PATCH V2 00/12] Add basic VLAN support to bridges

From: Vlad Yasevich <hidden>
Date: 2012-12-19 20:03:41

On 12/19/2012 02:37 PM, Shmulik Ladkani wrote:
Hi Vlad,

On Wed, 19 Dec 2012 09:13:10 -0500 Vlad Yasevich [off-list ref] wrote:
quoted
quoted
Why the "untagged vlan" is per-bridge global?
It's not.  There is a per port untagged pointer where you can designate
which VLAN is untagged/native on a port.
Ok (misinterpreted the text in the cover letter).
quoted
quoted
802.1q switches usually allow conifguring per-vlan, per-port
tagged/untagged egress policy: each vid has its port membership map and
an accompanying port egress-policy map.
This gives great flexibility defining all sorts of configurations.
Right, and that's what's provided here.
   * Each VLAN has port membership map (net_bridge_vlan.portgroup).
   * Each port has a list of vlans configured as well
(net_port_vlan.vlan_list).
   * Each port also has a single vlan that can be untagged
(net_bridge_port.untagged).
   * The bridge also has a single untagged vlan (net_bridge.untagged)

The limitation (in switches as well) is that only a single VLAN
may be untagged on any 1 port.
Switches usually allow you to configure each port's egress policy per
vlan, and allow you to configure multiple vlans to _egress_ untagged
on a port.
quoted
If you have more then 1, you don't know
which VLAN the untagged traffic belongs to.
The port's PVID uniquely determines VID to associate with the frame
during _ingress_ on that port - in the case frame arrived untagged.

This is unrelated to whether a frame having a specific VID would _egress_
tagged or untagged on that port.

Ahh...  I see what you mean.  You would like to separate
ingress policy and egress policy with regard to how tags are applied...
I haven't seen that type of config before.

I did say "Basic VLAN support". :)

In this set of patches ingress and egress policies are hardcoded the same...

So, consider that what I am calling "untagged" in this series is
really vlan associated with PVID.  To change the egress policy, we
could add an untagged bitmap into the vlan.  Then the bitmap from the 
vlan would determine the egress policy.  If the port is in the "tagged"
bitmap, frame leaves tagged. If the port is in the "untagged" bitmap,
frame leaves untagged.

The code to make this would would be simple enough.  The more 
interesting part would be the configuration :)

quoted
quoted
Personally, I'd prefer a fully flexible vlan bridge allowing all sorts
of configurations (as available in 802.1q switches).

What's the reason limiting such configurations?
So, what do you see that's missing?
[ snip good example ]
The bridge constructs needed for supporting such setups are:
- per port: PVID
- per VLAN: port membership map
- per VLAN: port egress policy map
Ok, so from above, membership map is the exiting port_bitmap.  Egress
policy map could be new untagged_bitmap.  We wouldn't need a tagged 
policy map since a port can't be "in egress policy, but not in 
membership map".

Membership port_bitmap is consulted on egress for basic forward/drop 
decision (just as it is now).  Egress policy (untagged bitmap) is 
consulted to see how the forwarding is done.

Sounds about right?  If so, I could probably work something up.
Will probably leave the configuration for later as that might take a bit
longer to figure out.

-vlad
I agree, tools other than a vlan bridge may implement such setups, but
using the vlan bridge would be preferred, mainly due to the simplicity.

Regards,
Shmulik
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help