VLAN Trunking Protocol does one job: it propagates VLAN definitions from one switch to the rest of the switches in a domain, so you do not have to create the same VLAN by hand on twenty boxes. That sounds purely helpful, and in small doses it is. VTP also has a famous failure mode where a single mis-handled switch wipes the VLAN database across an entire network. This post explains how VTP works, the differences between v1, v2, and v3, and why a lot of engineers now deliberately turn it off.
For the cluster overview, see the VLAN and Layer 2 switching pillar.
What VTP is for
Without VTP, every VLAN exists only on the switch where you created it. A 30-switch campus with 40 VLANs means creating 40 VLANs, 30 times. VTP lets you create a VLAN once, on one switch, and have that definition replicate automatically to every other switch in the same VTP domain over trunk links.
It is genuinely useful for keeping VLAN definitions consistent. What it does not do, and what people wrongly expect it to do, is decide which VLANs are allowed on which trunks - that is the trunk allowed-list, a separate thing entirely.
The three VTP modes
A server can edit VLANs and pushes changes to the domain. A client cannot edit VLANs - it only accepts what servers send. A transparent switch is opted out: it keeps its own local VLAN database, ignores VTP advertisements from others, but politely forwards them along so it does not break the chain for downstream switches.
The revision number: the dangerous part
Every VTP server and client tracks a configuration revision number. Every time a server makes a VLAN change, it increments its revision number and advertises the new database. Switches receiving an advertisement compare revision numbers: if the incoming revision is higher than what they currently have, they overwrite their entire VLAN database with the incoming one.
Read that again, because it is the whole problem. The decision is purely "is this number bigger?" It does not matter whether the advertising switch is your core or a switch a contractor pulled off a shelf. A higher revision number wins.
The classic disaster: a switch is removed from the network, used in a lab where lots of VLAN changes pump its revision number sky-high, then plugged back into production - still in server or client mode, still in the same VTP domain. Its revision number is now higher than the production core's. Every switch in the domain accepts its database. If that lab switch's database had three VLANs, the production network now has three VLANs. Hundreds of access ports go dark because their VLANs no longer exist.
How to avoid the disaster
Any switch entering or re-entering a VTP domain must have its revision number reset to 0 first. Two reliable ways to force a reset:
- Change the switch to VTP transparent mode and back - transparent mode resets the revision to 0.
- Change the VTP domain name to something else and back - a domain change also resets the revision.
This is mandatory hygiene. Never plug a switch with unknown VTP history into a production domain without first zeroing its revision.
VTP versions: v1, v2, v3
VTP v3 is the version that addresses the revision-number disaster head-on. In v3 there is exactly one primary server for the domain - and only the primary can make changes that propagate. A switch is not primary just because it is in server mode; it has to be explicitly promoted with a command, and that promotion is what gives it write authority. A rogue switch with a high revision number cannot overwrite anything in v3 unless it has been deliberately made primary. If you must run VTP, run v3.
Configuration on Cisco IOS XE
! Set the domain, version, mode, and a password
vtp domain PINGLABZ
vtp version 3
vtp mode server
vtp password STRONG_SECRETIn v3, after setting the switch to server mode you still must explicitly make it the primary before it can push changes:
SW1# vtp primary vlan
This system is becoming primary server for feature vlan
...
Do you want to continue? [confirm]Verifying
SW1# show vtp status
VTP Version capable : 1 to 3
VTP version running : 3
VTP Domain Name : PINGLABZ
VTP Pruning Mode : Disabled
VTP Traps Generation : Disabled
Device ID : 0050.7989.aaaa
Feature VLAN:
--------------
VTP Operating Mode : Primary Server
Number of existing VLANs : 12
Configuration Revision : 7
Primary ID : 0050.7989.aaaa
Primary Description : SW1The two lines to read: Configuration Revision (the number that drives overwrites - know it before adding any switch) and VTP Operating Mode (Primary Server, Server, Client, or Transparent).
Why many engineers just turn VTP off
A large number of modern networks run every switch in VTP transparent mode, or VTP off entirely, and create VLANs manually (or via automation - Ansible, scripts, controller-based provisioning).
The reasoning: the downside of VTP (one bad switch erasing the VLAN database network-wide) is catastrophic, while the upside (not typing VLAN definitions a few extra times) is modest and is better solved by configuration automation anyway. Automation gives you the same consistency with version control, change review, and no revision-number landmine. If you do run VTP, v3 with its primary-server model is the only version that should be on the table.
Common gotchas
Key takeaways
VTP propagates VLAN definitions across a domain so you create each VLAN once. It has three modes - server, client, transparent - and a revision number that decides whose database wins: higher revision overwrites everyone. That mechanism is the source of VTP's signature disaster, where a stale switch with an inflated revision number wipes the VLAN database network-wide. Always reset a switch's revision to 0 before connecting it. Run v3 if you run VTP at all - its primary-server model removes the rogue-overwrite risk. Many modern networks skip VTP entirely and provision VLANs through automation, which is a defensible and increasingly common choice.
For the L2 cluster, see the VLAN pillar.
