VTP Version upgrade

[Chad Parish]

My network is currently using VTP version 1 with MST.  The switches are all VTP version 2 capable and some VTP version 3.  I want to upgrade to Version 3 (and version 2 for those not capable of 3).  Do I simply make a version 3 capable switch the Primary Server then enable VTP version 3 on it.  I read that all other switches within the VTP domain will then upgrade accordingly.

How disruptive is such an upgrade, assuming the switch I make Primary server is already the STP Root with all vlans.

[Peter Paluch · Accepted solution]

Chad,

I am not sure if you want to upgrade to VTPv3 to provide a domain-wide synchronization of VLANs or MST configuration - or perhaps both. You did not include that information.

Anyway, a couple of things to watch out for:

• First migrate your entire domain to VTPv2. Only then start migrating switches to VTPv3. VTPv3 attempts to fall back to VTPv2 on a per-port basis if a VTPv2 neighbor is detected, however, it will not interoperate with VTPv1.
• You will have to activate VTPv3 manually on each switch. As opposed to version 1 and 2 where the version change on a Server switch propagated throughout the domain, VTPv3 does not operate this way. Each switch intended to act as a VTPv3 switch must be configured for v3 operation manually,
• You can configure a switch to be a Pimary Server only after it has been migrated to VTPv3 already. Also, the knowledge about a Primary Server will not propagate among v2 switches. Therefore, it is necessary first to migrate the whole network to v3 and only then start promoting a selected switch to the Primary Server role.
• VTPv3's ability to synchronize MST configuration is unique to v3 only. Switches that support v2 will not be able to synchronize the MST configuration over VTP.
• VTPv3 must be independently configured to synchronize VLAN information and to synchronize MST configuration. These two features are entirely independent.
• By migrating to VTPv3, no outage should occur because the information in VLAN database or MST should not be modified as a result of version migration. However, VTP pruning should be deactivated prior to migration, as this mechanism may cause nasty hiccups.
• In general, running mixed VTPv3/VTPv2 is not recommended. I have heard people having issues with this kind of setup. Most importantly, there is no protection against incidental VLAN database rewrites in the VTPv2 part of the network, aside from configuring all VTPv2 switches as clients.

Best regards,
Peter

[Chad Parish]

Thank you very much Peter, I really appreciate this feedback.  Yes, the idea was to have version 3 to provide vlan synchronization within a MST region.  

So most of our production switches will support version 3.  The only ones that do not are used simply for monitoring/management.  They can be placed to version 2 and I can always manually update their vlans and MST instances.

So my plan is to:

1. put all switches within the MST region into Transparent mode
2. disable VTP pruning
3. manually upgrade each to VTP version 3 (or version 2 for the management switches)
4. make one of the core 6509's the Primary Server 
5. place all switches back into Client mode, with the exception of the other 6509 which will be a secondary server

Does this sound like a sound plan?  And should I re-enable pruning?  

One more question, we use an active/active HSRP scenario, dividing the odd and even vlans between 6509 Cores, giving one 6509 the best revision number for instance 1 (even) and the other the best revision # for instance 2 (odd).  Will making one of the 6509's the Primary Server have any adverse affect to this?