Musings of a Wayfarer

Cisco VLAN Basics

In my recent posts on Cisco switching, I have covered the essential concepts of forwarding, filtering and flooding, and explored basic configuration of security, interfaces and trunking. It is time to move on to a subject that seems to be the bane of many students: virtual local area networks, or VLANs. Much of the networking literature appears, to my mind, a little too eager to skip the simple nature of VLANs and begin configuring inter-VLAN routing. As a result, students end up confused about what is limited to layer 2 and what is added by layer 3.

Hopefully, I can cut through some of the haze. It’s worth saying up front that VLANs are layer 2 (data-link) beasts. They are created on switches, live on switches and die on switches. The time to bring in layer 3 is when you need the hosts in one VLAN to be able to communicate with those in another. I’ll get to that soon, but let us first consider how these things work and what benefits they bestow.

In this simple schematic, we have two separate switches with a couple of hosts attached to each. Imagine that VLANs do not exist; these switches work in the ordinary way, forwarding and filtering frames as required. George and John can communicate, as you might expect, as can Paul and Ringo. But no frames can pass between the two switches, since there is no interconnecting link. VLANs allow us to achieve exactly the same result within a single switch. Here is the same concept illustrated with two VLANs, numbered 1 and 2:

To see how this works, let’s follow a couple of frames. The switch has just started up and its MAC address table is empty. George sends a frame to John. The frame enters the switch on port Gi0/1, which has been configured to belong to VLAN 1. Thus, the switch considers the sender to be in this VLAN. (Note that hosts know nothing about VLANs; all the configuration is done on the switch port to which they attach.)

Now the switch tries to match the destination MAC, John’s, with an entry in its table, but there is no match. When we covered switching basics, you saw how the switch proceeded to send the frame out of all active ports except the one it arrived through. This process is called flooding. Well, now that VLANs are involved, the switch floods the frame only to the ports in the same VLAN as the incoming frame. In this scenario, only John, on port Gi0/2, is in the same VLAN, so he gets a copy. Of course, the switch also records the sender’s address (George’s) and associates it with port Gi0/1.

When John responds, his frame enters the switch on port Gi0/2, which is in VLAN 1. The switch compares its destination MAC against the table and finds a match: George is found via port Gi0/1. Now the switch asks a very pertinent question: is the destination port in the same VLAN as the incoming frame? In this case, the answer is yes. So the frame is sent to George and nowhere else. As expected, the switch notes the sender’s address (John’s) and associates it with port Gi0/2.

When we had two separate switches, John and George were isolated from Paul and Ringo. Let’s see how this is enforced by the separate VLANs. George sends a frame to Ringo. It enters the switch on port Gi0/1, which is a member of VLAN 1. Now, assume the switch has built a full MAC address table, and knows Ringo resides out of Gi0/4. It therefore matches the destination address to that port. However, port Gi0/4 is in VLAN 2, so the switch filters the frame. Ringo never receives a copy.

In this manner, VLANs allow a switch two be split into multiple ‘mini’ switches. Each one has hosts connected, but they are isolated at layer 2. Devices within the same VLAN can talk, but a device cannot talk to another if it’s part of a different VLAN. There are two immediate benefits to this. First, broadcast traffic is limited to each VLAN. Switches traditionally flood broadcast frames (whose destination MAC is FF-FF-FF-FF-FF-FF) to every other active port; but broadcasts are now limited to those ports in the same VLAN as the sender. Devices can be grouped by function: for instance, all the accounting department systems can be attached to VLAN 2, and all the marketing systems to VLAN 3. It is unlikely that a broadcast by an accounting application needs to be processed by the marketing devices, so why forward it to them? This just wastes bandwidth and processing time.

The second benefit is increased security. Devices and their traffic are now sequestered at layer 2. The marketing devices cannot see, deliberately or accidentally, the frames exchanged by the accounting systems.

Enough of the theory. Let’s configure a multi-VLAN scenario with a Cisco switch. The main point I’d like to drive home about VLAN configuration on switches is how easy it is. It involves just two steps: create the VLANs and assign ports into them. All Cisco switches nowadays support VLANs and, by default, every port belongs to VLAN 1. This why you can simply plug and play; with every port in the same VLAN, all devices can communicate out of the box. Moreover, VLAN 1 is always part of a switch’s VLAN database and cannot be deleted. It is usually referred to as the default VLAN. The first thing you’ll want to do is see a switch’s VLAN database, in order to discover which VLANs already exist:

This clearly shows the default VLAN, with a number of 1. Also present, by default, are a few other VLANs you’ll not need to worry about, but which cannot be deleted either. VLAN 1 is active and all the switch’s ports are currently assigned to it. Now we can go about creating some VLANs of our very own. First, we will create a VLAN 2 for accouting:

From global configuration mode, enter the command vlan 2 to create a new VLAN in the database with this number. You can use any number from 2 to 1001 for standard VLANs, which provides a lot of scope. As soon as this command is entered, the switch will helpfully inform you that the new VLAN was added, with its default name of VLAN0002. You are then immediately placed into configuration mode for the new VLAN—note the prompt. At this point, the VLAN is given a friendly name for easier administration. Finally, the changes are committed by issuing the exit command. In most cases, switch commands execute instantly; but when configuring a VLAN, you must use the exit command to update the database. Here is the output from that last show command:

Using the interface range command, you can target multiple ports at the same time, which saves a lot of agro when doing this kind of thing. Next, the switchport mode access command ensures that these ports are access links, not trunks. This is the default mode for a switch port, but there’s no harm in confirming it. Finally, the ports are assigned to VLAN 2 via the switchport access vlan 2 command. A rerun of show vlan clearly indicates that interfaces Gi0/1 and Gi0/2 are now members of the Accounting VLAN, numbered 2.

It is now quite trivial to create another VLAN for marketing—this one numbered 3—and assign ports Gi0/3 and Gi0/4 into it:

The output shows the port is in access mode and that the access VLAN is number 3. You can safely ignore the various settings that pertain to trunking, since the port is not operating as a trunk. One point of interest is the reference to a Voice VLAN, which is currently set to none. If you have a device, like a PC, that is plugged into an IP phone, and this phone is, in turn, connected to the switch, then it is possible for the port to be in two VLANs simultaneously: a data VLAN (for the PC) and a voice VLAN. I’ll cover this scenario in a future post.

This is all there is to creating and using basic VLANs. The switch will now treat ports Gi0/1 and Gi0/2 as if they were on their own mini-switch, and do the same with Gi0/3 and Gi0/4. Traffic can pass within a VLAN, but the two VLANs cannot send frames to each other. Any attempt to send a frame from one VLAN to another is filtered by the switch. It is at this point we need to bring layer 3, the network layer, into play, since it provides the means for getting traffic from one VLAN into another. We must use a router and place the devices in each VLAN into their very own subnets. But, before we get there, I want to cover a few more layer 2 VLAN concepts.