VTP version 3 is the enhanced version to the previous VTP versions 1 and 2. This post covers the operation and important features & benefits of VTP version 3 when compared to VTP version 1 and 2.
VTP Version 3 Important Features:
- Protection against data overwrites in case “wrong” database accidentally being inserted into a VTP domain.
- Support for extended VLANs up to 4096
- Support for creation and advertising of PVLANs
- Support for propagation of other databases (not just VLAN data), specifically MST databases but there are hooks for more in the future.
- Improved server authentication(MD5)
- Interaction with VTP version 1 and VTP version 2
VTP Version 3 Operation:
VTP version 3 introduces the concept of transferring an opaque database in situations where VTP version 1 and VTP version 2 interacted with the VLAN process directly. VTP version 3 supports for both VLAN instance and a separate MST instance. By offering a reliable and efficient transport mechanism for a database, usability can be expanded from just serving the VLAN environment.
Two Different kinds of instances are in VTP version 3:
VTP instance: Either the VLAN database, the MST database, or the unknown database instance. This is also called the VTP Mode.
MST instance: Support for between 1 and 64 instances or mappings between VLANs and STP calculations: 1 MST STP calculation equals 1 instance.
The unknown DB instance serves as a placeholder for forthcoming new features.
VTP Version 3 Operation Modes:
VTP version 3 uses the concept of device roles like older Version 1 and2. In addition to the three well-known roles client, server, and transparent, a fourth role called off is now available. This role is tied with VLAN or MST instances for VTP version 3 operations not with physical devices.
• Transparent: In this mode a device saves local VLAN configuration in to a local permanent storage space NVAM. VTP messages are neither sent nor evaluated when received. The local configuration revision number is equal to 0 at all times. Received VTP messages are relayed out of a non-receiving trunk interface if the STP state for VLAN 1 equals forwarding. A domain check, as in VTP version 1, is not implemented.
• Client: A device using a local temporary storage space (for example, DRAM) to hold via VTP received information for runtime use. This information is used to update other devices, such as a device that is working as a server. Local configuration of devices in the client role is not possible. After booting, a client device issues a VTP message asking for the configuration of other VTP devices.
In the case of MST, the default MST configuration will be used at boot time until a VTP version 3 message arrives. Until then, all VLANs are assigned to the default IST instance.
• Off: Turning VTP to off allow a VTP domain to connect to devices in a different administrative domain. Such devices can be switches or servers at a customer or partner site.
This feature introduced in CAT OS 7.X and it is similar to transparent mode was offered. The difference between transparent and off mode is the termination of received VTP messages instead of relaying them. Off mode can be configured globally or on per port (for example trunk) base.
• Server: VTP3 expands and enhances the concept of the server role. Only one server per domain can be prompted to be a primary server. Client and secondary server devices receive a configuration from a primary server. A secondary server stores the received configuration in a local permanent storage space (for example, NVRAM) and updates other devices in the same domain and for the same instance. In the case of VTP version 1 or VTP version 2, a server can be manually configured via command-line interface (CLI) or Simple Network Management Protocol (SNMP). In VTP version 3, a secondary server cannot be configured manually but can receive updates, similar to a device owning the client role.
One server can be promoted to be a primary server for an instance. There are two instances available at the time of writing: the VLAN instance and the MST instance. Configuration changes can be made only at the primary server itself via either CLI (Telnet or Secure Shell Protocol) or SNMP. The role of a primary server for the VLAN database and the MST database can be divided among two different physical machines or handled by one machine alone.
For more details visit: http://www.cisco.com/en/US/prod/collateral/switches/ps5718/ps708/solution_guide_c78_508010.html
Filed Under: VLAN/VTP
About the Author: