Introduction to VTP (VLAN Trunking Protocol)

Hello Chris

Initially, a switch will have the following default parameters for VTP:

  • VTP operating mode: Server
  • VTP Domain Name: Null

In such a case, VTP is active, but switches will not actively create any VTP associations with any other switches simply because the domain has not been configured. When all switches have a domain of NULL, it is as if VTP is not functioning.

However, this can still be a dangerous situation, because if a rogue switch is added which has a VTP domain configured, it will start to send VTP messages, and any switch on the network that still has a NULL domain, will automatically adopt that domain as well.

You can’t disable VTP as a feature, but you can ensure that a switch never participates in any VTP domain that may appear on the network by simply changing the VTP mode to transparent like so:

Switch(config)#vtp mode transparent

This ensures that any VTP messages received will be ignored.

I hope this has been helpful!

Laz

Yes it was very helpful, thank you!

1 Like

Hi Rene,
I’m configuring VTP pruning, as this topology
prun
R5 and R6 connect to access port of vlan 100 on sw2 and sw4. I enable vtp pruning on sw1.
When I ping from R5 to an IP address, ex 10.1.2.100 to generate ARP packets, sw1 still forwards ARP traffic to sw3 , although sw3 does not have any accessport in vlan 100.
Pls help to explain. Tks you.

Hello Hai

Indeed, based on your explanation, ARP packets sent by R5 should not reach SW3 due to VTP pruning. However, from the image you have shared, it looks like you’re using GNS3. Others have found similar incorrect behavior when using GNS3, and this may be a similar result. Take a look at this Cisco learning network post:
https://learningnetwork.cisco.com/s/question/0D53i00000Kt1H6CAJ/vtp-pruning-not-working-as-i-expected

I hope this has been helpful!

Laz

1 Like

Hi, Rene.

  1. Would this (reset the revision number) be the recommended way to avoid the problem you mention early in the letter (experiment on a switch in the lab, delete your experiments, reattach switch to network)? Or is there another/better way to avoid that?

Hello David

Resetting the revision number is probably the best way to ensure that adding a switch to your topology will not change the VTP configuration of all the switches.

There are a couple of ways to reset the revision number in VTP:

  • change the VTP mode to transparent, and then back to server or client mode
  • change the domain name and then change it back

In any case, it’s always best practice to make a switch VTP transparent before connecting it to the network. Once connected, you can then change it back to whatever you need, ensuring that the revision number is indeed smaller than the rest of the switches.

I hope this has been helpful!

Laz

1 Like

Hi,

Great lessons. And I have little suggstion to it. I tried to configure VTP manually, but it didn’t work, untill I found on VTP Cisco page, that VTP requires trunk between switches. I think it’s little confusing to learn VTP before Trunk. since VTP doesn’t work without trunk. So suggestions is to put Trunk Lesson before VTP and mention that VTP requires active trunk, so that students can practise VTP without jumpnig between lessons or trying to understand why VTP doesn’t work. I don’t know, if someone had this problems also, but for me it wasn’t clear. (Yeah VTP stays for VLAN “TRUNKING” Protocol, but again as a newbie I didn’t get it)

Thanks

Hello Shahlar

Thanks so much for this feedback. The VTP lesson is part of various courses and may appear elsewhere in the order of lessons as they appear for each course. In the Switching course, VTP appears after trunking:


In other courses, it may indeed appear before trunking. In all cases, however, it is indeed helpful to indicate in the lesson itself that a trunk link is necessary between switches in order for VTP to operate.

I will let Rene know to take a look and make any necessary modifications to the lesson.

Thanks again!

Laz

1 Like

Hi Laz

Okay, got it. Thank you for your answer. Glad to be helpful!

1 Like

VTP advertisements are not mentioned

VLANs creates different broadcast domains, how broadcast traffic will impact another link having different VLAN?

Hello jijith

If you want to find out more about VTP advertisements, take a look at this NetworkLessons Note on the subject. Rene does mention advertisements in the lesson, but not to any extent. Hopefully, this will cover what you need.

I hope this has been helpful!

Laz

Hello Amit

When a broadcast is sent on a particular VLAN, let’s say VLAN 10, that broadcast will be sent out of all access ports that are on VLAN 10, and out of all trunk ports that include VLAN 10. If we were to draw a line around that broadcast domain on the diagram within the lesson, we would get something like this:

image

As you can see, we would have broadcasts on VLAN 10, sent out of the main switch to the middle switch (highlighted in yellow). This traffic is useless since no hosts exist on VLAN 10 on the middle switch.

Now how would this impact another link having a different VLAN? If there was another access or trunk link that doesn’t include VLAN 10, then it would be unaffected, since broadcasts would not exist on any other VLAN except 10.

I hope this has been helpful!

Laz

Hello, my question is about revision numbers on VTP Transparents. If the VTP Transparent receives an update, but does not synchronize and only forwards the information, does the VTP Transparent’s revision number change or stay the same?

Hello Mario

That’s a good question. I went into the lab and checked this out. I have found that on transparent switches, the revision number always remains zero. Even though I added several VLANs to this switch, you can see that this is so:

SW1#show vtp statu
*Nov  9 06:38:55.759: %SYS-5-CONFIG_I: Configured from console by consoles
VTP Version capable             : 1 to 3
VTP version running             : 2
VTP Domain Name                 : 
VTP Pruning Mode                : Disabled
VTP Traps Generation            : Disabled
Device ID                       : 5254.0006.8000
Configuration last modified by 0.0.0.0 at 11-9-22 06:37:31

Feature VLAN:
--------------
VTP Operating Mode                : Transparent
Maximum VLANs supported locally   : 1005
Number of existing VLANs          : 14
Configuration Revision            : 0
MD5 digest                        : 0xD8 0x87 0x4A 0xF5 0x0D 0x70 0x90 0x91 
                                    0x65 0x54 0x4B 0x9F 0x2A 0xC2 0x95 0xCC 
SW1#

This means that even local changes made do not change the revision number of the transparent switch, nor do any VTP messages that a transparent switch may receive and relay to other switches. This makes sense, because a revision number has no meaning for a transparent switch from the moment that its VLAN configuration remains completely independent of any other switch on the network.

I hope this has been helpful!

Laz

Hi there,

At the begining of this topic you need to write that first of all moves ports to trunk mode. VTP couldn’t work without it.

Hello Yatsenko

When a switch has VTP enabled, and it has no domain configured, then the very first VTP message it receives will cause it to assign the domain name in that message to itself. Once this is done, the VTP domain can only be changed manually. This is simply how VTP operates.

If subsequent VTP messages have a different VTP domain, they will be ignored, because they belong to a different domain.

As soon as a switch joins a VTP domain, it will automatically adopt the most recent VLAN configuration sent out by the VTP server. That’s why SW2 and SW3, as soon as they were configured with the VTP domain, adopted all of the changes to the VLANs that had been done to SW1.

I hope this has been helpful!

Laz

Thanks for your time, but I meant other stuff.

When I read this article I tried to make a network scheme on cisco packet tracer and all my connecting between switches was like switchport mode access. I have run debub sw-vlan vtp events command on all switches and change vtp domain on one switch. And nothing to do, but when I have changed one connection link to switchport mode trunk i got debug messages that my vtp domain on the second switch was changed.

In my previous messages I meant that if your connection link belongs to access mode, vtp domain messages didn’t spread.

Hello Yatsenko

Thanks for the clarification. Indeed, VTP sends VTP messages only over trunk links. Access ports do not send any VTP advertisements or messages. This is simply the way the protocol has been designed. Take a look at this NetworkLessons not on VTP operation over tunks for more information and links.

I hope this has been helpful!

Laz

Hello,

So if VTP will only work if the switches are in the same domain, wouldn’t you say it’s a security best practice to set a random VTP domain name on all of your old switches, the ones that had a VTP configuration in the past? With your new switches out of the box, the domain is NULL anyway, so (please correct me if I’m wrong) they won’t synchronize with each other, even if some are Servers and others are Clients.

The issue I’d have with just setting them in the Transparent mode is if you accidentally leave a switch as Server and another as Client, and all of your switches are in the same VTP domain, then the Transparent switches will relay the VLAN information. But if they all had gibberish VTP domain names, then their states wouldn’t matter. So at least you’d have 2 fallback options: if you accidentally forget one (changing the VTP mode or the VTP domain), you’re still good if you haven’t forgotten the other. So if your design is to set all switches to Transparent and set a gibberish domain name, and you forget to do one but not the other, this VTP issue can’t happen.

That’s because
(A) any switch is likely to either have the same domain as (maybe some of) the other switches but be Transparent;
(B) or be Client or Server but have some gibberish domain;
(C) or be Transparent and have a gibberish domain. In either case, VTP can’t cause any issues.

It might be a good idea to set the VTP domain to some gibberish with your new switches as well, even though they are all in the NULL domain out of the box, because if you don’t do things consistently, then there’s bound to be a case where you mix up the rule with the exception, and make a mistake. In this case, if you get in the habit of not changing the domain for factory new switches, and you get to work on an old switch, then (due to fatigue or a brief lapse of attention, all of which are normal) you may forget to change the old switch’s VTP domain as well. (Of course, this can happen in general even without having to keep track of exceptions, but with more exceptions, the chances are greater.) Do that to a second switch, and you’ve got yourself a bad day (assuming both switches were put in the same domain some time ago, which obviously can happen based on this article).

Wouldn’t this design choice result in a network that’s less prone to issues in case of human error?

Thanks.
Attila