- [Instructor] In this video let's talk about VTP.
Now, technically VTP is not on the encore blueprint
but I still think it's very important that you know this.
It might pop up in your real world scenarios.
VTP stands for VLAN Trunking Protocol,
however, some other Cisco literature says,
it stands for VLAN Trunk Protocol.
So you can use those interchangeably.
But personally I'm not a big fan of the name
because VTP is not a trunking protocol.
The reason that trunk is in the name VTP,
is that this is a protocol that runs over trunks.
Here we have all of our switches interconnected with trunks
and the purpose in life of VTP is to allow us
to create, modify or delete a VLAN on one switch,
and have that change propagated
throughout our switched infrastructure,
so we don't have to make changes
on each switch individually.
For example, here on switch SW1 maybe I create VLAN 100.
Well if we have VTP configured
that switch SW1 can send VTP advertisements
over its trunk links, down to switches SW2 and SW3.
And they're going to update their VLAN database
and they're going to create VLAN 100.
Then they're going to forward the VTP advertisements
down to switches SW4 and SW5.
And then they have VLAN 100 created in their VLAN database.
And that's the quick overview
of what VTP is going to be doing for us.
But let's get a bit more detailed.
A switch running VTP can operate in different VTP modes.
Let's talk about these different modes.
The first mode is server mode.
Here, we're able to create a VLAN on a switch
configured for server mode.
We can delete, we can modify VLANs.
But just because we're a server doesn't mean
that we cannot learn from someone else.
If we receive a VTP advertisement from another switch,
yeah we might update our VLAN database
based on that advertisement.
That begs the question,
how do I know that,
that advertisement I just received is more authoritative
than my own VLAN database?
Well, we're going to have something called
a configuration revision number.
And whoever has the highest configuration revision number
is going to be considered the most authoritative source
of VLAN information.
So if I receive a VTP advertisement
and let's say its configuration revision number is 10,
but my local VLAN database
has a configuration revision number of nine,
then I'm going to believe the advertisement.
And the server mode switch can forward VTP advertisements
that it receives.
And if we make a change
directly on that switch configured as a server
then it can originate VTP advertisements.
Contrast server mode with client mode.
With client mode we cannot go to the command line interface
of that switch and say,
I want to create or modify or delete a VLAN.
However, that switch does have a VLAN database
and we can update that VLAN database
based on advertisements that we receive.
And if we receive an advertisement,
then we're going to forward that advertisement out
our trunk ports.
And we can originate VTP advertisements.
How is that possible?
If I'm not able to make a change,
how can I originate a VTP advertisement?
This is a common point of confusion.
In fact, some people have put their switches in client mode
to make it, quote unquote,
safe to add them to an existing network.
And it's led to some disastrous results.
We'll talk about that coming up in just a few moments.
But client mode we cannot go directly to that switch
and create, modify or delete a VLAN.
And maybe we have a switch that doesn't really want
to participate in this exchange of VTP advertisements.
We can have a switch in transparent mode.
Here we can go to the command line interface
on that switch and we can create, delete, modify VLANs,
but if we receive a VTP advertisement,
we don't make any updates based on that.
We don't originate any VTP advertisements.
We don't tell anybody what we have configured on our switch
and we don't update our switch based on information
we receive from anyone else.
However, if I receive an advertisement
from a neighboring switch,
I'm not going to stop it,
because somebody downstream from me,
may want that information.
So we still can forward VTP messages that we receive.
And we have different versions of VTP
that we'll be talking about in a few moments.
But in version three,
there's support for something called a primary server.
So instead of just a server mode,
we can have a primary server.
This is only something available in VTP version three.
And it is the only switch in our topology
that can create, delete or modify VLANs.
This can help overcome that danger
that I was telling you about,
that we'll discuss in a moment.
Specifically, it can prevent the accidental overwriting
of a VLAN database.
Now let's take a look at an example
using some of these different VTP modes.
Let's say that switch SW1 is running in server mode,
SW2 is in client mode,
SW3 is a transparent mode switch,
SW4 is in server mode,
SW5 is client mode.
And let's say I go to switch SW1 and I create VLAN 100.
Well, we're going to send VTP advertisements
down to switches SW2 and SW3 over those trunk links.
And SW2 which is in client mode,
it's going to update its VLAN database
and it's going to create VLAN 100 on its switch.
But switch SW3 is in transparent mode,
it's not going to update its VLAN database.
But it's not going to stop the advertisement.
Both switches SW2 and SW3,
they will forward on that VTP advertisement
over their trunk links down to switches SW4 and SW5.
And one is in server mode and one is in client mode.
And they both create VLAN 100 in their VLAN database.
So we can have multiple servers in a network,
unless we are running VTP version three,
where we have a primary server.
Now let's talk a bit more about that caution,
where we might accidentally overwrite the VLAN database
on all of our switches.
Here, I'm showing you the configuration revision number
of all the switches in this topology.
And everybody should agree,
once we reach a steady state
and everybody agrees on what the VLAN database looks like,
every switch, except the transparent mode switch,
every switch is going to agree on the VLAN database,
and they're going to agree on the configuration
revision number.
That way if I go to a switch like SW1
and I create a new VLAN,
that will increment the configuration revision number from,
in this case 12 to 13.
And when that advertisement goes out to switches,
SW2,
SW4
and SW5,
they're going to say, oh 13 that's more authoritative
than my configuration revision number of 12.
So I'm going to update my VLAN database based on that.
Now notice a transparent mode switch
has a configuration revision number of zero.
Now here's the danger I was telling you about.
Imagine this scenario.
Imagine this is my company's production network
and we just got a brand new switch in.
And I've been playing with this switch,
trying out some new quality of service features perhaps.
And I've been adding, deleting, modifying VLANs
and now it's time to put this switch into production.
And it will say that this is going to be switch SW6.
And I don't want to cause a disruption
to the existing VLAN database,
so I think I'll switch this to client mode,
but notice that this switch,
which has just been sitting on my desk,
based on all the changes I've made,
it's got a configuration revision number of 25.
Is that a problem?
It sure is.
As soon as I plug this into the topology
then it's going to send out its VTP advertisement,
assuming that's a trunk connection between SW6 and SW4.
And it is going to
blow away the existing VLAN databases on our switches,
except for the transparent mode switch.
And those switches are now going to have
configuration revision number 25.
They're going to have the VLAN database
that I configured on my desk,
which does not mirror what's going on
in the corporate network, at all.
This is a big danger.
So how do we avoid falling into that trap?
Well it's not enough just to have a switch in client mode
because that does not reset
the configuration revision number.
It's not even enough to delete your VLAN database.
There's a file in the flash of your switch
called vlan.dat.
Even if you delete that,
that doesn't get rid of your configuration revision number.
Here's what I normally do.
Before adding a switch to a network like this,
I would do two things.
I would first set the mode to transparent.
And by doing that,
that's how we set the configuration revision number
to a zero.
Then I would delete that VLAN database
just as an extra caution,
it's probably not necessary,
but I like to do that just as an extra caution.
And then maybe I set it to client mode.
Now when I plug into the network,
I'm not going to have the authoritative
configuration revision number
because I reset it to a zero
by switching it temporarily to transparent mode.
And we also mentioned a moment ago
that if we are running VTP version three,
that could protect us against this as well,
because with VTP version three,
we can have a primary server.
We can have just one switch
that's able to create, modify or delete VLANs.
So the addition of this extra switch in the network
is not going to inadvertently destroy
our existing VLAN databases.
In fact, let's talk about some of the different
version enhancements.
What we've been talking about so far
is generally true for VTP version one.
But what extra things do we get
with VTP versions two and three?
First, let's consider VTP version two.
The first one isn't that impressive these days.
It supports token ring VLANs.
Well, I haven't had to work with a token ring VLAN
since, I think back in 2001 when I took my CCA lab,
way back then there was Token Ring on the lab.
Yeah, you're probably not going to be running into that much
in today's networks.
But with VTP version two a transparent mode switch
if it receives an advertisement,
it's not going to check to see if that advertisement
matches its VTP domain configuration
or its version information.
It's just going to forward it on.
Now with VTP version three,
we mentioned that it supports that primary server,
where we have that one switch
on which we can create, delete or modify VLANs,
and that's going to prevent somebody from adding a switch
intentionally or accidentally,
that can have a higher configuration revision number
and delete everything on all the switches.
We want to prevent that.
Also, something we could not do
with VTP versions one and two,
we could not support extended VLANs
in the range of 1006 through 4094.
We can with VTP version three.
It also supports private VLANs,
it supports multiple spanning tree,
it improves authentication.
You can even turn it off with version three.
You can turn the mode to off.
And the great news is,
since there's so much of VTP version two out there today,
VTP version three is backwards compatible
with both versions one and version two.