From: Brian Allen Vanderburg II <brianvanderburg2@aim.com>
To: netdev@vger.kernel.org
Subject: iproute2/vlan: Idea: Support untagged VLAN interfaces
Date: Wed, 02 Apr 2014 07:54:38 -0400 [thread overview]
Message-ID: <533BFA7E.9020001@aim.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 2706 bytes --]
I've been recent playing around with some of the new VLAN filtering
features. One feature I want to be able to do is to create an interface
that handles untagged data for VLANs as a sub-interface instead.
Currently, untagged data is only handled by the main interface. I can
think of some reasons to have untagged data on its own VLAN interface.
* The ability to bring up and down the untagged interface without
affecting all tagged interfaces as well.
* The ability to bridge only untagged traffic for mapping/translating.
If an untagged sub-interface exists, then VLAN mapping can be performed
by bridging the VLAN interfaces of two NICs with differing VLANs and
including the untagged traffic. Without untagged VLAN sub-interfaces
only tagged traffic could be mapped. The bridge VLAN filtering allows
filtering of VLANs per port, but does not seem to allow mapping or
translating VLANs.
* Misc
The bridge VLAN filtering feature seems to make it possible, but
requires a rather large amount of configuration. This first section
will take any traffic on eth0 and pass it in to br0. VLAN 1 is untagged
on eth0, but is treated as tagged as it passes to br0.
ip link add dev br0 type bridge
ip link set dev eth0 master br0
ip link set dev eth0 promisc on
echo 1 > /sys/class/net/br0/bridge/vlan_filtering
bridge vlan add dev eth0 vid 1 pvid untagged
bridge vlan add dev eth0 vid 10
bridge vlan add dev eth0 vid 99
bridge vlan add dev br0 vid 1 self
bridge vlan add dev br0 vid 10 self
bridge vlan add dev br0 vid 99 self
Because br0 sees even the original untagged traffic as tagged, I can now
add a separate interface for the untagged VLAN as desired:
ip link add link br0 name br0_user type vlan id 1
ip link add link br0 name br0_priv type vlan id 10
ip link add link br0 name br0_mgmt type vlan id 99
The interfaces can then be configured as normal. I can bring down any
interface and it will not affect the others, or do anything else. I
have managed to confirm this seems to work fine in a VM where untagged
traffic on eth0 was received on br0_user as expected.
This is a bit of work to get a "sub-interface" for an untagged VLAN.
One idea I had was that if the groundwork already exists, it may be
possible to add something similar directly to the interface without the
bridge and VLAN filtering setup. I could imagine a command such as
ip link add link eth0 name eth0_user type vlan id 1 pvid untagged
as being able to accomplish the same thing without the overhead of
creating a bridge and assigning all the VLANs to both the physical
device and bridge device.
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
reply other threads:[~2014-04-02 11:52 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=533BFA7E.9020001@aim.com \
--to=brianvanderburg2@aim.com \
--cc=netdev@vger.kernel.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).