VLANs on Linux

An introduction to VLANs and VLAN trunking, how Linux interacts with VLANs and how you might use them in networks.

To begin, we must have a more formal definition of what a LAN is. LAN
stands for local area network. Hubs and switches usually are thought of
as participating in a single LAN. Normally, if you connect two computers
to the same hub or switch, they are on the same LAN. Likewise, if you
connect two switches together, they are both on the same LAN.

A LAN includes all systems in the broadcast domain. That is,
all of the systems on a single LAN receive a broadcast sent by any
member of that LAN. By this definition, a LAN is bordered by routers or
other devices that operate at OSI Layer 3.

Now that we've defined a LAN, what is a VLAN? VLAN stands for virtual
LAN. A single VLAN-capable switch is able to participate in multiple
LANs at once.

This functionality alone has a variety of uses, but VLANs become far more
interesting when combined with trunking. A trunk is a single physical
connection that can carry multiple VLANs. Each frame that crosses the
trunk has a VLAN identifier attached to it, so it can be identified
and kept within the correct VLAN.

Trunks can be used between two switches, between a switch and a router or
between a switch and a computer that supports trunking. When connecting to
a router or computer, each VLAN appears as a separate virtual interface.

When using trunks, it is important to consider that all the VLANs carried
over the trunk share the same bandwidth. If the trunk is running over
a 100Mbps interface, for example, the combined bandwidth of all the VLANs crossing
that trunk is limited to 100Mbps.

Advantages of VLANs

VLANs provide a number of benefits to a network designer. The first
advantage is the number of devices required to implement a given
network topology can be reduced. Without VLANs, if your network design
requires ten machines divided into five different LANs, you would need
five different switches or hubs, and most of the ports would be wasted. With
VLANs, this work could be done with one device.

Most routers and standard computers can support a limited number of
physical network interfaces. Although dual and quad-port Ethernet adapters
are available, these are expensive. For example, a quad-port
Ethernet card may cost $400. VLAN capable switches start at around $500,
but they support many more interfaces.

Depending on the scenario, VLANs and trunks can provide an effective
way of segmenting a network without the expense and complexity of managing
many physical interfaces.

Types of Trunks

Several trunk encapsulations are available. Trunks can be carried
across a variety of interface types, but this article deals only with
Ethernet. The two main protocols for carrying VLANs over Ethernet are
ISL and 802.1q. ISL was created by Cisco prior to the standardization of
802.1q and is proprietary. 802.1q, on the other hand, is an open standard
and is widely supported. Hereafter, references to trunking mean
802.1q-over-Ethernet. As a side note, 802.1q is defined on only
100Mbps or higher Ethernet; it does not support 10Mbps.

How VLANs Work

Trunks using the 802.1q protocol work by adding a 4-byte VLAN identifier
to each frame. This is used on both ends to identify to which VLAN each
individual frame belongs. When a switch receives a tagged unicast frame,
it looks up the outgoing port using both the destination MAC address and
the VLAN identifier. When a broadcast frame is received, it is flooded out
to all active ports participating in that VLAN.

When a VLAN-aware router or computer receives a tagged frame, it examines
the tag to determine to which virtual interface the frame belongs. This
virtual interface can have an IP address and behaves basically the same
as a normal physical interface.

Some switches have the concept of a native VLAN on a trunk
connection. Packets sent out from the trunk port on this VLAN are untagged.
Likewise, untagged packets received on this port are associated with
this VLAN. Native VLANs on both ends of a trunk must
match. A native-VLAN mismatch on the two ends of the trunk causes
problems using the native VLAN configured on each end.

Security Considerations for VLANs and Trunks

For all the benefits of VLANs and trunking, some risks must
be weighed. As opposed to physical separation between network segments,
VLANs rely on the switch to do the right thing. It is possible that a
misconfiguration or a bug could cause the VLAN barriers to be broken.

Two risks are associated with VLANs. In the first, a packet leaks from one VLAN
to another, possibly revealing sensitive information. In the second, a specially
crafted packet is injected into another VLAN. Any attack that could
cause the VLAN barriers to break requires a machine directly
attached to the physical network. This means that only a local machine
can execute an attack against the switch.

When the switch is configured properly, the chances of these problems
happening are slim, but the possibility still exists. It is up to
you to examine your needs and your security policy to determine if VLANs
are right for you.

It is beyond the scope of this article to describe exactly how to configure
your switch securely, but most vendors provide documentation outlining
best practices. Briefly, you should configure at least the following:

Disable trunking and trunk negotiation on all ports except those
absolutely necessary.

Thanks for sharing about vlan. I have been trying to configure VLANs on my pc(linux),but i am not able to do that.

First thing i want to know is, how to configure the vlan on the pc alone(not on switch).My linux pc works with kernel built-in 802.1q driver and rtl8139 nic card. Does the nic driver(8139too) should also support the vlan ?

second, after configuring(two vlans eth0.2,eth0.3) how to send packets specifically via eth0.2 alone, and the same with receiving side.

Hi guys...
I just have a quick question to ask and i d appreciate if u answer me on my mail
Well,me and my class we ve been working on Vlans, on Switches, Catalysts 2900
the thing is when I configure Vlan from Vlan database, and go to the interface I press the commnada MAnagement, cause other wise with Show vlan command it will show that vlan in the table, but when I do show ip int vlan (name) it sais that the protocol down. And our teacher said that with Management command can make that Vlan operational.
The thing is, that when I configure more that 1 vlan in the switches it can be up and operational only 1 vlan, only the one i press the command Management into the interface.
Without that command the vlans don't work...and with that command only 1 can be operational.
Well if u can help me i ll appreciate...

I was looking for something useful about vlans,
a few days ago, I was heared something about vlan and I just had to inject this to my local lan network,
article is very useful and so much helpfull (at least for me)
after all I bought my cisco catalyst 2900xl and wanted to configure it with vlans but actually don't know what,

thanks in advance for autor of this article, and maybe I will see something about vlans, so if someone has some info about vlan, plese mail it to me

What is the advantage and disadvantage by doing VLAN trunking on a single physical NIC vs. assigning sub-IPs to the NIC? I was wondering if we really gain the security & traffic segmentation features of a real VLAN. If we simulate VLAN trunking by sharing a physical NIC, on what level does the OS actually separate the traffic? Or, they are still mixed and make it as if they were VLANs?

This article exactly hit the nail on the head! I was to able create a "layer 3 switch" with an unused PC running Linux and an old 3Com superstack 3300 switch for our test lab. Suprisingly fast, it's clearly faster than what I suspected (although certainly not as fast a real L3 switch)

How to organize domain server by help of Linux Vlan router.
For instance I have VLAN: 2,3,4,5 and I want the traffic from them to be routed in vlan 10 (server's VLAN) but 2,3,4,5 must don't touch. Help!

Having no previous knowledge about vlans or switch configuration and being suddenly tasked with setting up multiple vlans on a switch configured from a single ethernet connection on a debian system, I found this article invaluable. Thanks.

If we create VLAN interface
vconfig add eth1 2
and not give it IP address, is it possible to create script which would manage network traffic for VLAN2.
For example, would this command work:
iptables -A FORWARD -i vlan2 -j DROP

Did you manage to use the vlan without configuring them. I've encountered a similar problem. In earlier sysconfig, simply creating vlans using 'vconfig add would've configured it as well, inheriting the values from physical interface. It also used to show up using 'ifconfig'

But now vconfig moving into vlan package, this is no more true. Now one has to configure it seperately in order to see it using 'ifconfig', otherwise it'll not show up in 'ifconfig', though 'ifconfig -a' will show it.

Still a little cloudy if this is necessary all the time when using all Linux workstations on a network. For instance, you have two switches linked together to share various VLANS (i.e. VLAN 1 and VLAN 2 have ports on both switches) and you have 2 physical LANs with different network addresses. Physical LAN 1 is part of VLAN 1 and physical LAN 2 is part of VLAN 2. Both physical lans are connected to a router (Linux box with 2 Ethernet cards) via the switches. With this setup isn't all this transparent to the the Linux workstations? If you want to talk to the other VLAN or physical network it would go to the router. In this scenario you would not need to do all the configuration mentioned in the article? The reason I ask is that we need to mix and match fiber and copper. The above scenario would enable us share the switches between the physical LANs. We would not be required to use two switches for each LAN (one copper one fiber). Also, it would still maintain separate broadcast domains for the physical LANs. Am I way off base?

I had 3c905C card on my RH9 Linux box. I made 2 VLAN and http traffic stopped. Before this everything worked fine. I tried to change cards and so on. I fixed it only when removed the 3c905 card and installed DFE-538TX card. It seemed 3c905 driver has some bugs. I guess it is a bug of assigning or management MTU.

having the ETH driver patched to support 1504 mtu's the normal eth's had to have their mtu capped to 1500... to do that, add to the /etc/sysconfig/network-scripts/ifcfg-ethX MTU=1500 and to the ifcfg-ethX.X MTU=1504

VLAN interfaces behave exactly as normal physical interfaces do in iptables. You can specify them for rules as incoming (-i) and outgoing (-o) interfaces.

I haven't had any issues with VLAN interfaces behaving differently than normal interfaces do any any of my deployments. I do know that in the past there were some issues with DHCP, but I have never had any problems with it myself.

I'm terribly sorry but this was a crappy article. Understanding how to configure interfaces is done in two seconds. The MTU issues are a big problem that you wrestle with for much longer. Until recently (or does it still apply?) you had to patch your ethernet interface drivers manually in the kernel to adjust the maximum MTU size.

Also you have to adjust your ruleset to accompany the larger packets. Then some drivers are buggy and will crash when you increase MTU above the standard 1500 (not to speak of crappy taiwanese d-link switches that lock up from time to time).

All this is skimmed through with one sentence that it "could be issues". You might say that, yes.

I disagree with your criticism of the article. He did adequately address tne issue of limited/buggy Linux ethernet drivers (though a link to a more indepth resource, perhaps a Wiki page where various kernel hackers list links to their patches, would be nice).

Noting that some cheap ethernet equipment might also choke when connected to a trunk line would be nice, but is also above and beyind the call of this article.

As for how trivial the interfaces are to set up, configure and use --- that's the core of the article. I teach professional sysadmin courses, and compile kernels for breakfast (well, usually I start them before I go to bed, actually).

I've been seeing the VLAN 802.1q patch available for years and was vaguely familiar with VLANs from working alongside Cisco networks on numerous occasions. However, I'd never used the VLAN features, didn't know about the 'vconfig' command, wouldn't have known that the vlan* interfaces needed to be bound to their physical interfaces with it, and generally would have had to hunt around a bit to find that info.

This article introduced the concept well, and gave me enough info that I could fire up an old Cisco 2900 switch I have laying around and play with the functionality with no fuss. (Well, no fussing on the Linux side; I have no idea what state that 2900 is in and how I would fix it up; it's on permanent loan from a friend).

It's one of the best articles I've seen recently. I like the fact that he covers the basics of using Cisco IOS or is it CatOS for the other side of this effort; stressing how the switch must talk to the Linux box in trunk mode, and giving examples of setting up the other ports as well.

I abolutely agree with the reply to the original post. This was not intended to be an in depth article on vlans but introductory one to help a user new to vlans quickly set up to use them. I found it helpful in answering some questions I had since this just came up at work eg. can I trunk a linux box to a Cisco 3550 or do I need to buy another switch.

All in all a great starter article for anyone interested in getting started using vlans. BTW he does throw in some caveats regarding NIC drivers and MTU.

I understand the benefits of VLANS, but I'm not quite sure what the purpose of configuring VLANS at the OS level is. Could you explain the purpose or benefit of configuring VLANS on Linux? Why would you need to do it you already configured VLANS in your switch.

We use it for management. The public addresses of our servers only do serving, there is no management (ssh fx) on these addresses. Instead we use a separate LAN for management access. We could put a separate nic in each server, but it is much easier to just add a VLAN on eth0.

Our management VLAN is tagged throughout the network, so for me to get access to it, my workstation needs to support VLAN's too. My eth0 is configured like any other user's, but then I also have an eth0.2 configured, which happens to be our management VLAN.

The switch is configured to allow VLAN 2 only on the switch port where I sit, not on everybody else's. So normal users simply can't have access to VLAN 2. So there is no way they can even connect to an open port 22.

You'd do it when you want your Linux box on the trunk line to be a router from one VLAN to another, and perhaps even to run a Snort or Prelude IDS or other NIDS (network intrusion detection system) on on one or more of the VLANs.

I personally prefer separated switches or hub when I can --- especially for the DMZ and server room segments. However, VLANs become important at a certain scale (as do manageable, SNMP switches).

Trending Topics

Upcoming Webinar

Getting Started with DevOps - Including New Data on IT Performance from Puppet Labs 2015 State of DevOps Report

August 27, 2015
12:00 PM CDT

DevOps represents a profound change from the way most IT departments have traditionally worked: from siloed teams and high-anxiety releases to everyone collaborating on uneventful and more frequent releases of higher-quality code. It doesn't matter how large or small an organization is, or even whether it's historically slow moving or risk averse — there are ways to adopt DevOps sanely, and get measurable results in just weeks.