VTP — VLAN Trunking Protocol

Mental model

If you have 50 switches and need to add VLAN 100 to all of them, you have two options:

1. SSH to each one and type vlan 100; name USERS. Tedious.
2. Configure VLAN 100 on one switch and have it auto-propagate to the others. That’s VTP.

The convenience comes with risk: if a switch joining the network has a higher VTP revision number, its VLAN database overwrites everyone else’s. A misplaced switch from a lab → entire production VLAN database wiped → every access port reverts to VLAN 1. Big outage.

For CCNA: know VTP exists, how it works, and why most production networks run vtp mode transparent (each switch maintains its own VLAN database, no auto-sync) instead.

The roles

Server is the source-of-truth. Client receives. Transparent does its own thing but passes VTP through to others. Off is total isolation.

The dangerous revision number

Every change to the VLAN database on a Server (or Transparent) switch increments its revision number. When a Client receives a VTP update, it compares the revision number with its own. Higher number wins — the Client’s database gets overwritten.

The disaster scenario:

1. Engineer powers up a lab switch that was previously in production, with revision number 47.
2. Connects it to a trunk in production. Production VTP is at revision 35.
3. Production switches see the higher number, accept the lab switch’s (empty) VLAN database.
4. Every access port in the production network suddenly thinks its VLAN doesn’t exist → no traffic forwards.

This has happened many times. The fix: always set vtp mode transparent on any switch before plugging it in. Or reset its VTP revision to 0 by changing the domain name briefly.

VTP versions

VTPv3 is what you’d actually deploy in 2026. It has a “primary server” concept — only one switch is authoritative, others can’t accidentally override. Still many environments run v1/v2 from inertia.

Commands

! Set the VTP domain (must match on all switches)
SW1(config)# vtp domain CORP

! Set mode
SW1(config)# vtp mode server                ! default
SW1(config)# vtp mode client
SW1(config)# vtp mode transparent
SW1(config)# vtp mode off

! Set version (v2 or v3 — affects feature support)
SW1(config)# vtp version 2

! Optional — password
SW1(config)# vtp password supersecret

! VTPv3 primary server (only this switch can change VLANs in the domain)
SW1# vtp primary

Verify

SW1# show vtp status
SW1# show vtp counters
SW1# show vtp password

Key fields in show vtp status:

• VTP Operating Mode: Server / Client / Transparent / Off
• VTP Domain Name: must match neighbors
• Configuration Revision: the number that determines who wins
• Number of existing VLANs: how many VLANs this switch knows about

Resetting the revision number

If you need to safely add a switch to an existing VTP domain, reset its revision number to 0 first. Three ways:

! Method 1 — change the domain name briefly (revision resets)
SW1(config)# vtp domain TEMPORARY
SW1(config)# vtp domain CORP-REAL

! Method 2 — change to transparent and back
SW1(config)# vtp mode transparent
SW1(config)# vtp mode client

! Method 3 — wipe vlan.dat (requires reload)
SW1# delete flash:vlan.dat
SW1# reload

Always do this before connecting the switch to a production trunk.

Why production often runs transparent

The “convenience vs blast radius” calculation. Pros of running everything in transparent mode:

• No risk of revision-number-based wipeout
• Each switch’s VLAN database is local — explicit and auditable
• Forced to update VLANs via config-management automation (Ansible, etc.) — generally healthier than relying on auto-propagation

Cons:

• Have to add VLANs on every switch separately (or via automation)

In modern networks with config management, transparent is the safer default. Auto-propagation of critical config across switches is a 2005-era convenience that doesn’t fit current best practices.

VTP Pruning

A different VTP feature: pruning removes VLAN broadcast / unknown-unicast traffic from trunks that don’t carry any access ports for that VLAN. Saves bandwidth.

SW1(config)# vtp pruning

Pruning is generally safer than VLAN propagation — manage allowed VLAN lists on trunks explicitly instead.

Common mistakes

1. Adding a lab switch to production without resetting revision. Wipes the production VLAN database. Has burned every CCNA learner at some point.

2. VTP domain name mismatch. Two switches with different domain names won’t exchange VTP info. Common after a config copy-paste mistake.

3. Running VTP servers everywhere. Defeats the point — any one of them can become the canonical source by being changed. Run one or two servers max; the rest as clients (or transparent in modern setups).

4. Forgetting password mismatch. Two switches in the same domain but with different VTP passwords → updates ignored. show vtp password to verify.

5. Confusing VTP with DTP. VTP synchronizes VLAN databases. DTP (Dynamic Trunking Protocol) negotiates trunk vs access mode between switches. Different things — both Cisco-proprietary, both can be disabled.

6. Trusting VTP to never break things. Mistakes happen. Always have a recent backup of running-configs and the VLAN database (show vlan brief saved somewhere).

Lab to try tonight

1. Three switches connected via trunks. Same VTP domain CORP.
2. Configure SW1 as server, SW2 and SW3 as clients.
3. On SW1, create VLAN 10, 20, 30. Verify with show vlan brief.
4. On SW2 and SW3, run show vlan brief — the same VLANs appear automatically.
5. On SW2 (client), try vlan 99. Should fail — clients can’t create VLANs.
6. The dangerous experiment: disconnect SW3, configure a totally different VLAN list on it locally, manually set a high revision (or change & change back the domain to bump it up), then reconnect to the trunk. Watch the production VLANs disappear. Restore from backup.
7. Bonus: convert everything to vtp mode transparent. Note each switch now maintains its own DB. Add a VLAN on each individually.

Cheat strip