An easy to understand description of VLANs for Cisco, HP, VMWare, or Microsoft

VLANs can be confusing for virtualization administrators, because it takes a really solid understanding of networking to then be abstracted into a virtual environment, which can then be configured multiple ways.
Let's make sure we're on the same page with VLANs first

Let's think about a physical environment that is segmented without any VLANS

 

If we think about networks from a chronological perspective, we start with just the green local area network at the top. All your local clients were in a local broadcast domain with a single network ID. And the living was easy.

Then LANs continued to grow and grow, which caused too many broadcasts, traffic congestion, and security vulnerabilities... all because all the devices were playing in the same "sandbox."

 

So to divide the LAN we ran a dedicated cable from a newly dedicated interface on the router, installed a separate switch, and routed between the LANs, as seen in the diagram above.

 

Question: Why would anyone ever want anything better than that solution?

#1 - Money: High speed Ethernet interfaces on routers are a costly proposition, only superseded by purchasing entirely new routers to handle the traffic from each network. Additionally, every subnet needs a dedicated switch. What if a 48 port switch is serving a network of only 10 hosts? 37 wasted ports.

#2 - Management: To reassign a host to a different subnet means moving their patch cable to a physically different switch. This is a manual, physical process that requires going into the racks and mucking about - always an additional risk, easy to make mistakes

The good news is that soon one of the first network virtualization technologies came into being. Instead of having to buy additional switches and router interfaces, we can use virtual LANs (VLANs)

- VLANs allow us to virtualize networks using two key components:

1) Switch ports are virtualized so that instead of one switch you can have the effect of having two or three or more switches from a single physical switch, and then you can spread these multiple virtual switches across multiple physical switches!

2) Router interfaces are also virtualized, using sub-interfaces on physical routers or virtual VLAN interfaces on multilayer switches. Each virtualized router interface will be configured to "plug in" to the virtual switch. This means that one uplink could support a connection to 20 different subnets!

So how do you go about virtualization? It's all about playing a game of tag. Each switch's access port (a port going to an end station such as a server, desktop, phone, or router) will be tagged with a particular VLAN number, determined arbitrarily by the administrator.  (Side note, many administrators make their lives easier by creating a loose association between VLANs and subnet IDs. For example, the 192.168.5.0 subnet could be assigned VLAN 5 for simplicity.)

So each VLAN is identified by a number and the default VLAN is VLAN 1. All ports are assigned to VLAN 1 by default, meaning that the switch functions like an unmanaged switch, all ports will forward, filter, and flood with all other ports. Since this is the case, by default, VLAN tagging (inserting the tag ID into the frame) is skipped by default for VLAN 1. This skipping can only be done for one VLAN ID number, and is known as the "native VLAN". 

But now we choose to subdivide the switch by adding VLAN 2.  Generally on a switch you will have the opportunity to provide a VLAN name, which makes it a more sensical device (ie: HR_192.168.5.0 for the Human Resources subnet using 192.168.5.0)

Now that we two different VLANs an administrator needs to assign access ports to that VLAN.

This effectively turns a switch from this:

(Switch with all ports still on VLAN 1)

into this:




Remember, the devices connected to the switch know nothing about VLANs. But now the switch has virtualized two networks instead of one, which means that traffic must be ROUTED from one VLAN into the other, not just switch. 

In order to allow multiple switches and routers to participate in these VLANs we must modify the standard Ethernet frame and insert a VLAN tag number so that all devices can respect the defined VLAN boundaries. Tagging is done between devices over what are known as trunk ports. Trunk ports are used when connecting switches to each other or when connecting switches with multiple vlans to a router. Trunk ports are not assigned a VLAN number because their job is to carry ALL VLAN traffic upstream to a router and to take the returning packets and forward them to the correct access ports. VLAN ID numbers are stripped from the frames before they enter an access port.

That allows for this:

With this configuration you can see that we have the equivalent of 4 switches instead of two, with two switches in each broadcast domain. The great thing about the configuration above is that a device in VLAN 1 can switch to another device in VLAN 1 (or a VLAN 2 device to another VLAN 2 device) at high speeds. However, if a device wants to connect to another device across VLANs (VLAN 1 PC to a VLAN 2 Server, for example) then they had better know the know the IP address of the sub-interface (virtual interface) of their L3 routing service! In other words, they must route as if they were physically connected to different physical interfaces of the router.

But the real beauty of all this is that any device could be moved to a different subnet by reconfiguring the VLAN ID of an access port to a different number. As long as all the switches have the same VLAN ID numbers (and the router has VLAN associated sub-interfaces.

A little more about the native VLAN. The default VLAN is VLAN 1 (what all ports start off as). The default VLAN is also the native VLAN (untagged "assumed" VLAN number) by default. This was useful when connecting unmanaged and managed switches and in carrying management traffic back in the day. However, for security reasons, it is usually a best practice to change the native vlan to a different, unused VLAN ID number (such as 999). This ensures that are no assumptions, and therefore no annoying security holes. Now VLAN1 frames will be tagged as VLAN 1 just like all the other VLANs

When VLAN 2 is added, the VLAN tag is added to frames that are a part of VLAN 2. We now have two VLANs, and at least one of them must be tagged to be identified. 

Now, let’s add VLAN 3.  In this setup, two VLANs would need to be tagged, one would not because it was the original lan (VLAN)  The VLAN that is not tagged is known as the native VLAN.

There are a lot of questions of when and why to use the native VLAN or if you should use the native VLAN at all.  As always in IT, the answer is, it depends on what you are doing. VLAN 1 does not have to be your management VLAN.  It does not have to be the native or untagged VLAN. You can do whatever you need for your environment.  Typically, I do not use the native VLAN for security reasons, and I choose to tag everything. 

Remember that all of this is true whether you are dealing with a physical switch or a hypervisor driven virtual switch on Microsoft Hyper-V or VMWare ESXi. Trunk ports between switches, defined VLANs omnipresent, Access ports with VLAN ID numbers on individual access ports.

Keep it clean, keep it safe.