Cisco VTP Explained: Server, Client and Transparent Modes

VLAN Trunk Protocol (VTP) is Cisco's mechanism for distributing VLAN information across a switched network: create the VLAN once on a VTP server and every switch in the same VTP domain learns it automatically over trunk links. That convenience comes with a dangerous side effect — a switch with a higher configuration revision can wipe or rewrite VLAN databases network-wide. This guide explains VTP modes, message types, the revision number and the operational rules that keep VTP from hurting you.

VTP Modes

• Server — can create, modify and delete VLANs; advertises its VLAN database to the domain and synchronizes from other servers. Default mode.
• Client — behaves like a server but cannot create, change or delete VLANs locally.
• Transparent — does not join VTP: keeps its own VLAN database, ignores synchronization, and in VTP version 2 forwards advertisements out its trunk ports.
• Off — same as transparent except advertisements are not forwarded.

The mode is a per-switch setting, not a per-port one, and it is stored in the VLAN database along with the domain name and revision. Changing a switch from server to client does not delete its VLANs; changing it to transparent freezes whatever VLANs it currently has and stops listening for updates. The mode that surprises people most is client: a client cannot create a VLAN locally even in an emergency, so keep at least one server reachable if your change process depends on ad-hoc VLAN creation.

VTP Versions 1, 2 and 3

VTPv3 is the only version that can carry extended VLANs (1006-4094) and the only one that should be considered for a modern campus, because it adds a primary server role that stops any server from overwriting the database. In v3 only the primary server can make changes that are advertised; a secondary server accepts the database and does not originate updates. That single rule removes the classic "a re-used switch nuked my VLANs" scenario.

How VTP Advertisements Work

VTP packets travel in ISL or 802.1Q frames to the multicast MAC 01-00-0C-CC-CC-CC. Three message types matter in daily operation:

• Summary advertisements — sent every five minutes by default, carrying the domain name and configuration revision.
• Subset advertisements — follow a summary when VLANs change; they carry the actual VLAN list.
• Advertisement requests — sent when a switch resets or its domain name changes, asking neighbors for the current database.

A receiving switch ignores a summary if the domain name differs or its own revision is equal or higher; otherwise it requests the newer database.

Two more details matter when you are reading packet captures. The first is that summary advertisements are also sent immediately after a change, not only on the five-minute timer, which is why a VLAN appears to propagate "instantly" even though the periodic timer is 300 seconds. The second is that a switch only accepts an update if the domain name matches, the revision is higher, and - if a password is configured - the MD5 digest validates. A domain mismatch is silent: the switch simply considers the two networks unrelated and keeps its own database.

The Configuration Revision Number

Every VLAN change increments the 32-bit configuration revision on the device where it was made. Revision is the poison that makes VTP dangerous: install a repurposed switch with revision 10 into a domain at revision 5 and the newcomer pushes its (possibly empty) VLAN database onto every switch. Always reset the revision before adding a switch — the standard trick is to change the VTP domain name and change it back:

Switch(config)# vtp domain TEMP
Switch(config)# vtp domain PROD

In VTPv3 the equivalent and safer step is to leave the switch in transparent or off mode until it is racked and configured, then convert it. A switch in off mode holds its revision at zero and never advertises, so it cannot influence the domain at all.

VTP Configuration Commands

Switch(config)# vtp mode server
Switch(config)# vtp domain PROD
Switch(config)# vtp version 2
Switch(config)# vtp password MySecret
Switch# show vtp status
Switch# show vtp password

show vtp status reveals the mode, domain, revision and the number of VLANs the switch believes exist — the first command to run when a VLAN database looks wrong.

Reading show vtp status Field by Field

Switch# show vtp status
VTP Version capable             : 1 to 3
VTP version running             : 2
VTP Domain Name                 : PROD
VTP Pruning Mode                : Disabled
VTP Traps Generation            : Disabled
Device ID                       : 0c11.2233.4455
Configuration last modified by  : 10.10.10.1 at 3-1-24 09:14:22
Local updater ID is 10.10.10.1

Feature VLAN:
--------------
VTP Operating Mode              : Server
Maximum VLANs supported locally : 1005
Number of existing VLANs        : 42
Configuration Revision          : 57
MD5 digest                      : 0x3C 0x11 ...

Three numbers carry the operational meaning. Configuration Revision tells you how "new" this switch believes its database is - a switch with a high revision joining a low-revision domain is the dangerous one. Number of existing VLANs tells you whether the database is complete or has been overwritten with something smaller. And Configuration last modified by tells you which device last made a change, which is the fastest way to identify the switch that caused an unexpected update.

VTP Pruning

Without pruning, a VLAN's broadcast traffic is flooded across every trunk in the domain even if only two switches have ports in that VLAN. Pruning suppresses advertisements and flooded traffic on trunks where no port belongs to the VLAN:

Switch(config)# vtp pruning
Switch(config-if)# switchport trunk pruning vlan 10,20,30
Switch(config-if)# switchport trunk pruning vlan remove 100-200
Switch# show vtp counters

Pruning must be enabled domain-wide to be effective; a switch that has it disabled continues to receive pruned VLAN traffic. Cisco recommends VTP pruning on large Layer 2 domains, and it is safe to enable incrementally because the VLAN 1 traffic is never pruned.

Step-by-Step: Building a VTP Domain Without Breaking It

1. Decide the domain name, version and password before touching any switch, and write them in the build document. A typo in the domain name silently splits the network into two independent VTP islands.
2. Configure all switches in transparent mode first. VLANs created in transparent mode survive a later conversion to server or client.
3. Choose one switch as the server (or, in v3, the primary server) and create the VLAN list there.
4. Convert the remaining switches to client mode. Watch show vtp status on each and confirm the revision rises to match the server and the VLAN count matches.
5. Confirm every trunk is actually carrying VTP frames with show vtp counters and show interfaces trunk. A trunk in the wrong native VLAN will not pass VTP.
6. Enable pruning and traps, then record the final revision in the change ticket.

Recovering from a VTP-Induced Outage

If VLANs vanish across the campus, stop propagation first and diagnose second. The sequence that actually works:

Switch(config)# interface range gi1/0/1 - 48
Switch(config-if-range)# shutdown
Switch(config)# vtp mode transparent
Switch(config)# vlan 10
Switch(config-vlan)# name USERS
Switch# show vtp status

1. Shut the trunks (or physically pull them) to isolate the offending switch.
2. Put the suspect switch in transparent or off mode so it can no longer advertise.
3. Rebuild the correct VLAN database on the remaining switches, or let them re-learn from a known-good server.
4. Only then re-enable the trunks one at a time, checking show vtp status and the VLAN count after each.

Disabling VTP on a live network is done from the edges inward, never from the core outward, because the core carries the trunks that propagate the bad database.

VTP Traps, Counters and Monitoring

VTP is invisible until it breaks, so wire it into monitoring before you need it. vtp trap enable generates SNMP notifications when the VLAN database changes, when the domain changes, and when a switch detects an inconsistency. On the receiving side, show vtp counters reports how many summary and subset advertisements each switch has sent and received, along with any configuration errors. A switch that shows received advertisements but no configured VLANs is being updated by a domain it does not belong to, or is failing the password check - both are worth an alert rather than a manual review.

VTP and Spanning Tree Interactions

A VLAN that exists on one switch but not on its neighbour is one of the more confusing Layer 2 failures, and VTP is usually the cause. When a VLAN disappears from a switch, its ports fall back to VLAN 1, its STP instance for that VLAN is removed, and the spanning-tree topology silently changes shape. The symptom is often reported as "STP is flapping" or "the trunk is blocking" when the real fault is a VLAN database mismatch. Before you debug spanning tree, run show vlan brief on both ends of the trunk and compare the VLAN lists directly. Consistency matters for native VLAN matches too: a native VLAN mismatch is a common VTP-adjacent misconfiguration that shows up as a spanning-tree inconsistency warning on the trunk.

Production Risks and Mitigations

Cisco itself stresses the trade-off: ease of administration versus the risk of a network-wide VLAN disruption or STP loop. In modern networks many engineers set every switch to vtp mode transparent (or off) and manage VLANs per switch or with automation. If you do run server/client VTP, keep the revision discipline religiously and never let a VLAN span the entire campus unnecessarily. Layer 2 hardening continues with PortFast and BPDU guard, and see Arista EOS VLAN configuration for a VTP-free alternative.

VTP Versus Manual or Automated VLAN Provisioning

Most large campuses land on the third option, using VTP only as a legacy fallback. If you are automating anyway, compare Ansible network modules against a declarative platform approach in NETCONF, RESTCONF and gNMI compared, and track the resulting VLANs as inventory in NetBox IPAM.

VTP Operational Checklist

• Never put a used switch onto a production trunk before its revision has been reset or it has been placed in off mode.
• Ensure the domain name and password match exactly on every switch, including case.
• Enable VTP traps so the monitoring platform sees domain and revision changes.
• Keep a written record of VLAN IDs, names and the current revision, so an unexplained change is obvious.
• Verify with show vtp status on at least two switches after every VLAN change, not just the server.
• Prefer VTPv3 with a primary server, or turn VTP off entirely, on any network larger than a few switches.

原文链接：https://www.cisco.com/c/en/us/support/docs/lan-switching/vtp/10558-21.html