With the increased adoption of virtualization by companies of all sizes there is a requirement by systems and server administrators to have a good appreciation and working knowledge of not only the hypervisor and the physical server on which it is running on but also storage and networking technologies.
Virtualization products such as VMware’s ESX(i), depending on the configuration, can require a significant number of network ports especially if using features such as DRS, HA and FT. Add to this iSCSI storage and a layer of resilience on each of the network ports and you can easily be looking at a requirement for 8+ ports. Not only this, if you want to follow best practices and keep some of your network traffic isolated (eg: iSCSI, different business departments) then you would require separate physical switches. As you can imagine the cost involved in purchasing all of these posts and switches could be significant.
This is where network VLANs come to the rescue and assist in running multiple isolated networks over a single or handful of ports. There are obviously performance and best practice considerations when doing so though VLANs do offer a cost effective and convenient way of doing more with less.
TechHead Guest Contributor
VLANs can prove to be a little confusing when first starting out though this excellent article from TechHead guest contributor, Jon Langemak takes you through the basics of a VLAN right through to how to configure one on an ever popular Cisco switch.
Jon Langemak is a Cisco certified network engineer currently working in the consulting area of IT. When he’s not working on Cisco he also dabbles in VMware and storage architectures. Check out his blog over at dasblinkenlichten.com for more great networking, virtualization and storage related posts.
What is a VLAN?
VLANs are relatively easy to describe in concept, however they can be significantly harder to implement. The term VLAN stands for ‘Virtual LAN’ and Cisco defines a VLAN as a broadcast domain. Basically, what that means is that you can segregate certain ports on a single physical switch into logical switches (VLANs). Let’s take a simple example to solidify the point. Say there are two businesses who, because of cost restraints, decided to split the cost of a single 48 port switch. The switch can be configured with two VLANs and you can assign half of the ports to VLAN 2 (Company A) and remaining ports to VLAN 3 (Company B). If I plug a computer into a VLAN 2 port and another computer into a VLAN 3 port they will be unable to communicate. I can push this example further by creating more and more VLANs. Since a VLAN is its own broadcast domain, a device in one VLAN will never be able to talk to a device in another VLAN. In addition to a VLAN being its own broadcast domain, it should have a unique network/subnet number. For instance, VLAN 2 might have a network of 192.168.2.2 /24 and VLAN 3 might have 192.168.3.3 /24. The bottom line is that each VLAN should use its own unique addressing scheme. As you can see, the concept of VLANs is pretty simple to understand but gets more confusing as the infrastructure grows.
The native VLAN
One thing that drives me absolutely nuts is when people buy a Cisco switch, unwrap it, plug it in, plug hosts into it, and call it a day. While it’s true that any Cisco switch can be plugged in and just work, that’s not exactly a best practice. Cisco has what they call the ‘native’ VLAN which is, by default, VLAN 1. A brand new switch without any configuration will have all of its ports defined in the native VLAN. Notice in the above example that I didn’t assign any ports to VLAN 1. In some environments the native VLAN is reserved for management purposes. In larger deployments switches will use the native VLAN to communicate with one another. Additionally, an IP address can be configured on this VLAN for management purposes. In these cases the native VLAN won’t actually be assigned to any physical switch ports since we don’t actually want data traversing it. Changing the native VLAN is possible by modifying the native VLAN on access and trunk ports, however this should be done with caution and usually isn’t seen in smaller installs.
Multiple Switches with the same VLANs
As our network infrastructure grows it becomes necessary to add more switch ports. This is done by adding more physical switches. In order to pass traffic from VLANs on one switch to another switch we need to implement what is called a ‘trunk’ port. There are basically two types of ports on a Cisco switch. Access ports can be assigned to a single VLAN (phone VLANs are the exception here) and are used to connect a single host to the network. Trunk ports are designed for interconnecting switches and allow one or more VLANs to be assigned to the port. As you can see in the example below, there are two switches interconnected by a trunk port which allow both VLAN 1 and VLAN 2 traffic to traverse the link between the two switches. Note that the trunk port is not a member of any specific VLAN, I just happened to show the trunk between two ports that are shown as being in VLAN 1. For the picture to be 100% accurate, the trunk port would be in neither VLAN 1 or 2. When you define a trunk on a switch you used to have to define an encapsulation type for the trunk. Since data from multiple VLANs travel over a trunk, the switches need to mark (encapsulate) the frames traversing the link so that either side can determine what VLAN the frames belong to. The two options for encapsulation were ISL (Inter-Switch Link A Cisco proprietary standard) and DOT1Q (802.1Q A IEEE standard). Cisco is well known for creating their own solution before a standard can be ratified and that’s how ISL came into play. These days most Cisco switches (at least layer 2 switches) don’t even give you an option to define an encapsulation type. The standard is simply DOT1Q. DOT1Q tags each frame with a VLAN by adding a 32 bit VLAN tag into the original frame. The bottom line is that when you connect two switches you should use a trunk port which, by default in most cases, uses DOT1Q trunking. It should be noted that trunk ports aren’t only used for interconnecting switches. An example of this would be for use on a single ethernet drop that supports both a VOIP phone and a computer. Going by strict definition, an access port supports one VLAN and a trunk port supports one or more VLANs. Before the ‘switchport voice vlan’ command came around if you wanted to support both a phone and data VLAN on a single port you would have to configure the port as trunk port. Trunk ports by default support all VLANs but can be limited to support only a select group. We’ll talk about that configuration below. It should also be noted that in order to connect two switches, a cross-over cable should be used.
Where is VLAN information stored?
VLAN information is stored in each switches local VLAN database. If I wanted to connect two switches and be able to assign ports to both VLAN 1 and VLAN 2 on both switches, I would need the exact same VLANs defined on each switch. As you can probably guess, ensuring that all switches have the exact same copy of all the VLANs in a 100+ switch deployment could be a daunting task. Cisco has a proprietary solution known as the VLAN Trunk Protocol (VTP) that allows you to propagate VLANs from one switch to all of the others. VTP involves assigning at least one switch to be the ‘server’ and other switches to be the ‘clients’. The clients will poll the server for VLAN information and ensure that they have an exact copy of the VLAN database from the server. It should be noted that not all of the VLANs need to be defined on each switch. For instance, let’s look at our company A and company B example from above. Let’s say that company A is expanding and needs more switch ports. They purchase another switch and connect it to the first switch using a trunk port as shown below.
If they were going to use all of the switch ports we would only need to define VLAN 2 on the second switch. Note that the trunk port still shows both VLANs traversing the link. By default a trunk port allows all VLANs to traverse it. However, in this example there aren’t any ports in VLAN 3 assigned to the switch so there’s no need to define the VLAN on the switch. The best practice in smaller environments that aren’t running VTP is to define all the VLANs on all switches. If you are in a larger environment using VTP there is an option called VTP pruning which automatically prunes VLANs from switches that don’t have ports defined in the VLAN.
VLAN tagging means a lot of different things, particularly between vendors. Often I’ll hear HP Procurve guys say something like “Tag that access port on VLANs 100 and 200”. In Cisco land, that’s not really possibly. Access ports in Cisco only support one VLAN. In this case we would need to use a trunk port and limit the trunk port to VLANs 100 and 200. You also need to take into account that a device plugged into a trunk port needs to be able to talk the same encapsulation method as the switch. If it doesn’t, it won’t be able to see anything but the native VLAN because it’s traffic is always untagged. I usually use the term ‘tagged’ when referring to the particular configuration of an access port. Actual VLAN tagging on a Cisco switch only occurs on trunk ports to make sure that traffic from a particular VLAN is tagged as such. It’s also important to realize that, for the most part, host devices don’t understand VLANs and their associated encapsulation. So while it might seem obvious to some, it should be noted that no VLAN configuration needs to be done on the host devices. Plugging them into an access port on a particular VLAN is all that needs to be done to qualify VLAN membership.
Layer 3 switching
Before we dive into configuration commands I want to mention one last item. VLANs are a layer 2 technology. That being said if we are dealing with strictly layer 2 switches there isn’t any way for data to get from one VLAN to another. Now you might be asking yourself why you want to have data from one VLAN in a different VLAN. VLANs are used to make large networks smaller. What I mean by that is best described by an example. A large corporation might define VLANs for each floor or each department within their building. Not only does this make networks smaller and easier to manage but it severely decreases the size of the broadcast domain which makes the network faster. So, if each department is in their own VLAN, how do they get out to a shared internet connection, or to a shared file server? The answer is inter-VLAN routing. There are two main approaches to inter-VLAN routing. The oldest approach which is still commonly implemented is called “router on a stick”. Essentially you plug a router interface into a trunk port on one of your switches. Since a trunk port can see all of the VLANs you can configure a sub-interface on the router for each VLAN. If the router is capable of talking the same encapsulation that the trunk port is, the router can distinguish between VLANs and define a sub interface for each VLAN. The other method of achieving inter-VLAN routing is layer 3 switching. Layer 3 switches are essentially routers with a lot of ports which means that they are typically at least 2-3 times the price of normal layer 2 switches. The difference, of course, is that the switch can talk at the network layer. This means that we can define interfaces on each VLAN which is essentially the same as the “router on a stick” configuration except that you don’t need a router. In either case, clients on a particular VLAN would point to this VLAN interface (Cisco calls these Switched Virtual Interfaces (SVIs)) as their default gateway. When they try to access something off subnet ,such as a server or the internet, they would hit the interface on the switch. Since the switch/router sees all of the other interfaces as directly connected routes, it can switch the traffic to the appropriate resource residing in a different VLAN. This is why each VLAN should have its own unique network, otherwise inter-VLAN routing won’t work. Below is an example of how inter-VLAN routing might work with a layer 3 switch. Keep in mind, it’s crucial that devices in each VLAN use the SVI for their default gateway. If all the devices in the network don’t have the correct default gateway defined then traffic wont flow correctly.
I know that explanation was brief but the point I want to make sure you understand is that VLANs are a layer 2 concept. To route between them you need something that can talk layer 3.
So let’s summarize what we know so far.
- You can define multiple VLANs on the same switch
- By default all ports are members of the native VLAN (VLAN 1)
- Physical switch ports can be either access or trunk ports
- Access ports are designed for connecting to physical hosts and support a single VLAN configuration
- Trunk ports are designed for interconnecting switches and support all VLANs.
- Switches are interconnected using cross-over cables
- VLAN data traversing a trunk link is ‘tagged’ so that the receiving switch knows what VLAN the data should be put into. The exception is traffic in the native VLAN which is never tagged.
- Inter-VLAN communication can be achieved by use of a router or layer 3 switch.
Enough theory, let’s talk configuration
If you work with Cisco for as long as I have, you learn that the best way to configure a Cisco switch is through the CLI(Command Line Interface). Most newer switches have a GUI interface that can be used for configuration. In most cases, I find the GUI’s far more confusing to use than the CLI. This configuration section will only include commands used in the CLI however some of the terms/concepts will roll over to the GUI side as well.
-Insert your relevant information between <>
-Console prompts are show in green
-Notes are in blue
Note: All of these examples were done on Cisco 2950 switch
Enter Enable Mode
Notes: Enable mode is sort of like entering administration mode. Disable mode (what you start in) has limited command access. Enable mode gives you full access to all of the commands. You can tell you are in enable mode by the console changing from 2950> to 2950#. Part of the initial configuration of the switch should be configuring the enable password.
Password: <enter your enable password>
Enter Global Configuration Mode
Notes: Global configuration mode is the main configuration prompt.
Enter configuration commands, one per line. End with CNTL/Z.
Create a VLAN
Notes: Adding a VLAN to a switch is pretty straight forward. From the global configuration prompt enter the command ‘vlan’ followed by the number you wish to assign to it. After you press enter you’ll enter into vlan configuration mode and you can give the VLAN a name if you like. To return to global configuration mode type exit.
Ensure the interface is on
Notes: Cisco defines an interface as either up or administratively down. An interface that’s shutdown does not pass traffic. Interfaces that are shutdown will show the ‘shutdown’ configuration line under their interface configuration. To turn the interfaces up you negate the command by putting a ‘no’ in front of the command. This is an important concept as it is how you remove any configuration line from the config. Removing the shutdown command on the interface using the ‘no’ command prefix will turn the interface ‘up’ and allow it to pass traffic.
Configure an Access port and assign it to a VLAN
Notes: The first thing to do is to enter interface configuration mode. To do this type ‘int’ followed by the port which you wish to configure. On a standalone switch this will depend on the type of port it is (ethernet, fast ethernet, gigabit, etc..). In this case I want to configure a fast ethernet port. On a normal switch you’ll enter 0/<the number of the switchport you want to configure>. Once in interface configuration mode I tell the port to be an access port with ‘switchport mode’ command. Next I configure the port to be a member of VLAN 20 using the ‘switchport access’ command. Adding the port to VLAN 20 was an intentional mistake. What happened is interesting though. VLAN 20 did not exist previously in the VLAN database. The console picked up on this, displayed a message, and created the VLAN for me. While this is obviously another way to create VLANs it’s not good practice as now the VLAN doesn’t have a name which isn’t required but certainly helpful. To fix this you’d have to go back into VLAN configuration mode and name the VLAN. I think it’s much more straight forward to create the VLAN properly and then configure it on an interface.
2950(config-if)#switchport mode access
2950(config-if)#switchport access vlan 20
% Access VLAN does not exist. Creating vlan 20
Use the range command to configure a series of interfaces
Notes: Sometimes you need to configure a series of interfaces on a switch with the exact same configuration. If this is the case, it’s much easier to apply the same configuration to all of the ports at the same time. To do this you can use the interface range command.
2950(config)#int range faste0/1 – 24
2950(config-if-range)#switchport mode access
2950(config-if-range)#switchport access vlan 10
Configure a Trunk port and limit the VLANs on the trunk
Notes: In this example I configure fast ethernet 20 as a trunk port. The only difference between an access port and a trunk port is the ‘trunk’ and ‘access’ key word in the ‘swithport mode’ command. Additionally, I’m telling the trunk port to only allow VLANs 1,2, and 3 to traverse the trunk.
2950(config-if)#switchport mode trunk
2950(config-if)#switchport trunk allowed
2950(config-if)#switchport trunk allowed vlan 1,2,3
A full configuration example:
Now that we know how to do some of the major parts of the configuration let’s walk through configuring a switch from the ground up. I’m going to assume that you have a console cable connected between your computer and the switch and the switches configuration has been wiped. We’ll perform the following tasks
-Set the switches hostname
-Configure the enable secret
-Configure an interface on VLAN 1 for remote management
-Configure telnet password
-Configure two VLANs, one for normal data traffic and one for ISCSI traffic
-Assign half the ports to each VLAN
-Configure two ports as trunks for future switch expansion
Would you like to enter the initial configuration dialog? [yes/no]: no
Press RETURN to get started
Notes:Enter enable mode
Notes:Enter configuration mode
Enter configuration commands, one per line. End with CNTL/Z.
Notes:Change the switch name
Notes:Change the enable password
2950(config)#enable secret <password>
Notes:Configure a management interface and assign it an IP.
2950(config)#int vlan 1
2950(config-if)#ip address <IP Address> <Subnet Mask>
Notes:Set a password on the telnet lines
2950(config)#line vty 0 15
Notes:Create two VLANs and give them names
Notes:Select the first range of ports and add them to the Data VLAN
2950(config)#int range faste0/1 – 12
2950(config-if-range)#switchport mode access
2950(config-if-range)#switchport access vlan 2
Notes:Select the second range of ports and add them to the ISCSI VLAN
2950(config)#int range faste0/13 – 24
2950(config-if-range)#switchport mode access
2950(config-if-range)#switchport access vlan 3
Notes:Select the two gigabit ports and configure them as trunks. While its not necessary limit the trunk to only pass VLAN 2 and 3 traffic over the trunk link
2950(config)#int range gig0/1 – 2
2950(config-if-range)#switchport mode trunk
2950(config-if-range)#switchport trunk allowed VLAN 2,3
Notes:Save the configuration
Notes: Use the ‘show vlan’ command to display the VLANs that are locally defined. The output also displays which ports are assigned to which VLANs. Note that the two trunk ports aren’t assigned to either VLAN.
VLAN Name Status Ports
—- ——————————– ——— ——————————-
1 default active Gi0/1, Gi0/2
2 Data active Fa0/1, Fa0/2, Fa0/3, Fa0/4
Fa0/5, Fa0/6, Fa0/7, Fa0/8
Fa0/9, Fa0/10, Fa0/11, Fa0/12
3 ISCSI active Fa0/13, Fa0/14, Fa0/15,
Fa0/17, Fa0/18, Fa0/19, Fa0/20
Fa0/21, Fa0/22, Fa0/23, Fa0/24
<Some output omitted>
LANs are a relatively simple concept. However, their implementation is something that can be significantly harder to master. I hope that after reading this article you have a better understanding of how VLANs work on Cisco switches and their corresponding configuration.
As always, I love to hear feedback and answer any questions readers have. Feel free to leave a comment below or contact me directly at email@example.com