N.B. All configurations are based off the lab build seen in the introduction post.
There are three versions of the Cisco proprietary VLAN Trunking Protocol (VTP), 1, 2 and 3. Versions 2 and 3 are generally used in most modern deployments so I would expect questions and configs to be focused around both those versions. However version 1 is the default, enabled-out-of-box, version and that means understanding the differences across all 3. After creating the VLANs on my first switch, I can verify the VTP settings through show vtp status.
- Shows the VTP versions that the switch is capable of supporting
- Shows the current version running (1 is default)
- If set, shows the configured VTP domain
- Tells you if VTP Pruning is enabled
- Tells you what VTP mode this switch is running in (Server is default)
- Shows the configuration revision. This increments by 1 anytime a Layer 2 VLAN configuration is altered.
As you can imagine, each version has built upon its predecessor to meet the fast changing requirements for office, campus, and data centre switch deployments. Before a review of the versions, we’ll need to cover off the modes as well.
The default out-of-box mode. You should only have one VTP Server, per VLAN, in your network. If there are two switches set as a VTP Server, the higher configuration revision always wins out which can leave your network vulnerable to a VTP attack. In addition to this vulnerability, a switch in Client mode can override a switch in server mode if its configuration revision is higher. This risk is mitigated through shutting down unused ports and isolating your VTP configurations via domains and passwords. There is no supported way to manually set the revision number on a switch however it can be reset to zero by changing the switch to transparent mode.
Switches in Client mode cannot create, delete or modify their Layer 2 VLAN config and so are completely relying upon the Server to tell it what the config should be. For troubleshooting purposes it is not uncommon to set a switch temporarily to Transparent mode which will allow you to make an alteration before setting it back to Client to see what happens. This helps identify if a Client switch is still receiving appropriate updates from its Server.
Transparent mode is the hybrid, lone wolf mode. It gets to manage its own VLAN database but won’t tell other switches what they should be doing either. It was designed to continue forwarding any VTP frames received on Trunk ports through the network to assist with propagation. This is useful if you have one switch higher up a chain running in Transparent mode but still want switches beyond it to receive their configurations from the Server.
V1 brings in the core elements of VTP has seen very little alteration over the years. As noted, it is enabled by default and can operate in all three modes. It is limited to the lower VLANs and tops out at 1005. If your network needs to support the extended VLAN range (1005-4094), you’ll need to jump all the way up to Version 3.
Almost identical to Version 1 except it brings in support for Token Ring Networks, back whenever they were all the rage. One notable difference is Transparent mode will forward all VTP frames regardless of domain/password. In version 1 the frames are only forwarded if the domain/password match.
The largest changes occur here as security is altered to protect against VTP Revisions wiping out whole networks as described above and passwords were no longer stored in clear text within the configuration.
Other features introduced include:
- Support for Private VLANs
- Support for the extended VLANs (1005-4094)
- Support for multiple VTP instances on a single switch
- Per port configurations if required
- The ability to turn VTP off
- Introduction of Primary and Secondary Servers (Default is Secondary)
In the last post the Layer 2 and 3 VLANs were created on a single switch but now I want to propagate all the Layer 2 VLANs across to my second switch
A seen earlier, version 1 is already active on my switch so I’ll just create a domain to allow for basic propagation. I’ve included a password here which Cisco’s documentation states:
You can configure a password for the VTP domain, but it is not required. If you do configure a domain password, all domain switches must share the same password and you must configure the password on each switch in the management domain. Switches without a password or with the wrong password reject VTP advertisements.
vtp domain rippleslab
vtp password rippleslab
On switch 2, set the VTP mode as client. In the default version (1) this is good enough in a small network for protection but ideally version 3 would be used to ensure the primary server is always the switch you intend it to be.
vtp mode client (vtp mo cli)
show vtp status
Now I’ll need to enable a trunk port between the my two switches Rip-3560-1 and Rip-3560-2. I’m not going for bonding (Etherchannel) yet so it is just interface fastEthernet 0/9 on both switches for now.
int fa 0/9
switchport trunk encapsulation dot1q (swi tru enc dot)
switchport mode trunk (swi mod tru)
spanning-tree portfast (spanning-tree portf)
The VLANs still won’t propagate until the VTP Domain AND Password have been set like switch 1. Repeat the step above to set them and do a show vtp status after a few seconds and the VLAN configuration should be there.
A final validation is show vlan to check all the VLANs are there.
This has all operated at Layer 2 through the transfer of packets across the Trunk ports without the need for a management IP to be configured. Once I do configure it, inter-switch comms will be available at Layer 3.
Version 3’s most important feature is the primary server simply due to the enhanced protection provided through this. There’s not a whole lot to it to enable the version but ensure all your switches are on at least version 2 prior to turning this on. Jumping back to switch 1:
vtp version 3
To ensure it is the primary VTP server you need to (oddly) go back to exec mode and either force it to become the primary or tell the switch to check first before confirming.
— Wait 20 seconds whilst the switch scans for other VTP servers —
Final validation will list this switch as the Primary Server
The final VTP command to go through will be to tell all switches to prune unnecessary traffic flooding their trunk links if required. This is enabled on the VTP Server which will in-turn enable across all switches within the domain. VTP Pruning trims packets that would normally be dropped at a destination switch from even traversing a trunk port, thus saving bandwidth. Some VLANs, such as VLAN 1, are ineligible for pruning and by default only VLANs 1-1000 are eligible meaning extended VLANs are never pruned.
To turn it on, simply type in
— Check Confirmation —
show vtp status (validation)
show interface trunk – Lists Trunks and their permitted VLANs
show vtp counters – Lists some VTP stats
show vtp devices – Version 3 only. Shows Primary Server conflicts.
Other useful information
You could successfully have switches running all 3 VTP versions in the same network as long as the domain was the same.
VTP versions are backwards compatible all the way through but only by 1 meaning Version 1 can’t directly talk to Version 3. However, the caveat is they must still be able to support the higher version even if they aren’t running it.
A Version 3 switch won’t accept configuration changes from a switch running a lower version.
If a switch is running in Version 1 but receives an advertisement from Version 3 it will automatically move to Version 2.
- A drag and drop style question with the different features of each version.
- Configure switches with a VTP version that allows for extended VLANs as minimum.
- Configure switches with a VTP version that advertises Private VLANs as minimum.
- Configure switches with a VTP version that will forward VTP frames regardless of domain and version when in transparent mode