What is VTPv3? VTP version 3 is the third version of the VLAN trunk protocol and enhances its initial functions well beyond the handling of VLAN matters. There is a document at Cisco.com about VTPv3. Let’s dig into that.
Features
The document lists the following key features.
- Protection against data overwrites.
- Support for VLAN numbers up to 4096
- Support for exchanging information regarding PVLANs
- Support for propagation of other databases (not just VLAN data), specifically MST databases but there are hooks for more in the future.
There is a brilliant line here “VTP…is designed to simplify administration and to reduce unintended configuration errors.” Without a doubt VTP is responsible for some of the biggest outages I have ever seen because of VTP revision problems when new switches are inserted into the network and not many networks today run VTP for exactly that reason.
The paper notes that VTPv3 uses an entirely new code base. This is Cisco-speak for new software and you should look out for bugs for a while.
Where It Would be Useful?
One of the most common configuration errors in† data centre occurs when someone fails to configure the VLAN database on all switches. In this case, everything works until a failover occurs and, because the VLAN isn’t available on the failover switch, a major problem occurs. This situation is difficult to detect quickly since the failover event often obscures the actual cause.
On the other hand, I have seen an entire data centres taken offline because a junior engineer plugged in a new switch at the top of a new rack and requiring physical intervention on every switch. For this reason, VTP is disabled in most places.
VTP – Let’s Recap, It’s Been a Painful Journey
In large campus-style LAN (Universities / Large Enterprise) the automatic propagation and consistency of VLAN allocation means that VTP is a valuable tool for reducing the cost of ownership. In is typical that hours we wasted maintaining and resolving VLAN numbering and allocation issues, especially in networks where documentation and records are not tightly maintained. The historical campus-wide outage is the stuff of legend and VTP is not usually enabled here either.
VTP was intended to make administration of Layer 2 switching domains easier by automatically propagating VLAN details to all switches in a domain. It would be fair to say that in 1999 switching domains were not that big, and administrative control was handled by very few people and often just one person. I think that VTP failed us when our networks got very large and the shortcomings of the protocol were exposed in a large team that would have at least some poorly trained people.
Then we had the change from a separate database in the vlan.dat file to the main IOS configuration which was handled badly. Because it seems to me that there was no consistent approach for the developers I conclude VTP wasn’t going anywhere. VTPv3 was introduced in CatOS 8.1, but only in Dec2008 was included in the C6500 IOS software. Therefore modifications were being made on the fly, not in a consistent planned way.
These problems, plus the huge outages I mentioned earlier, mean that VTPv3 will need a really good story to get engineers and management to agree on its implementation.
Good Things in VTPv3
So what’s the goodness in VTPv3 that might make you interested?
No Automatic Setup of VTP Domain
In VTPv2, a factory default switch which receives a VTP message will automatically configure to be in the VTP domain. It’s counter-intuitively a good idea, isn’t it? But, in the real world, automatic configuration makes you scared. VTPv3 forces manual configuration.
Support for all VLAN Numbers
Well, except for 1000-1017 which are reserved, you can use VTP for propagating all VLAN numbers in accordance with the IEEE. This is the probably the most important feature.
Security
The VTP domain password is secured in the database and in transmission.
Database Propagation Fixed
The other vital ingredient. “With VTP version 3, only a specific device in a domain, a primary server, is allowed to update other devices.” Logically, only one server per domain can be a primary server. Secondary servers can be defined, but they can never be configured and the secondary server will update its database from the Primary exclusively.
When you configure the Primary VTPv3 server, its checks the VTP messages to determine if any other servers are Primary before asking for confirmation. See below (taken from the Cisco Web Site)
Catalyst6500-1#vtp primary vlan
This system is becoming primary server for feature vlan
No conflicting VTP3 devices found.
Do you want to continue? [Confirm]
*Jul 8 12:34:20.047: %SW_VLAN-SP-4-VTP_PRIMARY_SERVER_CHG: 00d0.bcd2.0c00 has become the primary server for the VLAN VTP feature.
MST Configuration
The VTPv3 database is extensible, thus allowing other information to be exchanged and replicated. Currently this includes Multiple Spanning Tree configuration. Which is a good idea since it needs to be the same on all switches and it can be painful changing the configuration on a lot of devices when you don’t
What’s the Bad News?
Limited Device/Software Support
At time of writing, VTPv3 is only available for 12.2.33SXI releases on the C6500 for late models of Supervisor, 12.2.50SG2 on the C4500 with late model of Supervisor (Sup2+/4/5/6). This means that you need to carefully check all the modules in your chassis to make sure they are compatible with this code train.
Interoperability
“VTP3 interoperates with VTP version 2 but not VTP version 1. For devices that are capable of running VTP version 2 but are running in VTP version 1 mode, a change to VTP version 2 is triggered by the VTP version 3 devices. Before considering VTP version 3 for your network it is recommended that you verify if all switches in the existing or prospective VTP domain are capable of running in VTP version 2 modes.” – got that? For a big network with old bits in it, it gonna be painful.
Am I going to Use It?
Yes, in DMZ’s that use PVLANs this is going to be a fantastic way to
- Solve my problems with firewall/security people who don’t understand VLANs and especially PVLANs.
- More consistent operation for VLANs leading to less outage when people don’t configure the VLANs correctly.
And because DMZ’s are reasonably small networks (you DMZ’s are on physically separate switches aren’t they?), it will be easy to implement on just a few pieces of kit that are tightly controlled.
Anything Else?
I would be just about guessing here. But I think that VTPv3 will be a vital part of the Data Center Ethernet and the Shortest Path Bridging standards from the IEEE. There needs ot be a lot of synchrony between switches that are going to exchange QoS, SPBB and all the other information that Data Center Ethernet (or Converged Enhanced Ethernet, or Data Center Bridging – whatever you want to call it) will need to function. I suspect that we will all see a lot more of VTPv3 in the next couple of years.
—Reference from https://etherealmind.com/vtp-3-making-comeback-review/
More Related Reading: VLAN Trunking Protocol (VTP) & VTP Modes
