Configuring VLANs – CompTIA Network+ N10-006 – 2.6


A switch’s VLAN configuration can provide the network administrator with additional network segmentation options. In this video, you’ll learn about configuring VLANs, configuring trunked links, and the benefits of using VTP.

<< Previous: Patches and UpdatesNext: Spanning Tree Protocol >>

Many of today’s switches support a capability called Virtual LANs or VLANs. VLANs allow us to take the individual interfaces on a switch and separate them out into logical groups. We could accomplish the same thing by adding multiple physical switches and plugging people into their own physical switch, but instead of having all of that additional hardware, we can do all of that segmentation inside the switch itself. With VLANs, you’re effectively creating individual subnets for these different devices, just the same as if you had separate individual physical switches.

So the same limitations are in place. If you need to communicate between one VLAN or another, you’re going to need a router to perform that function. This layer 3 device then is going to be the gatekeeper. Many people will put a router or even a firewall between all the different VLANs and then be able to have very granular control over what traffic is passing between the individual VLANs. VLANs are often grouped together by function.

So there may be a VLAN for shipping and receiving or for marketing or your VLANs may be organized by particular projects that people are working on. The goal is to have people as close as possible to the resources they need. So the marketing department would generally have the marketing servers on the same VLAN. The shipping and receiving team would have the same shipping and receiving resources all located on their private VLAN. We’re generally going into a switch and configuring specific interfaces to be members of specific VLANs, but if you have a network access control device, you can even automate that process.

When someone is logging into the network, the NAC will recognize that user, it will understand what group that user belongs to, and change the interface on the switch so that that person is on their specific VLAN. When you’re configuring the VLAN in your switch, you would look at all of the different interfaces, you would identify what users are connecting to what interfaces, and then you configure the switch to put that user on a particular VLAN. VLAN numbers can range between 1 and 4,096, and very rarely are we using that many VLAN on an individual switch.

In my example, I’m going to use four separate VLANs, for example. In this particular case, I have a switch and I’ve configured a number of interfaces already for a single VLAN. Maybe this is the marketing group. I’ve assigned those with a red color. And inside of my switch I would put each one of those interfaces on the same VLAN.

For shipping and receiving, I would identify those users. Perhaps those are the green users. And I would assign those to a completely different VLAN. Then I also perhaps have a manufacturing group. I can assign those interfaces inside of the switch and perhaps also an executive team.

And I’ll assign those also on the switch. So you can see visually here there are many different departments that are all working on this switch, but each one of these VLANs is a completely separate subnet. None of these are communicating to each other unless I enable some layer 3 functionality that’s either built into the switch or that is external to the switch so that all of these VLANs can communicate from one to the other. In many environments, you don’t simply have a single switch, of course.

There are many different switches and each one of these switches may have people connected to it from the marketing department and shipping and receiving and manufacturing and the executive team. So you may need to have some way to extend VLANs between switches. And we do that with something called trunking. With trunking, we’re effectively tunneling this VLAN information from one switch to another so that wherever anybody’s connected to whatever switch they’re connected to, they’re still on their local VLAN with all of their local resources.

The standard that specifies this tunneling method between switches is called 802.1Q. You’ll sometimes hear people refer to this as a dot one Q configuration. Each packet is going to have a header in front of it that we send through the trunk and on the other end, the switch removes that header and places that information into the proper VLAN. Even though we’re sending this tagged information between switches, we can also send information between switches that is normal network traffic without any of these 802.1Q tags. We call this the native VLAN.

And any communication that is going between switches over the native VLAN will not be subject to any of the tunneling or headers on the dot one Q trunk. Let’s look visually at how we can accomplish this trunking. In this particular configuration, I have two switches. Each one of the switches has a VLAN 100 and a VLAN 200. And without any type of connection between these two VLANs, can’t communicate with each other on the individual switches.

So we’re going to extend a cable between the two and plug it into an interface on each switch, and we’re going to configure that interface as an 802.1 trunk. And we’re going to configure that interface to also support VLAN 100 and VLAN 200 on both of these switches. So if there’s any traffic from VLAN 100 that needs to go from this switch to the other, this trunk interface will grab that information, tag it as VLAN 100, send it through this link.

On the other side the switch receives that traffic, identifies that as being tagged with VLAN 100, removes the tag, and then puts it on to the VLAN 100 on this switch. To send traffic in the other direction, the exact same process is performed in reverse to the other side. All the information going through this particular link that is tagged will be tagged with a VLAN 100 or VLAN 200 associated with it. One of the challenges you have with these VLAN configurations is that you have to do them on every single switch. And if you have two switches, it’s not that big of a problem.

But if you have 100 switches, it becomes more of a management challenge. You can, of course, go to each individual switch, log into that device, manually configure the interfaces, and then log out, log on to the next one, and repeat the process. If you add a new VLAN into your network, you’re going to have to go to every single switch and configure that switch to support that new VLAN. In large environments then we may want to do this automatically.

Cisco thought of this and created a trunking protocol called VTP. Stands for VLAN Trunking Protocol. And it’s an automated process for configuring your switches from one central switch. And those changes would be pushed down to individual switches automatically. There’s also a more standards-based protocol that accomplishes this function called Multiple VLAN Registration Protocol or MVRP.

If you’re non-Cisco, you may be using MVRP to accomplish effectively the same thing. If we aren’t running VTP, we will log into each switch individually. The switch at the top, then we’ll move over and configure the second switch, then we’ll configure the third, and the fourth, and finally the fifth switch. And hopefully we got everything right and we don’t need to make changes again, because if we need to add something, we’d have to repeat that process over again for every single switch.

If we’re using VTP, we generally configure everything on one central switch. That switch is then configured to take all of those changes and pass them down to all of the other devices. That way we don’t have to log into individual devices to make this work, we can simply go to one place, make our change, and that change is going to propagate itself to every other switch in our environment.