Introduction to VTP (VLAN Trunking Protocol)

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!



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?


Hello Attila

Actually, with a switch right out of the box, the domain name is indeed NULL. However, if you don’t change anything on the switch, it will adopt the domain name of the first VTP message it receives. So right out of the box, VTP is not in a very secure state.

Yes this is indeed true, and by setting up a random VTP domain with a password on each switch, you can ensure that VTP messages will not be relayed. In my opinion, this solution is a little bit over the top. What I mean is, the administrative overhead needed for the solution is a bigger problem than the issue it resolves. Simply setting all switches to transparent as a best practice should be more than enough to ensure that you’re “safe” from the possible problems introduced. For me, I’d be more prone to make a mistake trying to ensure each switch has a different VTP domain rather than simply setting everything up as transparent.

Your approach is not incorrect, and if it works for you, go for it. The other option that I’d like to point out is that VTP version 3 has the ability to disable VTP completely using the vtp mode off command. This command essentially is the same as the transparent mode, but the switch doesn’t forward VTP messages. For me, if VTP version 3 is available, this is the best option.

I hope this has been helpful!


1 Like


I’ve got a couple of questions, can someone help me out please?

  1. Even if using VTP doesn’t lead to any issues, is there a point to using it? All it does is save some effort by creating the VLANs, but that doesn’t sound like such a win if we consider that you have to log in to each switch anyway to add the switchports to their needed VLANs. So not a lot of manual labor (therefore, manual errors) is saved by VTP, and in exchange, it can easily bring the network down. Doesn’t sound like a good tradeoff to me, but I might be missing something.

  2. I’ve read an interesting article that discusses some VTP best practices:

The article promises that VTP won’t causes any issues if you configure the following on the intended VTP Server:

CoreSwitch(config)# vtp domain
CoreSwitch(config)# vtp password fedmag secret
CoreSwitch(config)# vtp mode server
CoreSwitch(config)# vtp version 2
CoreSwitch(config)# vtp pruning

However, I don’t understand why any of these would avoid the issue caused by introducing a new switch with a higher revision number into the network.

The only solution I could think of was to add and remove the same VLAN a couple thousand(!) times on the intended VTP Server. Since it’s pretty unlikely that anyone would accidentally modify the VLANs thousands of times, it’s a safe (but not certain) bet that the intended Server would have the highest revision number.

All I’d do is copypaste around 3000 lines of the following commands into the Server:

CoreSwitch(config)# vlan 111
CoreSwitch(config-vlan)# exit
CoreSwitch(config)# no vlan 111

A couple of things to note:

  • I’d do this to a switch while it’s not connected to the network and I’m connected to it via a console cable.
  • There’s no need for this with VTP 3 if you set up a primary server.
  • I’ve chosen that VLAN number randomly. The important thing would be to make sure that it’s a VLAN that doesn’t actually exist.
  • Creating thousands of copies of these three commands in Notepad++ took me around 5 seconds. (Notepad++ is good because it shows the number of lines.) All I did was copypaste them into a new tab a couple of times, then select them all with Ctrl+A, then I pressed Ctrl+C, then Ctrl+V, and I’ve repeated these three commands in this order a couple of times to get around 3000 lines.
  • All I’d do then is select all 3000 and paste them into the Server.
  • I’d rather not use VTP at all, but with versions 1 and 2, I couldn’t think of a better way to decrease the likelihood of an issue. Even so, I’m not a huge fan of this solution, but is there a better way to decrease the chance of someone wiping out all VLANs by accident, if using VTP version 1 or 2 is mandatory?

Wouldn’t that ensure a high enough revision number?

  1. What happens when the highest revision number is reached?

I found only one post about this question here:

I’d be very happy to read a response.
Thank you for reading my long comment.

Hello Attila

I am the administrator of a municipal network of over 2500 end devices and over 70 switches in 14 buildings throughout the city in which I live. We have close to 400 VLANs, and VTP has saved me a lot of time. This is true because the network is changing all the time. I have to add and remove VLANs relatively frequently, and VTP ensures that all 70 switches are synchronized, and pruning takes place automatically. Yes, you have to configure each individual access port separately, but every time you add or remove a VLAN you don’t have to add or remove it from each and every switch. Eventually, I would lose track of which switch should have which VLAN configured.

The key here is the password and the domain. If all of your switches in your existing network are configured with this password and this domain, then even if you introduce a new switch with a higher revision number, it will not affect any of the existing switches. The existing switches will only be affected if the password and domain are the same. Otherwise, they will ignore any VTP messages. For this reason, it is of utmost importance to modify the password and domain from the default and to keep those credentials safe and private. Although your solution of increasing the revision number is inventive and would work, it is unnecessary.

The Cisco Community link you shared is incorrect in that VTPv1 and VTPv2 use a 12-bit value for the revision number, giving a maximum of 4096. For all VTP versions, the version number is 32 bits giving up to 4.2 billion values. This is detailed here:

Practically speaking, you would never NEVER reach this number. If you make a change to your VLANs every second, resulting in the revision number being incremented every second, it would take over 1300 years to reach the maximum value of the revision number. So this is a practical impossibility unless there is some corruption in your VTP messages.

I hope this has been helpful!


1 Like

Hi, Rene,
You write in really good explaination!
But I got a question: you said a vtp server is also a vtp client, if I make a change on the vtp client, the lastest information will be sent to all other switches, right? I wanna ask you if this vtp client has already became a vtp server at the moment? I just have a bit of confused of the transform between vtp client and vtp server.
Thanks you for answering my question!
Based on my understanding, if I make a change on the vtp client (vtp server: adds/deletes/modifies information), this vtp client will become a vtp sever.

Hello, everyone.

A quick question. Why does DTP refuse to negotiate a trunk between two switches if they are in different VTP domains? Why did they design it like this?

That’s all, thanks!

Hello Heping

If you try to make a change to a VTP client, such as adding a VLAN, it won’t let you make the change. You’ll get an error message like this:

%VTP VLAN configuration not allowed when device is in CLIENT mode.

In order to be allowed to make changes to VLANs from a switch, that switch must be manually configured as a VTP server. For VTPv3, it’s not enough to simply be a VTP server. Only the primary VTP server can make changes to VLANs.

I hope this has been helpful!


Hello David

DTP refuses to negotiate a trunk between two switches in different VTP domains as a safety measure to prevent any unwanted updates or changes to the VLAN database.

Remember, VTP messages are sent over trunks. By preventing the automatic negotiation of a trunk between two such switches, it provides one more layer of protection against the accidental propagation of VLAN information via VTP. If two switches in different VTP domains were allowed to form a trunk, then changes in one VTP domain could potentially propagate across the trunk and affect the VLAN configuration in the other VTP domain. This could lead to network inconsistencies and disruptions.

So, to prevent this, DTP does not allow trunk negotiation between switches in different VTP domains. This design ensures the integrity and stability of VLAN configurations within their respective VTP domains.

I hope this has been helpful!


Hi Rene, How to disable the VTP completely in the switch.

Hello Shakti

Take a look at this NetworkLessons note on how to disable VTP on a switch.

I hope this has been helpful!