Let’s start off by showing you a picture of a network:
Look at this picture for a minute, we have many departments and every department has its own switch. Users are grouped physically together and are connected to their switch. what do you think of it? Does this look like a good network design? If you are unsure let me ask you some questions to think about:
What happens when a computer connected to the Research switch sends a broadcast like an ARP request?
What happens when the Helpdesk switch fails?
Will our users at the Human Resource switch have fast network connectivity? How can we implement security in this network?
Now tell me explain to you why this is bad network design. If any of our computers send a broadcast what will our switches do? They flood it! This means that a single broadcast frame will be flooded on this entire network. This also happens when a switch hasn’t learned about a certain MAC address, the frame will be flooded.
If our helpdesk switch would fail this means that users from Human Resource are “isolated”
from the rest and unable to access other departments or the internet, this applies to other switches as well. Everyone has to go through the Helpdesk switch in order to reach the Internet which means we are sharing bandwidth, probably not a very good idea performance-wise.
Last but not least, what about security? We could implement port-security and filter on MAC addresses but that’s not a very secure method since MAC addresses are very easy to spoof.
VLANs are one way to solve our problems.
Two more questions I’d like to ask you to refresh your knowledge: How many collision domains do we have here?
How many broadcast domains do we have here?
Remember our collision domains when we talked about hubs, bridges and switches? I told you that each port on a switch is a separate collision domain so in this picture we have a LOT of collision domains…more than 20.
What about broadcast domains? We didn’t talk about this before but I think you can answer it. If a computer from the sales switch would send a broadcast frame we know that all other switches will forward it. Did you spot the router on top of the picture? What about it…do you think a router will forward a broadcast frame?
The answer is that routers don’t forward broadcast frames so they effectively “limit” our broadcast domain. Of course on the right side of our router where we have an Internet connection, this would be another broadcast domain…so we have 2 broadcast domains here.
When you work with switches you have to keep in mind there’s a big difference between
physical and logical topology. Physical is just the way our cables are connected while logical is how we have set up things „virtually‟. In the example above we have 4 switches and I have created 3 VLANs called Research, Engineering, and Sales. A VLAN is a Virtual LAN so
it’s like having a “switch inside a switch”. What are the advantages of using VLANs?
A VLAN is a single broadcast domain which means that if a user in the research VLAN would send a broadcast frame only users in the same VLAN will receive it.
Users are only able to communicate within the same VLAN (more on this later).
Users don’t have to be grouped physically together, as you can see we have users in the Engineering VLAN sitting on the 1st, 2nd and 3rd floor.
In my example, I grouped different users in different VLANs but you can also use VLANs to separate different traffic types. Perhaps you want to have all printers in one VLAN, all servers in a VLAN and all the computers in another. What about VoIP? Put all your Voice over IP phones in a separate VLAN so its traffic is separated from other data.
If you have ever seen a Cisco IP Phone you might have noticed it has two interfaces:
There’s one to connect your IP Phone to the switch and another one to connect your computer to the phone. This will save you a port on your switch and the need to get another cable to your switch, but there’s also something else that’s pretty neat.
Your IP Phone will be in the Voice VLAN and the computer will be in the Data VLAN, so you only have one cable from the switch to your phone but traffic will be nicely separated by using VLANs.
This also gives us the possibility to use Quality of Service (QOS). This is a topic which is not on the CCNA but very important if you deal with VoIP, it will let you set priorities for certain traffic types. VoIP is very sensitive to delay and jitter (jitter is a variation in delay) and in order to make things smooth you need to make sure VoIP traffic will always be prioritized in case of congestion of your network, this is what QOS takes care of.
Now you have seen some of the advantages that VLANs can give us but this leaves us with one big question, take a look at the following picture:
So we have two switches and there’s a voice VLAN and a data VLAN. What happens when Phone A wants to call Phone B? Or if computer A wants to send something to computer B? Our switches will forward traffic but how do they know to which VLAN our traffic belongs? Let’s take another look at an Ethernet frame:
Do you see any field where we can specify to which VLAN our Ethernet frame belongs? Well, there isn’t! That’s why we need another protocol to help us.
Between switches, we are going to create a trunk. A trunk connection is simply said nothing more but a normal link but it carries all VLAN traffic.
As you can see we have computers on both sides and they are in different VLANs, by using
trunks we can make sure all VLAN traffic can be sent between the switches. Because our regular Ethernet frames don’t have anything to show to which VLAN they belong we will need another protocol.
There are two trunking protocols:
802.1Q: This is the most common trunking protocol. It’s a standard and supported by many vendors.
ISL: This is the Cisco trunking protocol. Not all switches support it.
Let’s take a look at 802.1Q:
Here’s an example of an 802.1Q Ethernet frame. As you can see it’s the same as a normal Ethernet frame but we have added a tag in the middle (that’s the blue field). In our tag, you will find a “VLAN identifier” which is the VLAN to which this Ethernet frame belongs. This is how switches know to which VLAN our traffic belongs. That’s not too bad, right? There’s also a field called “Priority” which is how we can give a different priority to the different types of traffic.
VLANs and Trunks…if you are following me so far you understand the basics, very good! Let’s take a look at the options we have to configure VLANs:
Static VLAN is the most common method; you just configure the VLAN yourself on the interface. Dynamic VLAN is where you have a VMPS server (VLAN Management Policy Server) which has a database of MAC address – VLAN information. It will check the MAC address of the computer and assign you the VLAN that it found in its database. Is this a good idea? Probably not since MAC addresses are easy to spoof. The third option is the voice VLAN which has to be configured separately on a Cisco switch. The link between the switch and the phone is actually a trunk!
There is a 4th method which is popular nowadays, you can use 802.1X and a RADIUS server to authenticate users and dynamically assign users to a VLAN. This gets even more interesting by adding NAC (Network Admission Control) to it. If your laptop doesn’t have all the latest Windows Updates and Anti-virus definitions you will be assigned to a special quarantine VLAN where you can only update your MAChine, once you are updated you will be moved to the correct VLAN. In the wireless chapter, I talk a bit more about 802.1X and Radius.
Back to our trunks…every VLAN that goes across the trunk will be tagged using the 802.1Q protocol but there is one exception. The native VLAN is the only VLAN that will not be tagged. That’s right it will be using regular Ethernet frames. So what do we use the native VLAN for?
Management protocols like CDP (Cisco Discovery Protocol) use the native VLAN. Remote management to your Cisco switch uses the native VLAN.
The default native VLAN is VLAN 1.
Now you have an idea what VLANs, trunks, and VTP are about. Let’s take a look at what this all looks like on our real switches:
Let’s start with a simple example. ComputerA and ComputerB are connected to SwitchA. First, we will look at the default VLAN configuration on SwitchA:
Interesting…VLAN 1 is the default LAN and you can see that all active interfaces are assigned to VLAN 1.
VLAN information is not saved in the running-config or startup-config but in a separate file called vlan.dat on your flash memory. If you want to delete the VLAN information you should delete this file by typing delete flash:vlan.dat. I configured an IP address on ComputerA and ComputerB so they are in the same subnet.
Let’s see if ComputerA and ComputerB can reach each other:
Even with the default switch configuration ComputerA is able to reach ComputerB. Let’s see if I can create a new VLAN for ComputerA and ComputerB:
This is how you create a new VLAN. If you want you can give it a name but this is optional. I’m calling my VLAN “Computers”.
VLAN 50 was created on SwitchA and you can see that it’s active. However no ports are currently in VLAN 50. Let’s see if we can change this…
First I will configure the switchport in access mode with the switchport mode access
command. By using the switchport access vlan command we can move our interfaces to another VLAN.
Excellent! Both computers are now in VLAN 50. Let’s verify our configuration by checking if they can ping each other:
Our computers are able to reach each other within VLAN 50. Besides pinging each other we can also use another show command to verify our configuration:
By using the “show interfaces switchport” command we can see that the operational mode
is “static access” which means it’s in access mode. We can also verify that the interface is assigned to VLAN 50.
Let’s continue our VLAN adventure by adding SwitchB to the topology. I also moved ComputerB from SwitchA to SwitchB.
I just created VLAN 50 on SwitchB and the interface connected to ComputerB is assigned to VLAN 50.
Next step is to create a trunk between SwitchA and SwitchB:
I try to change the interface to trunk mode with the switchport mode trunk command. Depending on the switch model you might see the same error as me. If we want to change the interface to trunk mode we need to change the trunk encapsulation type. Let’s see what options we have:
so this is where you can choose between 802.1Q and ISL. By default, our switch will negotiate about the trunk encapsulation type.
Let’s change it to 802.1Q by using the switchport trunk encapsulation command. As you can see the trunk encapsulation is now 802.1Q.
Now I can successfully change the switchport mode to trunk.
We can confirm we have a trunk because the operational mode is “dot1q”. Let’s try if ComputerA and ComputerB can reach each other:
Excellent! ComputerA and ComputerB can reach each other! Does this mean we are done?
Not quite yet…there’s more I want to show to you:
First of all, if we use the show vlan command we don’t see the Fa0/14 interface. This is completely normal because the show vlan command only shows interfaces in access mode and no trunk interfaces.
The show interface trunk command is very useful. You can see if an interface is in trunk mode, which trunk encapsulation protocol it is using (802.1Q or ISL) and what the native VLAN is. We can also see that VLAN 1 – 4094 are allowed on this trunk.
For security reasons you might want to limit the VLANs that are allowed on the trunk, we can do this with the allowed keyword:
This will remove VLAN 1-4094 from the trunk and only allows VLAN 1-50. As you can see only VLAN 1-50 is now allowed.
We can also see that currently only VLAN 1 (native VLAN) and VLAN 50 are active. Last but not least you can see something which VLANs are in the forwarding state for spanning- tree (more on spanning-tree later!).
Before we continue with the configuration of VTP I want to show you one more thing about access and trunk interfaces:
An interface can be in access mode or in trunk mode. The interface above is connected to ComputerB and you can see that the operational mode is “static access” which means it‟s in access mode.
This is our trunk interface which is connected to SwitchA. You can see the operational mode is trunk mode.
If I go to the interface configuration to change the switchport mode you can see I have more options than access or trunk mode. There is also a dynamic method. Don’t worry
about the other options for now.
We can choose between dynamic auto and dynamic desirable. Our switch will automatically find out if the interface should become access or trunk port. So what’s the difference between dynamic auto and dynamic desirable? Let’s find out!
I’m going to play with the switchport mode on SwitchA and SwitchB and we’ll see what the result will be.
First I’ll change both interfaces to dynamic auto.
Our administrative mode is dynamic auto and as a result, we now have an access port.
Once we change both interfaces to dynamic desirable we end up with a trunk link. What do you think will happen if we mix the switchport types? Maybe dynamic auto on one side and dynamic desirable on the other side? Let’s find out!
It seems our switch has a strong desire to become a trunk. Let’s see what happens with other combinations!
Dynamic auto will prefer to become an access port but if the other interface has been configured as trunk we will end up with a trunk.
Configuring one side as dynamic auto and the other one as access and the result will be an access port.
Dynamic desirable and trunk mode offers us a working trunk.
What do you think will happen if I set one interface in access mode and the other one as
trunk? Doesn’t sound like a good idea but let’s push our luck:
As soon as I change the switchport mode I see these spanning-tree error messages on SwitchA. Spanning-tree is a protocol that runs on switches that prevent loops in our network. Don’t worry about it now as you will learn about it in the next chapter.
Let me give you an overview of the different switchport modes and the result:
Make sure you know the result of these combinations if you plan to do the CCNA exam. I always like to think that the switch has a strong “desire” to become a trunk. Its wish will always be granted unless the other side has been configured as an access port. The “A” in dynamic auto stands for “Access”, it would like to become an access port but only if the other side also is configured as dynamic auto or access mode.
I recommend never to use the “dynamic” types. I want my interfaces to be in trunk OR access mode and I like to make the decision myself. Keep in mind that dynamic auto is the default on most modern switches which means it’s possible to form a trunk with any interface on your switch automatically. Some of the older switches use dynamic desirable as the default. This is a security issue you should deal with! If I walk into your company building I could connect my laptop to any wall jack, boot up GNS3, form a trunk to your switch and I’ll have access to all your VLANs…don’t sound like a good idea right?
This is what I recommend for trunk interfaces:
The negotiation of the switchport status by using dynamic auto or dynamic desirable is called DTP (Dynamic Trunking Protocol). You can disable it completely by using the switchport nonegotiate command.
This is what I would do for access interfaces:
For security reasons it’s a good idea to disable the negotiation of the switchport status and to configure the interface in access mode yourself.
One last thing about VLANs and trunks before we continue with VTP. I recommend changing the native VLAN to something else.
You can see that VLAN 1 is the default native VLAN on Cisco switches. Management protocols use this native VLAN so for security reasons it might be a good idea to change it into something else:
This is how we change the native VLAN.
You can see the native VLAN is now VLAN 10.
Question for you: Will the computers in different VLANs be able to communicate with each other? We separated them for a good reason but are they totally isolated?
Computers in different VLANs are still able to communicate with each other but you’ll need a router! In the example above I have two computers in two different VLANs.
Each VLAN has a different IP subnet. If the computer in VLAN 10 wants to communicate with the computer in VLAN 20 we’ll have to route between the two networks. Traffic will go from computer VLAN 10 towards the router and from the router back towards the computer in VLAN 20. This is what we call a router on a stick.
If you look at this picture you might be wondering if this makes any sense, our traffic goes from the switch to the router and from the router back to the switch. This is why nowadays you can also buy layer 3 switches. The routing functionality has been placed in the switch! Later in the book when we talk about routing I will show you how to configure the router on a stick.
This is all that I have for you about VLANs and trunking. We still have to look at VTP (VLAN Trunking Protocol) which can help you to synchronize VLANS between switches. Let’s say you have a network with 20 switches and 50 VLANs. Normally you would have to configure each switch separately and create those VLANs on each and every switch. That’s a time-consuming task so there is something to help us called VTP (VLAN Trunking Protocol). VTP will let you create VLANs on one switch and all the other switches will synchronize themselves.
Does VTP are all in on what we call a VTP domain.
We have one VTP server which is the switch where you create/modify or delete VLANs. The other switches are VTP clients. The VTP configuration has a revision number which will increase when you make a change. Every time you make a change on the VTP server this will be synchronized to the VTP clients. Oh and by the way you can have multiple VTP servers since it also functions as a VTP client so you can make changes on multiple switches in your network. In order to make VTP work you need to set up a VTP domain name which is something, you can just make up, as long as you configure it to be the same on all your switches. This is the short version of what I just described:
- VTP adds / modifies / deletes VLANs.
- For every change, the revision number will increase.
- The latest advertisement will be sent to all VTP clients.
- VTP clients will synchronize themselves with the latest information.
Besides the VTP server and VTP client there’s also a VTP transparent which is a bit different, let me show you an example:
Our VTP Transparent will forward advertisements but will not synchronize itself. You can create VLANs locally though which is impossible on the VTP client. Let’s say you create VLAN 20 on our VTP server, this is what will happen:
- You create VLAN 20 on the VTP server.
- The revision number will increase.
- The VTP server will forward the latest advertisement which will reach the VTP transparent switch.
- The VTP transparent will not synchronize itself but will forward the advertisement to the VTP client.
- The VTP client will synchronize itself with the latest information Here’s an overview of the 3 VTP modes:
Should you use VTP? It might sound useful but VTP has a big security risk…the problem with VTP is that a VTP server is also a VTP Client and any VTP client will synchronize itself with the highest revision number.
The following situation can happen with VTP:
You have a network with a single VTP server and a couple of VTP client switches, everything
is working fine but one day you want to test some stuff and decide to take one of the VTP clients out of the network and put it in a lab environment.
- You take the VTP client switch out of the network.
- You configure it so it’s no longer a VTP Client but a VTP server.
- You play around with VTP, create some VLANs, modify some.
- Every time you make a change the revision number increases.
- You are done playing…you delete all VLANs.
- You configure the switch from VTP Server to VTP Client.
- You connect your switch to your production network.
What do you think the result will be? The revision number of VTP on the switch we played with is higher than the revision number on the switches of our production network. The VTP client will advertise its information to the other switches, they synchronize to the latest information and POOF all your VLANs are gone! A VTP client can overwrite a VTP server if the revision number is higher because a VTP server is also a VTP client.
Yes I know this sounds silly but this is the way it works…very dangerous since you’ll lose all your VLAN information. Your interfaces won’t go back to VLAN 1 by default but will float around in no man’s land…
One more thing about VTP, let me give you another picture:
You see we have computers in VLAN 10, 20 and 30. The links between the switches are trunks using the 802.1Q protocol and carrying all VLAN traffic. One of our computers in VLAN 10 sends a broadcast frame, where do you think this broadcast frame will go?
Broadcast frames have to be flooded by our switches and since our trunks are carrying all VLANs, this broadcast will go everywhere.
However, if you look at the switch in the middle do you see any computer in VLAN 10? Nope, There’s only VLAN 20 there which means this broadcast is wasted bandwidth. By enabling VTP pruning we’ll make sure there is no unnecessary VLAN traffic on trunks when there’s nobody in a particular VLAN. Depending on your switch model VTP pruning is either turned on or off by default.
Let’s take a look at the configuration of VTP. I will be using three switches for this task. I erased the VLAN database and the startup-configuration on all switches.
Depending on the switch model you will see a similar output if you use the show vtp status command. There’s a couple of interesting things to see here:
Configuration revision 0: Each time we add or remove VLANs this number will change. It’s 0 at the moment since I haven’t created or removed any VLANs.
VTP Operating mode: the default is VTP server.
VTP Pruning: this will help to prevent unnecessary traffic on your trunk links, more in this later.
VTP V2 Mode: The switch is capable of running VTP version 2 but it’s currently running VTP version 1.
Let’s create a VLAN on SwitchA and we’ll see if anything changes…
My new VLAN shows up in the VLAN database, so far so good…
You can see that the configuration revision has increased by one.
Unfortunately nothing has changed on SwitchB and SwitchC. This is because we need to configure a VTP domain-name before it starts working.
Before I change the domain-name I’m going to enable a debug using the debug sw-vlan vtp events command. This way we can see in real-time what is going on.
You will see the following debug information on SwitchB and SwitchC; there are two interesting things we can see here:
The switch receives a VTP packet from domain “X” and decides to change its own domain- name from “NULL” (nothing) to “X”. It will only change the
domain-name if it doesn’t have a domain-name.
The switch sees that the VTP packet has a higher revision number (1) than what it currently has (0) and as a result it will synchronize itself.
Make sure to disable the debug output before you get flooded with information.
The revision number on SwitchB and SwitchC is now “1”.
The show vlan command tells us that SwitchB and SwitchC have learned VLAN 10 through VTP.
Since all switches are in VTP Server mode I can create VLANs on any switch and they should all synchronize:
Let’s create VLAN 20 on SwitchB and VLAN 30 on SwitchC.
As you can see all switches know about the VLANs. What about the revision number? Did it change?
Each time I create another VLAN the revision number increases by one. Let’s change the VTP mode on SwitchB to see what it does.
It’s now running in VTP Client mode.
Right now SwitchA and SwitchC are in VTP Server mode. SwitchB is running VTP Client
mode. I have disconnected the link between SwitchA and SwitchC so there is no direct connection between them.
I’ll create another VLAN on SwitchA so we can see if SwitchB and SwitchC will learn it.
I’ll call the new VLAN “Engineering”.
SwitchB learns about VLAN 40 through SwitchA.
SwitchC learns about VLAN 40 through SwitchB. SwitchB as a VTP client will synchronize itself but it will also forward VTP advertisements.
A switch running in VTP Client mode is unable to create VLANs so that‟s why I get this error if I try to create one.
What about the VTP Transparent mode? That’s the last one we have to try…
I’ll change SwitchB to VTP Transparent mode and the link between SwitchA and SwitchC is still disconnected.
This is how we change SwitchB to VTP Transparent mode.
Let’s create VLAN 50 for this experiment on SwitchA.
It shows up on SwitchA as expected.
It doesn’t show up on SwitchB because it’s in VTP transparent mode and doesn’t synchronize itself.
It does show up on SwitchC! A switch in VTP Transparent mode will not synchronize itself but it will forward VTP advertisements to other switches so they can synchronize themselves.
What will happen if I create a VLAN on SwitchB? Let‟s find out!
We can create this new VLAN on SwitchB without any trouble. It‟s in VTP Transparent mode so we can do this.
VLAN 60 doesn‟t show up on SwitchA and SwitchC because SwitchB is in VTP Transparent mode. SwitchB will not advertise its VLANs because they are only known locally.
Is there anything else you need to know about VTP Transparent mode?
There’s a difference between VTP Transparent mode VS Server/Client mode. If you look at the running-config you will see that VTP Transparent stores all VLAN information in the running-config. VTP Server and Client mode store their information in the VLAN database (vlan.dat on your flash memory).
If you understand the difference between VTP Server, Client and Transparent mode…good! There’s one more thing I want to show to you about VTP.
I’m going to demonstrate the danger of VTP as I explained before. A VTP client can overwrite a VTP server if the revision number of the VTP client is higher. I‟m using the same topology but this time SwitchA is the VTP Server and SwitchB and SwitchC are VTP Clients.
First I change the domain-name and configure the correct VTP modes.
Next step is to create a couple of VLANS.
I will configure one (random) interface so it’s in VLAN 10.
All switches currently have the same revision number.
All switches are up-to-date with the latest VLAN information. Note that Fa0/1 on SwitchA is in VLAN 10 at this moment.
Now I’m going to shut down the interfaces on SwitchC connecting SwitchA and SwitchB. This could happen if you want to remove a switch from your production network and temporarily use it in a lab.
I will change SwitchC from VTP Client mode to VTP Server mode:
Easy enough! Let’s add some VLANs:
After adding the VLANs you can see that the VTP revision number has increased.
After playing with my lab I’m going to erase the VLANs and change the switch back to VTP Client mode so we can return it to the production network.
Note that after deleting the VLANs the VTP revision number increased even more.
Let’s do a “no shutdown” on the interfaces and return SwitchC to the production network.
!! this doesn‟t look good. SwitchA and SwitchB now have the same revision number as SwitchC. This is the moment where you start to get nervous before you type in the next command…
OUCH! All VLAN information is lost since SwitchA and SwitchB are synchronized to the latest information from SwitchC.
This is the moment where your relaxing Monday morning turns into a horrible day…if you are lucky the support ticket system doesn’t work anymore…if you are using VoIP than
there’s a chance your phones don’t work anymore and you just have to wait till a mob of angry users will ram your door because they blame you for not being able to reach Facebook anymore…
Ok maybe I’m exaggerating a bit but you get the idea. If you have a big flat network with lots of switches and VLANs than this would be a disaster. I would advise to use VTP Transparent mode on all your switches and create VLANs locally!
If you do want to use VTP Server / Client mode you need to make sure you reset the revision number:
Changing the domain-name will reset the revision number.
Deleting the vlan.dat file on your flash memory will reset the revision number.