VTP, VLAN Trunking Protocol. It's not an exam objective. It's not. But it is one of those topics that could show up on the certification exam either as a distractor or potentially as the real answer.
Therefore, it's really important for us to have a fundamental understanding of VTP, VLAN Trunking Protocol, what it is, what it's not, and some of the dangers behind it.
So that way if you are running it in your organization, whether you know or not, the end result is you might want to make a few adjustments to it to make sure you are as safe and secure as you possibly can be.
So when it comes to VLAN Trunking Protocol, what are we dealing with? We are dealing with a protocol that has the ability to support the auto propagation of VLANs across what we call in this case a VTP domain.
So your VTP domain is a collection of switches that are allowed to share VLAN information with each other. That's what a VTP domain is.
So essentially you put the switch in the same VTP domain as this one, this one, this one, then they can exchange VTP messages with each other.
Now why would we exchange VTP messages with each other? So we can share our VLAN database information with each other.
Now this was a protocol that was designed back in the day. What do I mean by back in the day? Well let's go back to this picture that we drew a little earlier today.
Remember when we said there was a time in our lives when we had our entire environment was Layer 2?
And so Cisco created a proprietary protocol called DTP for their own environments. That was a plug and play technology. DTP allowed two switches when connected together to automatically form a trunk with each other.
Now what else has to happen in this entire environment for all of this to work? Every single switch needs to know every single VLAN.
Everyone, you got a thousand switches, they all must be configured with the same VLAN information or else what would happen? They can't pass traffic for that VLAN.
So it's a lot of work to configure that many switches with all those VLANs. But also if you added another switch to the environment, so let's say I connected another switch here.
Trunks formed automatically using DTP. With VTP, VLAN trunking protocol, this switch would tell this switch all of the VLANs.
So if you had 50 VLANs configured here, this switch would now know all 50 VLANs. That's what VTP does for us.
So why is it called VLAN trunking protocol? Because it only works over trunk links. That's it.
So VLAN trunking protocol is about sharing VLANs over existing trunk links. That's where the name comes from. It's honestly a pretty bad name.
Because it has nothing to do with trunking. It uses trunks in order to pass the information.
So modern day networks don't look like this. So if we erase all of this, what do we have typically? We might have our environment like this today.
Oh, all of this is layer three, even the entire data center today.
Up here, what do we have? We've got layer two. Down here, we've got layer two.
So are there typically going to be a lot of VLANs here?
Not really. If I add another switch, could I easily create those VLANs on the new switch instead of relying on VTP?
If I add a VLAN to this layer two environment, could I easily add the VLAN to all my switches? Probably.
So there is a balancing point here. That balancing point is do I really need VTP or not? Do I really need DTP or not?
So we know that with DTP, if I'm configuring a switch to be a trunk, then more than likely that link is going to be a trunk forever and ever and ever.
So might as well just manually say switch port mode trunk, we're done. Switch port no negotiate.
But now the question about VTP is, well, is it going to make my life easier as an admin?
Whereby if we want to add now VLAN 50 to this environment, I go to this switch, type in VLAN 50, and then that gets automatically shared with the other switches.
If that's what you want to do, then fine, you need VTP.
But if you have the ability to maybe have a script to configure the VLANs on all those switches you could, or if you want to log in all of them and configure them, it's up to you.
So this is one of those protocols where it's, you know, some people love it, some people hate it. It's one or the other.
And the reason why people hate it is because of how dangerous it could be.
Or on how unnecessary it is for them to have to learn another thing and run another thing in their environment.
So with VTP, remember, this is Cisco proprietary.
So if you have some non-Cisco switches connected to Cisco switches, VTP is not going to help you out.
Same thing with DTP.
These are Cisco proprietary protocols, meaning all your devices are going to have to be Cisco in that environment for it to work.
So we support the auto-propagation of VLANs between the switches in the same VTP domain across our trunk links.
VLANs are going to be written in the VLAN database, stored in Flash, that vlan.dat file.
Which means by default, if you need something like VLAN 2000, well, that is in the expanded range of VLANs.
Well, VTP version 1, VTP version 2 is not going to support that.
Server mode is not going to support that.
Client mode is not going to support that.
So you're going to have to change modes, change versions, all these different things.
We're going to talk about that a little later on.
Because those are the things I want you to know for the exam.
I've got a page for it.
So also we have to realize that the domain name is null by default on your switch.
This is where the dangers come into play.
Because let's say you've inherited a network and nobody's ever used VTP in that network.
It is possible that you are vulnerable right now if nobody adjusted the default values of VTP.
When you're adding a new switch to your environment, or maybe an old one off the shelf and you're repurposing it.
You've set it back to factory default settings.
Again, domain name null.
What does that mean?
Well, let's take a peek in our live environment about what that means.
If we type in show VTP status, you're going to see my VTP domain name is null.
It means nothing.
It means blank.
What you need to realize is that when your domain name is null, your switch is trying really hard to join a domain.
It wants to be part of a domain.
And that's the way it's designed.
Now, is it actively seeking to join a domain?
No, it's not.
But if somebody comes along and says, hey, I'm part of a domain, this switch will go, oh, let me join you.
And it'll jump on board.
Regardless of whether it's a valid VTP domain name or not.
Because it's plug and play.
Remember when it was created, it was a time when plug two switches together.
DTP forms a trunk.
VTP then runs.
So you automatically join the existing VTP domain and you learn all the VLANs.
That's why it behaves this way.
So null means if somebody I get connected to is part of a domain, I will join their domain and learn all their VLANs and synchronize my VLANs with them.
So just picture a scenario where somebody connects a rogue switch to your switch.
And your switch is not part of a domain.
But the rogue switch is part of a domain.
Does that mean your production switch in your production environment would join that switch's domain?
Well, if that switch, when connected to this switch, successfully formed a trunk link, then yeah, absolutely, because it's part of a domain.
What does that then mean?
All of its rogue VLAN information is now going to be on my switch.
Now what about all my other switches?
Well, of all my other switches, domain names are null as well.
Guess what?
They will all then join that domain and all synchronize their databases.
And therefore, we now have a corrupt VLAN database and nobody can get any work done.
So if you have any switches in your environment that don't have a domain name, you might be vulnerable to that type of scenario situation.
Which could be a resume generating event for you.
Could be, I don't know.
Let me show that for you.
What we're going to do here is we are going to go to DSW-1 and type in show VDB status.
Again, null.
Let's go to DSW-2.
Show VDB status.
Again, null.
Let's go to ASW-2.
Show VDB status.
Now remember, we have trunk links configured between all the devices because we've already configured them before.
Again, null here.
So what we're going to do is we're going to go to ASW-1 and I'm going to type in VTP domain ROGUERO.
Just for fun.
And what I want you to realize is that we have now all my other switches have automatically joined that domain.
Incredible.
Why? Because that's the way they're designed to behave.
So if ASW-1 had a corrupt, bogus, not correct VLAN database, then all of those switches would now have that same bogus VLAN database.
Which could be bad.
For example, if I type in show VLAN brief right now, we'll see that we have which VLANs?
1, 10, 20, 50, 200.
Let's go ahead and say VLAN 100.
100.
Exit.
So I added VLAN 100 to ASW-1's database.
And you'll see it's in ASW-1's database.
But let's go over to ASW-2 right now.
It's also in this database now.
Let's go to ASW-1.
It's also in this database.
So you can see how being part of the same VTP domain is very beneficial.
But if you're not protecting your VTP domain, it's very dangerous.
So if you have any switches right now, folks, that are not part of a VTP domain, I encourage you to come up with a plan and follow your change management practices to at least get a domain name configured on those switches.
That is going to then protect them because once you're part of a domain, you're not going to join some other domain unless you're forced to join it by me configuring the domain name.
So for example, if on ASW-2 right now I type in VTP domain is ENCOR.
If we go to ASW-1 right now, you'll see that it's still in the rogue VTP domain.
So once you're in a domain, you're not going to want to change that domain.
But now that this device is receiving messages from DSW-2 that says it's from the rogue domain, it's just going to ignore those messages.
So you ignore messages from somebody in a different VTP domain than you are in.
So at a minimum, you should have a VTP domain name configured, at a minimum.
I'm going to change all of them.
And don't forget, you're only going to share and synchronize your databases with those that are in the same domain.
So let me go ahead and change all these to VTP domain ENCOR so that way they're all part of the same VTP domain.
So you're all part of the same VTP domain.
Now, the thing is that a rogue device could still enter your domain, enter your environment.
And if that rogue device has the ability to form a trunk link with your switch, and it has the same domain name, then it can still infect your environment, right?
So what's the other thing you want to do?
You want to set up a VTP password just to be on the safe side.
So I'm going to set my VTP password to the same on all of these devices.
All right, so set a domain name.
Come on, set a password.
Come on, there we go.
All right, so make sure the password is the same on all the devices.
So step one, make sure you've got a domain name.
Make sure you've got a password at a minimum.
And then all your devices now, if you configure your VLAN, if you configure your VLAN,
and then all your devices now, if you configure your VLAN information on one switch, it'll be propagated to all the other switches as well.
Now, I'm going to go to my diagram here first to say another way you can protect yourself is make sure that all these ports here are what?
All these ports are what?
What's the magic word?
It's a six letter word.
What type of ports do we want those to be?
Yes.
Why?
Why does this protect us?
Why does this protect VTP?
Because if somebody connects a rogue switch to us on any of those ports, a trunk will not be formed.
VTP only works on trunks.
No trunk, no VTP.
Therefore, if those are access ports, that's what you do.
So what you do is these ports are trunk ports on this device.
45, 46, 47, 48.
So ports one through 44.
Whether I'm using them or not, the recommended security best practice is switch port, mode, access for all of them.
Whether you're using them or not.
So right now in our environment on ASW1, the best thing to do is interface range gigabit Ethernet 1.0.1 through 44.
Switch port, mode, access, all of them that are not trunks.
So essentially your switch.
If the port needs to be a trunk, you configure it as a trunk.
If it's not going to be a trunk, type this command in whether you're using it or not.
Whether it's enabled or not, doesn't matter.
Type this command in.
That'll protect you from any rogue VTP problems.
All right.
Now, when you're using VTP, we have a couple of different modes here.
Before we even talk about the modes, let me group them together.
These two work together.
This works by itself.
Now, originally there was only these three options.
Off never existed.
It never did.
And then eventually off was created.
So here's the deal.
If you don't want to use VTP today, you just shut it off.
VTP mode off.
Shut off VTP.
What that means is that on that device, you will have to configure your VLANs manual.
That's it.
So if you have 100 switches and you shut off VTP, then you got to configure your switches manually with your VLANs.
Or use scripts or use a configuration tool that can push the configs to the device.
That's fine.
But if you don't need VTP, off is the best way to go.
But before V off existed, we had to use transparent mode to essentially shut it off.
Well, let's talk about server and client first of all.
So what do we mean by server and client?
We mean your switch is using a mode called server mode or client mode.
A lot of people get confused with that and they're thinking like, oh, you may have to set up a server.
No, no, no, that's not what we're talking about.
So if right now we go to DSW1 as an example and we just scroll up, you'll see the operating mode right now is server mode.
So operating mode, server mode.
What in the world does that mean?
Let's take a peek at that.
So server mode, let's type an S there or put an S for server mode.
Send and receive VTP messages, configure VLANs and synchronize database.
So configure VLANs.
So let's configure VLAN 10.
Let's configure VLAN 20 on this device in server mode.
I can then send a VTP message out indicating that VLAN 10 and VLAN 20 have been added to my database.
If you're in server mode, let's make this one server mode as well, you can receive VTP messages and then synchronize your database.
So now I have VLAN 10 and I have VLAN 20.
Through VTP.
All right, let's look at client mode.
So this one's client, let's say.
Look at client mode.
It says you cannot configure VLANs, cannot.
Oops, wrong button.
There we go.
VTP mode.
Client.
VLAN 66.
Can't do it.
Cannot do it.
Whoo, slid.
Special effects.
So if you cannot do it in client mode, it means you can only learn from other devices.
So who can you learn from?
You can learn from servers and you can learn from other clients.
Hang on to that for just a moment.
But learning from other servers, pretty straightforward, right?
Server mode.
Sends VTP messages.
You receive VTP messages and you synchronize your database.
You have 10 and 20.
So you cannot configure them manually yourself here and teach others, but you can learn.
Now, notice how I said that we can also send messages and we can learn from clients.
So clients can teach other clients.
So let me show you that here.
In that particular case, what are we dealing with?
We're dealing with, let's say this is a client.
Well, once I learn this, I can send a VTP messages about what I know.
So I may not be able to configure on this device, but once I know something, I can then send it down my trunk links.
So that way there, you can learn about it as well.
Now you might be saying, well, Raymond, this is kind of silly because you would have learned it this way anyways.
I know, but you've got to think like six dimensionally here, right?
You got to go back to a time that is prehistoric.
When layer two was everywhere, folks.
And when you look at it this way, these might be configured as my servers and everyone else is my clients.
So that way there, these are the only two devices we can configure VLANs on.
And then once we configure them, it gets sent out and then a client learns and then a client can tell the next client downstream.
So it makes perfect sense when you look at it from this perspective.
But when you look at it from our modern day networking perspective, where this is our layer three boundary right here, layer two, layer three boundary.
And then when you go down from there, we've got what?
We've got our access layer switches, layer two environment.
When you've got the redundancy between all the different switches, learning from another client typically doesn't actually happen all that often.
But server and client goes together.
Keep that in mind.
Transparent is essentially shutting off VTP.
Not 100% shutting it off.
That's what off is.
But before off existed, all we had was transparent for shutting it off.
So that's what we did.
We didn't want to use VTP.
You set it to transparent mode.
Transparent mode says we can configure VLANs locally.
So I can configure all the VLANs I want manually on all my switches.
So I can configure VLANs here, I can configure VLANs here, here, here.
But we are not going to tell the other switches about that.
So if I'm in transparent mode and I configure VLAN 10, nobody's going to know that except for me, ASW1.
If I configure VLAN 20 here and we're in transparent mode, I only know that.
So transparent mode is about you manually configuring all of your VLANs on all of your different switches.
And therefore, if you do receive a VTP message because you were in an environment, let's say you had, for example, server here, server here, transparent mode here.
If you received a VTP message for some reason, then you would ignore it, but you would still forward it on.
You would still forward it on.
This allowed you to have switches in your environment that maybe weren't server or client mode, but still allowed that server to be between them or switch to be between them.
But that becomes a challenge because if I had a server mode, transparent mode, and I have client mode, well, then if I have VLAN 10 here and I tell you about it, you ignore it, but you tell the client about it.
Now the client knows about VLAN 10.
And now if VLAN 10 traffic had to go this way, would it ever make it?
No, because the transparent switch doesn't know about it.
That's why you typically don't mix these two together, because I'd still have to go to this transparent mode switch and manually configure VLAN 10.
So you could do it if you wanted to, but it's just more work for yourself.
You might as well have server, client, client instead in that scenario.
But if you had a need for that or a reason to do that, you could.
That's why they allowed you to do that with transparent mode.
It allowed you not to be part of the VTP sharing, but still forward that information, or not learn from the VTP sharing, but still forward that information.
So the idea here is for you to recognize that on an exam, server mode, client mode, how do they behave?
You can configure on a server, but not a client.
But a server will teach a client.
A server will teach a server.
A client can teach a client everything it knows.
Transparent mode will ignore all those messages that come in, and will not teach anything or anyone about anything.
But if there's a transparent switch between a server switch and a server, or a client and a client, or a server and a client, the transparent switch will forward it.
But if it's an off switch, then an off switch will not forward anything.
So if this was off, and it received a message, it's sorry.
It is dropped.
Nothing's going to be sent to anybody else when it's all said and done.
So these are your different modes.
So if we go out to our live environment, if I type in VTP mode transparent, do show VLAN brief, you'll see that in this particular case, I have the original VLANs.
So if I type in VLAN, let's type in VLAN 55, 56, 57, 58, exit out, show VLAN brief, you'll see that this device has the VLANs now that we just created, 56, 57, 58.
But if we go over to somebody like DSW1 right now, look at our VLAN database, you'll see that they're not in there.
Same thing, ASW1, ASW2, they're not there.
Because this is a transparent mode switch.
I don't care.
I don't care about sharing my stuff with you.
Go to DSW1 right now.
Let's type in VLAN 777.
Exit out of there.
You'll see that ASW2 is going to learn about that.
So we learn about it.
777, there it is.
But if you go to somebody like DSW2, you'll see DSW2 didn't learn about it.
Why?
Transparent mode.
So you're not going to learn at all with transparent mode.
So one of the safest ways to make sure that your VLAN database never gets corrupted is to use transparent mode, or use off.
And then just manually configure your VLANs.
Now there's a lot of organizations out there that will do server mode and client mode temporarily,
where they do server client mode temporarily to share all the VLAN information they need to share with all the switches,
and then they'll revert all their devices back to transparent mode at that point in time after that, or off.
And so many different ways you can play around with this, it's up to you.
But be mindful of how these operate for the certification exam.
When it comes to sharing information, the decision as to whether you share it or not is based on something known as the configuration revision number.
So if we type in, or sorry, not share it, learn it, and synchronize yourself.
If we type in do show VTP status as an example,
we'll see here that right now I have a configuration revision number of one on DSW1.
And what does this configuration revision number do?
It keeps track of all the VLAN changes.
So for example, if we now type in something like VLAN 789, exit out of there,
you're going to see the configuration revision number goes up by what?
It's going to go up by one.
So now you can see there's a configuration revision number of two.
So type in VLAN 999, exit out of there.
You'll see now it's a configuration revision number of three.
Even going to like VLAN VTP or VLAN 999 as an example and typing, changing the name.
Name, la la la la, good enough, okay.
Exit out of there, that should change our configuration revision number as well.
And you'll see now we're a configuration revision number of four.
So what happens here is that when I send my VTP message out on the network
because I'm in server mode right now,
the configuration revision number that goes with this message is four.
The existing VLAN is 13.
And there's this message digest we have down here.
So I'm sending you the VLAN information I have,
but there's this message digest that is used to verify our authentication,
our synchronization, all of that stuff.
So remember, we've got a VTP password set up in this case.
So I have an Encore domain name.
I've got a VTP password of Cisco.
We've got a configuration revision number of four.
And what we do is we take all that information and all of our VLAN
and we can go ahead and we can build or create this MD5 digest.
So this is how we now synchronize and verify everything.
So right now, for example, like somebody like ASW2
has a configuration revision number of, let's say, two.
So because it has a configuration revision number that is lower than DSW1,
it now knows, hey, I've got to synchronize with that.
So the higher the configuration revision number,
the more trustworthy you are,
meaning that you are the information.
This is who we should be synchronizing with.
So ASW1 gets this information.
ASW2 gets this information.
It's like, oh my gosh, my configuration revision number is lower than yours.
I have to synchronize with you.
That is what determines synchronization.
And now based on things like, are we in the same domain?
Do we have the same password?
Can I generate the exact same message digest as you using that information
and the VLANs and the configuration revision number?
If so, then I'm going to go ahead and synchronize with you.
If not, then I'm not going to synchronize with you.
So because all of that is true in this particular case,
when we look at somebody like ASW2,
you'll see that we've successfully synchronized.
I've got a configuration revision number of four.
So does DSW1.
Number of VLANs, 13.
Same as DSW1.
Look at the message digest.
It's the same.
You see how it's the same?
Same.
So let's now add another VLAN.
VLAN 945.
Exit out of there.
Come back.
So we'll go to VTP status again.
You're going to see now, this has changed.
This has changed.
So if we go back to ASW2, this is what was there before on ASW2.
Now look at all this.
It's changed.
So when this message comes out from DSW1,
ASW2 is going to have to take its domain name,
its current configuration revision number is four,
but it sees that there's a five on DSW1,
so it's going to use five in this particular case.
And the number of VLANs we have,
build its own message digest from that.
And in the end, if it gets the same value,
it synchronizes.
If not, then it's not going to synchronize.
And in this case, you'll see that it got this value,
which is obviously different than that one before.
And is it the same, though, as DSW1?
Yes, it is.
So I successfully synchronized with you.
So all of that comes into the synchronization process.
And so this happens with servers and clients.
It doesn't happen with transparent.
So if we go over to somebody like DSW2 right now
who's in transparent mode,
and we type in show VTP status,
all of that stuff that happened doesn't matter here.
So every time DSW2 got the VTP messages,
it totally ignored them.
Look at the configuration revision number.
It's zero. It doesn't even care.
It doesn't even care.
So a lot of people ask me,
well, though, Raymond,
is the configuration number going to change
if we create VLANs? Nope.
Oops, wrong button again.
Nope, still zero.
Always zero. Always zero.
Always zero.
Now, notice the messages I just did change
because it still keeps track of that.
And then the next question is, okay,
so when you're in transparent mode,
does the domain name matter?
Do you even need one? Absolutely.
If you're in transparent mode, if you're null,
although you won't join a domain
if you are in transparent mode and null,
if your device ever accidentally gets changed back
to server or client mode,
accidentally or on purpose,
then the first VTP message it receives,
and it will get one pretty fast,
it'll join that domain.
It could just destroy everything on you.
So, yes, a domain name should always be configured.
And then what about version?
So version one is causing a lot of problems for us,
especially if we're in server or client mode
because version one was designed way back in the day
when we were dealing with just ISLs
before 802.1Q was created,
supported only normal range VLANs,
VLANs one through 1005, as we talked about before.
So, and that is for what?
Server and client mode.
Now, transparent mode, though,
if you go to transparent mode,
you can support all the VLANs, 4096.
So this only applies to server and client mode,
whereas in transparent mode,
you get all 4096 VLANs supported.
This added support for token ring networks,
so really not even valuable today at all.
You could just probably forget about version two.
Version three, though,
with server mode, client mode, off, transparent,
it doesn't matter.
It supports the entire range of VLANs.
And version three also supports enhanced authentication.
It supports private VLAN information,
supports the propagation
of multiple Spanish protocol information.
And on top of that,
it supports the concept of a primary,
primary server and secondary servers.
What does that mean?
It means you're going to promote one of your switches
to be the primary server.
So let's make this one the primary server.
What does that mean?
It means no matter what happens now in this environment,
your switches will not listen to anybody
but the primary server.
That's right.
So even if some rogue switch comes along,
rogue switch comes along,
and manages to form a trunk
and send VLAN information,
you ignore it.
You ignore it.
It doesn't matter.
It doesn't matter because you don't listen to anybody
but the primary server in that particular environment.
So that is a recommendation to use version three today
if you're using VTP.
So that's what I encourage you to do.
You can't even use VTP version three
unless you create a domain name.
So VTP version three, domain name,
is preferred.
And regardless of whether you're using server,
client, off, or transparent,
whatever you choose doesn't matter,
but go with version three.
Highly recommend it.
And our last discussion here is on something called
VTP pruning.
Now VTP pruning only works with server and client mode.
Let me repeat that.
VTP pruning only works with server and client mode.
Let me repeat that.
VTP pruning only works with server and client mode.
It does not work with transparent mode.
Or off.
So what does that mean?
It means that if you want to do VTP pruning
but you're in transparent mode or off,
you can't.
You're going to have to do something else.
Now is there something else you could use?
Absolutely.
Look at what it says here.
VTP pruning says add or remove VLANs
off a trunk dynamically.
Add or remove VLANs off a trunk dynamically.
Wait, wait, wait.
We talked about something like that earlier today,
we talked about that.
We talked about it with our trunk filtering.
That's where we talked about it.
Remember this discussion, folks?
We talked about using filters
to control which VLANs are allowed on a trunk link.
That's what VTP pruning does.
But it does it dynamically for you
instead of you having to do it manually.
But it only works if you're what?
Server or client mode.
Always remember that for the certification exam.
Why do I say that?
I say that because if I gave you this output
and I said, hey, I want you to prune VLANs
off the trunk link.
Let me repeat that.
I want you to prune your VLANs off the trunk link.
Look at the word I used, prune.
Can you actually use it?
The answer is no.
You would have to filter it instead.
Meaning, don't pick a pruning answer.
Pick a filtering answer.
That's the difference.
But if I showed you this output
and I said, hey, I want you to prune VLANs
that you don't need off your trunk link,
then you can use VTP pruning.
This is server mode or client mode.
That is what you need to consider
about that scenario in case it comes up.
Be aware of that.
How does VTP pruning work?
How do you turn it on?
If you saw client mode,
you can't turn it on on a client mode device.
You can only turn it on on a server mode device.
Here's a server mode device.
Here's a server mode.
Let's say this is client and this is client.
I would go to any one of my server mode devices,
just one of them,
and turn on VTP pruning.
When I type in VTP pruning on that device,
this here would change from disabled to enabled.
Then I generate a VTP message
and I send it to everyone in the VTP domain
and I tell them, turn on VTP pruning,
and they will do that.
You do it once on a server.
If this was client mode here
and they were asking you to turn on VTP pruning,
you would have to look to an answer option
that says go to one of the servers
and type in the VTP pruning command.
If it's a server,
then just type in the VTP pruning command.
It would magically happen on all the rest of them.
That's the first thing I want you to remember.
Second thing I want you to remember is,
again, it doesn't work on transparent mode devices.
What does that mean?
It means that this particular switch,
if it was transparent mode,
you wouldn't be able to turn on VTP pruning there.
What would you do?
You would create a manual filter list
like we talked about in our trunking discussion.
That way you know what you need to know.
That is VTP, folks.
Again, probably not a big part of the exam,
but if you get two questions
that either use it as a distractor
or as the real answer,
at least you can deal with it now
and you'll get full points that you need to get.