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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <50D21D98.7020907@redhat.com>
Date:	Wed, 19 Dec 2012 15:03:36 -0500
From:	Vlad Yasevich <vyasevic@...hat.com>
To:	Shmulik Ladkani <shmulik.ladkani@...il.com>
CC:	netdev@...r.kernel.org, shemminger@...tta.com, davem@...emloft.net,
	or.gerlitz@...il.com, jhs@...atatu.com, mst@...hat.com
Subject: Re: [PATCH V2 00/12] Add basic VLAN support to bridges

On 12/19/2012 02:37 PM, Shmulik Ladkani wrote:
> Hi Vlad,
>
> On Wed, 19 Dec 2012 09:13:10 -0500 Vlad Yasevich <vyasevic@...hat.com> wrote:
>>> 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).
>
>>> 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.
>
>> 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 :)

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

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html