The Cisco VLAN Trunking Protocol (VTP) is an option for those who have selected Cisco as their switching platform provider. VTP offers a method of global VLAN assignment that lessens the amount of configuration work that is required by the networking staff. This article takes a look at some of the most common configuration mistakes that can cause confusion when performing VTP troubleshooting.
There are a couple of different common Cisco VTP configuration mistakes and misconceptions which can confuse those not overly familiar with its operation. Let’s go over those misconceptions now.
There are a couple of VTP configuration parameters that must match for switches to properly communicate; these include the VTP domain, password and VTP version. If any of these is misconfigured then the switch that is misconfigured will not communicate with other VTP switches.
VTP has three modes of operation: Server, Client, and Transparent. By default, switches are configured as VTP servers and will operate with other VTP switches (as long as the parameters match). Only servers are allowed to configure the VLANs that are advertised by VTP — VTP clients are not allowed to configure VLANs at all. Switches that are in VTP transparent mode do not participate with other VTP switches but do forward VTP traffic; these switches are able to configure VLANs but they are specific to that switch only and are not advertised by VTP.
VTP only communicates over switch trunks. What this means is that if switches are not connected via an IEEE 802.1q (or ISL) trunk no VTP communication will occur between switches.
One quite serious — and often unexpected — issue is when VTP configuration revision numbers are not monitored. When VTP is enabled on a new switch it initially uses a revision number of 0, each time the VTP configuration changes this number is incremented. When switches communicate, the switch that has a VTP revision number that is the highest will be considered the most current, and other VTP switches will alter their configurations based on this revision number.
The problem arises when a switch is taken from another environment and placed into the current environment without clearing its VTP revision number. For example, if a switch was located in a lab environment and the VTP and VLAN configurations were being tested, then the VTP revision number would quickly reach a high value. If this switch is then taken from the lab environment without clearing its VTP revision number, then placed into another environment where the VTP revision number is lower, it will automatically be considered the switch with the most recent configuration, and all other VTP switches will alter their configurations to match. If this switch was moved from a lab environment to a production environment the switch configuration of all production VTP switches would be altered to match the last lab VTP configuration, potentially causing a number of switching issues.
On modern networks, the use of VTP (and VLANs) in general is becoming less recommended in favor of layer 3 switching. When using layer 3 switching from the core down to the access layer switches VTP (and VLANs) are not used outside each switch. If this trend continues (and it most likely will), the use of VTP will become less and less common — but until then it is important to have a handle on how it operates and is properly configured. Hopefully the content of this article will help in troubleshooting (or avoiding having to troubleshoot) these potential issues.
Editor’s Note: Check out these additional resources on the Petri IT Knowledgebase focused on troubleshooting and installing Cisco networking equipment.
• David Davis discusses setting up VTP on Cisco Switches
• Joe Rineheart writes about Troubleshooting VLAN and Switch problems
• David Davis once again covers the topic by answering the question What is VTP?
• The Petri IT Knowledgebase forum on Cisco Routers and Switches is a great resources for troubleshooting Cisco networking problems.)