Configure VTP on Cisco Switches

Learn how to configure, verify, and troubleshoot VTP on Cisco switches, including domains, modes, versions, pruning, authentication, and revision-number safety.

VLAN Trunking Protocol (VTP) is a Cisco-proprietary Layer 2 protocol that distributes VLAN database information between participating Cisco switches. VTP advertisements travel across trunk links, allowing switches in the same VTP domain to learn VLAN identifiers and names.

VTP can reduce repetitive VLAN configuration in a multi-switch campus network. For example, an administrator can create VLAN 10 on a designated VTP server instead of manually creating VLAN 10 on every switch. However, VTP can also propagate unwanted VLAN changes, so it must be deployed carefully.

How VTP Works

A VTP domain is a logical group of switches that share a domain name and participate in the same VTP information exchange. Switches normally need matching domain names, compatible VTP settings, and a working trunk before they can exchange useful VLAN information.

A VTP advertisement is a control message containing VTP domain and VLAN database information. Advertisements use trunk links between switches. An access link carries traffic for one VLAN and is not a normal path for VTP advertisements.

The VLAN database contains information such as VLAN identifiers, VLAN names, and other VLAN attributes maintained by the switch. The configuration revision number is a counter associated with the VTP database. A higher revision number is treated as newer than a lower revision number.

VTP Modes

VTP mode determines whether a switch can change VLANs locally and whether it synchronizes its VLAN database from advertisements.

Mode	Can Create or Modify VLANs Locally	Synchronizes VLAN Database	Forwards VTP Advertisements	Typical Use Case
Server	Yes, subject to platform and VLAN-range behavior	Yes	Yes	Central VLAN administration in a controlled server/client design
Client	Normally no for standard VLANs	Yes	Yes	Switches that receive VLAN information from a server
Transparent	Yes, using a local VLAN database	No	Yes, when the VTP version and platform support forwarding	Local VLAN control while allowing advertisements to pass through
Off, VTP version 3	Yes, locally	No	Behavior depends on platform and VTP implementation	Explicitly disabling VTP participation while retaining local VLAN administration

In server mode, the switch can create, modify, and delete VLANs and advertise the resulting database. In a server/client design, the designated server is the VLAN authority.

In client mode, the switch learns VLAN information from VTP advertisements. It normally cannot create, modify, or delete standard VLANs locally. A client still needs an operational trunk and matching VTP settings.

In transparent mode, the switch maintains its own VLAN database and does not synchronize that database with received advertisements. VLANs created on the switch are locally significant. Depending on VTP version and platform behavior, the switch can forward advertisements across its trunks without adopting their VLAN contents.

VTP version 3 adds an off mode on platforms that support it. Off mode disables VTP participation while allowing local VLAN management. Do not assume every Catalyst model or IOS release supports every VTP mode; verify the available commands on the target device.

VTP Versions

Version	Key Capabilities	Compatibility Considerations	Administrative Notes
Version 1	Basic VLAN database advertisements and domain operation	Older capability set; support for features and VLAN ranges is limited	Use mainly for legacy compatibility or simple demonstrations
Version 2	Improved behavior compared with version 1 and broader feature support on compatible platforms	Participating switches need compatible version settings; capabilities still depend on IOS and hardware	Common in basic CCNA-style labs
Version 3	Improved administrative control, primary-server concepts, stronger control over database changes, and enhanced support for extended VLANs where applicable	All devices must support the required version 3 features and be configured consistently	Often preferred for controlled modern deployments, but test platform-specific behavior first

VTP version compatibility is not simply a matter of choosing the highest number. Older switches may not support version 3, and some features vary by IOS release. A basic lab can use version 2 consistently on all participating switches. In real networks, carefully evaluate whether VTP is needed at all; transparent mode or version 3 with controlled administration may be safer than unrestricted server/client propagation.

An extended-range VLAN generally uses VLAN IDs 1006 through 4094. Whether extended VLANs are stored, advertised, or synchronized depends on the switch platform, IOS release, VLAN database implementation, and VTP version. Verify support before using extended VLANs in a VTP design.

VTP Pruning

VTP pruning reduces unnecessary flooded traffic across trunks. If a downstream switch has no active ports or other need for a VLAN, certain flooded frames for that VLAN do not need to cross the trunk toward that switch. Pruning can reduce broadcast, multicast, and unknown-unicast traffic.

VTP pruning is enabled in the VTP domain through the VTP server or the device designated to control the domain configuration. Trunks then determine which VLANs are eligible to be pruned based on downstream VLAN requirements.

The default VLAN and reserved VLANs are not pruned by default. VLAN 1 is a common example of a VLAN that remains present, and reserved VLAN ranges may also be excluded depending on platform behavior. Check the switch documentation and command output for the exact implementation.

Pruning does not replace deliberate trunk configuration. Use switchport trunk allowed vlan to state which VLANs are permitted on a trunk. Allowed-VLAN lists provide explicit design control; pruning only limits unnecessary flooding for VLANs that are otherwise permitted and eligible.

Basic VTP Configuration Workflow

Identify the switches that should participate in VTP and the trunk links connecting them.
Configure and verify trunking before relying on VTP synchronization.
Choose a VTP domain name, mode, version, and optional shared password.
Configure the designated VLAN authority as a VTP server if using server/client operation.
Configure receiving switches as clients, or use transparent/off mode when local VLAN administration is preferred.
Create VLANs on the designated server in a server/client design.
Verify that client switches learn the expected VLAN database.
Save the configuration and document the domain, mode, version, password policy, server role, revision number, trunk interfaces, and allowed VLANs.

Configure the VTP Server

configure terminal
vtp domain CAMPUS
vtp mode server
vtp version 2
vtp password <shared-password>
vtp pruning
vlan 10
 name USERS
vlan 20
 name VOICE
vlan 30
 name SERVERS
end

The password and pruning commands are optional. Use a consistent VTP version and password on every participating switch. Enable pruning only after confirming that it fits the topology and has been tested.

Configure the VTP Client

configure terminal
vtp domain CAMPUS
vtp mode client
vtp version 2
vtp password <shared-password>
end

The client needs an operational trunk to receive advertisements. In this design, create VLANs on the server rather than attempting to create them on the client.

Configure the Trunk

configure terminal
interface gigabitEthernet0/1
 switchport mode trunk
 switchport trunk allowed vlan 10,20,30
 no shutdown
end

Interface names and available commands vary by switch model and IOS release. The allowed VLAN list must not block VLANs that the design requires. During troubleshooting, also confirm that both ends agree on trunk operation and encapsulation behavior.

Configure Transparent Mode

configure terminal
vtp mode transparent
end

In transparent mode, configure VLANs locally. The switch does not adopt the server's VLAN database, even though it may forward VTP advertisements across trunks when supported.

VTP Authentication

A VTP password is an optional shared authentication value used with VTP advertisements. All participating switches must use matching domain and authentication settings. A password mismatch can prevent a switch from accepting advertisements even when the trunk and domain name are correct.

Typical symptoms include a client that remains at an old revision number, does not learn newly created VLANs, or reports inconsistent VTP information. Compare the password configuration where supported and verify the domain, version, and mode at the same time.

Two-Switch VTP Server and Client Lab

Use SW1 as the server and SW2 as the client. Connect them with an operational 802.1Q trunk and place both switches in the CAMPUS domain.

Configure the trunk on both ends before testing VTP.
Set the same domain name, version, and password on SW1 and SW2.
Set SW1 to server mode and SW2 to client mode.
Create VLAN 10 USERS, VLAN 20 VOICE, and VLAN 30 SERVERS on SW1.
Run show vtp status on both switches and compare the revision numbers.
Run show vlan brief on SW2 and confirm that the three VLANs appear.
Save the intended configuration after testing.

Creating or modifying VLANs on the server should increase its revision number. After the client receives the advertisement, its database should reflect the VLANs and normally show the corresponding revision state.

Transparent-Mode Comparison

Add SW3 as a transparent switch through trunk links. Create a local VLAN on SW3 and compare its VLAN database with SW1 and SW2. SW3 should retain locally configured VLANs and should not synchronize its database to the server's VLAN list.

When supported by the platform and version, advertisements can pass through SW3. This makes transparent mode useful when a switch must maintain local VLAN control while remaining in a trunked topology. Test forwarding behavior rather than assuming all IOS releases behave identically.

Verification and Monitoring

Command	What It Verifies	Important Output Fields
`show vtp status`	Overall VTP state	Domain name, operating mode, version, pruning status, configuration revision number, and supported VLAN ranges
`show vtp password`	VTP authentication state where supported	Configured or stored password information, subject to platform behavior and security considerations
`show vlan brief`	Local VLAN database and port membership	VLAN ID, VLAN name, status, and assigned access ports
`show interfaces trunk`	Operational trunk status	Trunking ports, native VLAN, allowed VLANs, allowed-and-active VLANs, and forwarding VLANs
`show running-config \| include vtp`	VTP-related running configuration	Domain, mode, version, password, and pruning commands when stored in the running configuration
`show running-config interface gigabitEthernet0/1`	Configuration of a particular trunk interface	Trunk mode, allowed VLAN list, shutdown state, and interface-specific settings

Start verification with show vtp status. Confirm that the domain, mode, version, revision number, and pruning state match the intended design. Then use show interfaces trunk to verify that the link is operational and that required VLANs are allowed and active. Finally, use show vlan brief to confirm local VLAN presence.

Safe Deployment and Recovery

Back up switch configurations and record the current VLAN database before making changes.
Inspect show vtp status on every switch before connecting an unknown device.
Check the incoming switch's domain, mode, version, password state, and revision number while it is isolated.
Reset or neutralize an unintended revision number according to the platform procedure.
Reconnect the switch only after confirming that its VTP state is safe and intentional.

A common lab method for resetting relevant VTP revision state is to change the incoming switch to a temporary domain, then verify the result:

show vtp status
configure terminal
vtp domain TEMPORARY
end
show vtp status

Changing the domain is a common approach, but exact behavior varies by IOS platform. Verify the revision number after the change. Do not rely on a reset procedure without checking the actual output.

Common VTP Problems and Causes

Symptom	Likely Cause	Verification Step	Corrective Action
Client does not learn VLANs	Link is not a trunk, domain mismatch, password mismatch, incompatible version, or client is actually transparent/off	Run `show interfaces trunk`, `show vtp status`, and `show vlan brief`	Correct trunking and VTP settings, then verify receipt of advertisements
VLANs disappear after a switch is connected	Incoming switch has a higher revision number and an outdated VLAN database	Compare `show vtp status` output and revision numbers while isolating the switch	Restore the intended database, reset or neutralize the incoming VTP state, and reconnect only after verification
Traffic reaches an unnecessary downstream trunk despite pruning	Pruning is disabled, the VLAN is ineligible, an active downstream port requires it, or the allowed list is too broad	Check `show vtp status`, `show interfaces trunk`, and `show vlan brief`	Enable pruning where appropriate and explicitly restrict allowed VLANs
Local VLANs are created but not received elsewhere	Switch is transparent, not the designated server, or has no valid trunk	Check VTP mode and trunk operational state	Use server mode for the designated authority or configure VLANs independently in transparent mode

Exam-Relevant Notes

VTP distributes VLAN database information; it does not route between VLANs.
VTP advertisements use trunk links, not ordinary access links.
Matching VTP domain names are required for normal exchange.
A higher configuration revision number is considered newer, which makes unknown switches dangerous to connect.
Server mode can create, modify, and delete VLANs and advertise those changes.
Client mode synchronizes VLAN information but normally cannot change standard VLANs locally.
Transparent mode uses a local VLAN database and does not synchronize to advertisements.
VTP pruning reduces unnecessary flooded traffic but does not replace allowed-VLAN configuration.
VTP version, password, domain, and platform support must be considered together.