VLAN Trunking Protocol, or VTP, allows VLAN information to be managed from one or more switches and automatically advertised to all switches in the same administrative domain. All VTP-enabled switches in the same VTP domain can then update their VLAN databases to maintain consistency throughout the switched environment. With the alternative being adding and maintaining individual VLANs on each switch, VTP can dramatically increase administrative efficiency.
Switches can only participate and be configured for a single VTP domain. Each switch within that domain must have the same VTP domain name configured otherwise VLAN database information will not be synchronized. Because each switch can only be configured with a single VTP domain, it will only listen and act on VTP advertisements it hears that match its own configured VTP domain name.
VTP advertises the VLAN ID, name, type, and state for each VLAN. VTP does not advertise which switch interfaces are assigned to VLANs. That means VLANs must still be assigned to specific access ports using the switchport access vlan command on each switch.
VLAN trunking Protocol has been updated over the years and currently exists in three versions: VTPv1, VTPv2, and VTPv3. VTPv1 is often the default version of VTP running on Cisco IOS switches. Even new platforms that have full VTPv3 support usually default to VTPv1 unless configured otherwise. VTPv1 provides basic VLAN learning across normal-range VLANs only (1-1005).
VTPv2 was developed to overcome many of the limitations of VTPv1, including the following:
- Support for Token Ring VLANs – Since Token Ring VLANs are not used in Ethernet networks, this enhancement has lost relevance.
- Support for Unknown TLVs – Type-Length-Value records, commonly referred to as TLV records, can be used in VTP messages to provide additional information. A switch running VTPv1 drops all unknown TLVs from received VTP advertisements – preventing them from being passed on to other devices. Switches running VTPv2 keep all TLV records as received, even if they are unrecognized.
- VLAN Database Consistency Checking Improvements – VTPv2 makes the VTPv1 VLAN database constancy checking process more efficient by eliminating redundant checks from different sources(CLI, SNMP, VTP).
VTP Version 1 & 2 Modes
Switches in VTP server mode have full control to add and make changes to VLANs. All changes are advertised out to all other switches. Each domain has at least one VTP server.
Switches in VTP client mode cannot add or change VLANs, but they do send periodic VLAN database advertisements and can change their configurations to match those they hear.VTP servers and clients store the VLAN configuration in a vlan.dat file in flash memory.
Switches running VTP version 1 or 2 do not allow stopping the VTP service on the switch. However, VTP transparent mode allows an administrator to effectively disable VTP’s functionality on the local switch, while still forwarding incoming VTP messages to VTP neighbors. Transparent mode switches require their VLANs be manually configured and maintained, but do not inhibit VTP message forwarding from other VTP switches.Many sources, including earlier Cisco documents, claimed that switches running VTPv1 in transparent mode would forward VTP messages only if the domain and version information in the message matched that of the transparent switch. It was also stated that switches running VTPv2 in transparent mode would forward VTP messages regardless of the domain or version information. Real-world tests show that transparent VTPv1 and VTPv2 switches without a domain name configured forward all VTP messages. A switch configured with a VTP domain only forwards messages if the domain name matches that of the switch.
VTP Configuration Revision Number
VTP switches use an index called the VTP configuration revision number which is sent with VTP advertisements. The configuration revision number helps to identify changes to the network by increasing by one every time a change occurs. Every switch stores the revision number of the last advertisement they heard. If a switch receives an advertisement with a higher revision number than is stored locally, its configuration is changed to reflect the new advertisement and forwards the advertisement to it’s neighbor switches.
If the revision number is the same as in its database, it simply ignores the advertisement. Finally, if the number in the advertisement is lower than the number stored in its database, the switch will respond back with more current VLAN information.When running VTPv1 or VTPv2, it is a best practice to set the revision number to 0 before inserting a new switch into a production environment. Switches in transparent mode have a configuration revision number of 0.
There are two ways to reset the revision number to 0:
1. Change to transparent mode, then back to server.
2. Change the VTP domain name, then change it back.
VTP Version 1 & 2 Message Types
VTP messages are sent and accepted on switch trunk interfaces to share VTP information to other switches in the VTP domain. Access ports do not send or accept VTP messages.
The following message types are used by VTPv1 and VTPv2. Surprisingly, Cisco has not made the VTPv3 message types publicly available.
Sent from all switches every 300 seconds (5 minutes) and after any VLAN-related changes (added, removed, renamed). Summary advertisements carry VTP domain name information, revision number, ID of the last updater, time of last update, MD5 checksum of of the VLAN database and password, and a list of subset advertisements to follow. Summary advertisements do not contain the VLAN database contents; that is the purpose of VTP subset advertisements.
VTP servers send subset advertisements after a VLAN change occurs. Subset advertisements follow summary advertisements and carry the full contents of the VLAN database. Subset advertisements are limited in terms of the amount of information they can carry. Larger VLAN databases will require multiple subset advertisements per summary advertisement.
Clients and servers can requests any VTP information they don’t have. The server will respond with a summary advertisement and subsequent subset advertisements. Advertisement requests are sent when a VTP client switch is restarted, when a switch enters client mode, or when a switch receives a summary advertisement with a higher configuration revision number than its own.
When VTP pruning is enabled, VTP clients and servers send join messages every 6 seconds. The join messages indicate whether each VLAN is active or unused (edible for pruning).
VTP Updates and Operation
The diagram above outlines how and when VTP version 1 and 2 updates are sent.
- A VLAN add, update, or delete occurs on a VTP server.
- The configuration revision number is incremented by 1 on the VTP server.
- The VTP server advertises its new VLAN configuration database represented by the higher revision number.
- When VTP updates are received, the configuration revision number is compared to the current number.
- If the received number is greater (newer) than the current value, the VLAN changes are applied.
Cisco switches default to VTP server mode, but do not start sending VTP updates until the switch has been configured with a VTP domain name. After a switch has been configured with a VTP domain name, it begins sending VTP updates including the VLAN database and configuration revision number after each VLAN change.
If a VTP client does not have a VTP domain name configured, but receives a VTP update, it will assume the domain name of the first VTP message it receives. The only configuration required in this case would be to change the mode from server (default) to client.
VTP Synchronization Risks
If a VTPv1 or VTPv2 switch (server or client) is inserted into a production VTP domain with a higher configuration revision number than the last domain advertisement, a VTP synchronization problem occurs. All of the other VTP servers and switches will proceed to update their VLAN database to match that of the newly-added switch. The results can be catastrophic – potentially overwriting the VLAN database on all switches in the environment and disabling access ports. A common example is if a lab switch is re-added to the VTP domain without first erasing the configuration and deleting the vlan.dat file.
This could also happen if multiple VTP servers are running in the network and trunk failures occur. If changes are made on one of the servers, the VTP configuration databases will differ and be merged once the trunk connection is restored. The formerly disconnected server (now with the higher VTP revision number) will then overwrite the VLAN database of all switches.
Note that even VTP clients can initiate VTP updates. This means a VTP client with a higher revision number can update the VTP database on other VTP clients and servers.
In summary, the following conditions must occur for a VTP synchronization event to occur. This can be originated from a switch in client or server mode.
- The switch is connected via a trunk link.
- The VTP domain name matches that of the rest of the domain.
- The switch has a revision number higher than that of the current VTP domain.
- If passwords are used in the domain, the switch must be configured with a matching password.
VTP Synchronization Protections
When VTPv1 or VTPv2 is used, the use of VTP domain passwords provide the greatest protection to unintentional VTP VLAN database overwrites. When a VTP password is configured, VTP advertisements contain an MD5 hash of both the VLAN database and the VTP password. Switches receiving VTP updates compute an MD5 hash of the received VLAN database contents and its own configured VTP password. If the hash comparison produces a match, that means that the sending switch and the local switch are using the same VTP domain password and the contents of the VLAN database have not been modified in transit.
An important point to understand is that password-protected VTP advertisements using MD5 hashes do not encrypt the VTP advertisements or provide any message confidentiality. Instead, they simply confirm that the switches are configured using the same administrative passwords – preventing rogue switches or agents from propagating VLAN database changes.
The introduction of VTPv3 changed much of the way legacy VTP operates. These enhancements ultimately make VTPv3 a more stable and secure implementation.
Primary and Secondary Server Roles
VTPv3 split the server role into two groups – primary servers and secondary servers. A primary server can modify VLANs and their attributes in the same way v1 and v2 servers could. There can only be a single primary server per domain however. Since the primary server role is a runtime state, when a switch holding the primary server role is reloaded it will come back up in the secondary server role.
A secondary server cannot make any VTP or VLAN changes, but is eligible to be promoted to the role of primary server. The primary server role is not stored in the switch configuration, rather it is a runtime state that can be revoked if requested by another v3 server. Allowing only a single primary server to make changes to VTP domain contents at any given time significantly reduces the likelihood of unintended VLAN changes – a common concern with v1 and v2 deployments.
Unlike VTPv1 or VTPv2, VTPv3 allows encrypted domain passwords to be stored which cannot be displayed back as plaintext. The hashed version of the password can then be added to other switches in the VTPv3 domain.
When a switch operating in server mode needs to be promoted to primary server mode, the plaintext domain password is required to be reentered.
Extended and Private VLAN Support
Support for extended-range VLANs and private VLANs was added in VTPv3. Previous versions required transparent mode if extended VLANs were used. One outstanding limitation of VTPv3 is related to pruning. VTP still only prunes normal-range VLANs.
VTP Off Mode
VTPv3 supports a new “off” mode in which the switch does not participate in VTP operations and drops all VTP messages. VTPv3 also allows disabling VTP on a per-trunk interface.
More Than Just VLANs
VTPv3 has expanded its implementation to support message delivery for non-VLAN related information. In this sense it is simply a message delivery platform for database elements. The best example of its alternative use is in Multiple Spanning Tree. VTPv3 natively supports the distribution of MST region configuration among all switches in a VTP domain. This makes MST migrations and changes much easier and is completely unrelated to the local VLAN database.
Reseting Configuration Revision Numbers
VTPv1 and VTPv2 permitted resetting the configuration revision number of a local switch to 0 by configuring the switch to transparent mode and back. VTPv3 removed that method. Instead, the revision number can only be set to 0 by modifying the VTP domain name or by configuring a VTP password.
VTP Version 1/2 Compatibility
If a VTPv3 switch detects a connected switch is running VTPv1 or VTPv2, it will fall back to VTPv2 operation on that port. If the connected switch only supports VTPv1, VTP communication will break as VTPv1 and VTPv3 are incompatible.
VTPv3 Synchronization Protections
VTP version 3 was designed with additional synchronization safeguards to prevent accidental VLAN database overwrite events. As discussed in the VTPv3 section above, VTPv3 introduced the concept of a primary server. The primary server is the only switch in a VTPv3 domain that can make VLAN database changes and only one switch can hold the primary role at any given time.
VTPv3 servers that do not hold the master role are considered secondary servers. Like clients, secondary servers are not able to make any changes to the VLAN database. Secondary servers can be promoted to the role of primary server – requiring the domain password to be reentered by an administrator. That process will automatically demote the previous primary server to a secondary server role.
All secondary server and client switches’ VLAN databases in the domain will match that of the primary server. For VTPv3 server and client switches to accept and share the VLAN database, they must agree on both the domain name and primary server (identified by its base MAC address). This means that for a VTPv3 client or server switch to to overwrite a VLAN database of another VTPv3 switch, it must have the following:
- A higher configuration revision number
- The same VTP domain name configured
- Agree on the same primary server MAC address
- The same VTP password configured
That is certainly a more substantial list to meet compared to VTPv1 or VTPv2, making VTPv3 less prone (but not immune) to accidental VLAN database overwrite issues.If two or more VTPv3 switches do not agree on the identity of the primary server, the situation is called a conflict. Conflicting switches do not accept VLAN database changes even if all other VTP parameters match.
This feature is the secret to the database overwrite prevention in VTP version 3. If a switch is removed from the environment, the only way its VLAN database can be modified is if it is promoted to the role of primary server. If it is promoted, VLANs are modified, and it is reconnected to the network, its primary server identity (now itself) will not match that of the rest of the network and a conflict occurs. In this example, the switch’s VLAN changes will not be propagated.
Configure VTP Version
Most Cisco switches default to VTP version 1. You can see all switches are running VTPv1 in the show vtp status output below.
To change the VTP version, use the vtp version command from global configuration mode. In this example, we will be changing the switches to VTPv2.
Configure VTP Domain Name
All Cisco switches default to VTP server mode with a VTP domain name of null. Switches will not send VTP updates out active trunk interfaces until the VTP domain name is changed. This means that in order for a VTP domain to actively propagate VTP updates, at least one switch must be in server mode and have a VTP domain name manually configured.
In this example SW1 and SW3 are in server mode. SW2 is in client mode. SW1 is configured with a VTP domain name of LAB1, which is then propagated to both SW2 and SW3.
After SW1 updated SW2 and SW3 with its VLAN database, we can see from the show vlan brief output that the VLAN list matches on all switches.
Configure VTP Pruning and Password
VTP pruning is a feature that limits VLAN learning via VTP to switches that do not have any ports configured as members of that VLAN. VTP pruning only applies to normal-range VLANs.
A VTP domain password of SECUREP@$$ is added to SW1 below to limit accidental VLAN database overwrites. After VLAN 61 is added, the configuration revision number is incremented to 11.
The same VTP password is added to SW2 below. After the password matches, the VTP revision number is automatically updated to 11 and the VTP databases are synched. Notice however that VLAN 61 is still not present in the local VLAN database of SW2. This is because pruning was enabled on SW1 and SW2 does not have any interfaces assigned to it. After interface Gig 1/0/15 is assigned to VLAN 61, VTP automatically extends the VLAN to SW2.
Configure VTP Version 3
Enabling VTP version 3 is simple; use the command vtp version 3 from global configuration mode.
Recall that VTPv3 requires a switch be elevated to the primary server role before any VLAN modifications can be made. This is accomplished using the vtp primary command. Below, SW1 receives the message “VTP VLAN configuration not allowed when device is not the primary server for vlan database.” when it attempts to create VLAN 62 because it is currently in the secondary server role. After the do vtp primary command is issued, the “No conflicting VTP3 devices found” output confirms that all VTP switches int the VTPv3 domain agree on the identity of the current primary server and share its VLAN database.
VTP Version 3 Off Mode
VTPv3 can be disabled either globally on a switch using the vtp mode off command or on a per-interface basis using the no vtp command in interface configuration mode.
Once a switch is configured for any other mode from VTP mode off, all existing VLANs will be deleted (except Cisco-defined VLANs 1, 1002-1005).