From: Vlad Yasevich <vyasevic@redhat.com>
To: Shmulik Ladkani <shmulik.ladkani@gmail.com>
Cc: netdev@vger.kernel.org, shemminger@vyatta.com,
davem@davemloft.net, or.gerlitz@gmail.com, jhs@mojatatu.com,
mst@redhat.com
Subject: Re: [PATCH V2 00/12] Add basic VLAN support to bridges
Date: Wed, 19 Dec 2012 09:13:10 -0500 [thread overview]
Message-ID: <50D1CB76.50202@redhat.com> (raw)
In-Reply-To: <20121219101006.7086faef@pixies.home.jungo.com>
On 12/19/2012 03:10 AM, Shmulik Ladkani wrote:
> Thanks Vlad,
>
> On Tue, 18 Dec 2012 14:00:51 -0500 Vlad Yasevich <vyasevic@redhat.com> wrote:
>> A single vlan may also be designated as untagged. Any untagged traffic
>> recieved by the port will be assigned to this vlan.
>
> Why the "untagged vlan" is per-bridge global?
> Usually, 802.1q switches define the PVID (port's VID) which controls
> the value of VID, in case ingress frame is either untagged or
> priority-tagged (per port configuration).
> This gives greater flexibility.
It's not. There is a per port untagged pointer where you can designate
which VLAN is untagged/native on a port. The bride interface itself
can also function as a port, so it gets its own untagged pointer so
it can behave similar to port.
>
>> Any traffic exiting
>> the port with a VID matching the untagged vlan will exit untagged (the
>> bridge will strip the vlan header). This is similar to "Native Vlan" support
>> available in most switches.
>
> 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. If you have more then 1, you don't know
which VLAN the untagged traffic belongs to.
>
> 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?
-vlad
>
> Regards,
> Shmulik
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
next prev parent reply other threads:[~2012-12-19 14:13 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-12-18 19:00 [PATCH V2 00/12] Add basic VLAN support to bridges Vlad Yasevich
2012-12-18 19:00 ` [PATCH V2 01/12] bridge: Add vlan filtering infrastructure Vlad Yasevich
2012-12-18 21:13 ` Eric Dumazet
2012-12-18 21:26 ` Vlad Yasevich
2012-12-18 19:00 ` [PATCH V2 02/12] bridge: Validate that vlan is permitted on ingress Vlad Yasevich
2012-12-18 19:00 ` [PATCH V2 03/12] bridge: Verify that a vlan is allowed to egress on give port Vlad Yasevich
2012-12-18 19:00 ` [PATCH V2 04/12] bridge: Cache vlan in the cb for faster egress lookup Vlad Yasevich
2012-12-18 19:00 ` [PATCH V2 05/12] bridge: Add vlan to unicast fdb entries Vlad Yasevich
2012-12-18 19:00 ` [PATCH V2 06/12] bridge: Add vlan id to multicast groups Vlad Yasevich
2012-12-18 19:00 ` [PATCH V2 07/12] bridge: Add netlink interface to configure vlans on bridge ports Vlad Yasevich
2012-12-18 19:00 ` [PATCH V2 08/12] bridge: Add vlan support to static neighbors Vlad Yasevich
2012-12-18 19:01 ` [PATCH V2 09/12] bridge: Add the ability to configure untagged vlans Vlad Yasevich
2012-12-18 23:01 ` Michael S. Tsirkin
2012-12-18 23:03 ` Vlad Yasevich
2012-12-18 23:10 ` Michael S. Tsirkin
2012-12-19 14:50 ` Vlad Yasevich
2012-12-18 23:04 ` Michael S. Tsirkin
2012-12-19 1:06 ` Vlad Yasevich
2012-12-18 19:01 ` [PATCH V2 10/12] bridge: Implement untagged vlan handling Vlad Yasevich
2012-12-18 19:01 ` [PATCH V2 11/12] bridge: Dump vlan information from a bridge port Vlad Yasevich
2012-12-18 19:01 ` [PATCH V2 12/12] bridge: Add vlan support for local fdb entries Vlad Yasevich
2012-12-18 22:32 ` [PATCH V2 00/12] Add basic VLAN support to bridges Jiri Pirko
2012-12-18 22:46 ` Vlad Yasevich
2012-12-19 8:27 ` Jiri Pirko
2012-12-19 16:25 ` Vlad Yasevich
2012-12-19 17:04 ` Thomas Graf
2012-12-19 17:11 ` Vlad Yasevich
2012-12-19 17:19 ` Jiri Pirko
2012-12-19 17:20 ` Thomas Graf
2012-12-19 8:10 ` Shmulik Ladkani
2012-12-19 14:13 ` Vlad Yasevich [this message]
2012-12-19 19:37 ` Shmulik Ladkani
2012-12-19 20:03 ` Vlad Yasevich
2012-12-19 22:59 ` Vlad Yasevich
2012-12-20 7:00 ` Shmulik Ladkani
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=50D1CB76.50202@redhat.com \
--to=vyasevic@redhat.com \
--cc=davem@davemloft.net \
--cc=jhs@mojatatu.com \
--cc=mst@redhat.com \
--cc=netdev@vger.kernel.org \
--cc=or.gerlitz@gmail.com \
--cc=shemminger@vyatta.com \
--cc=shmulik.ladkani@gmail.com \
/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.