VTP Domain Migration

[nucciocrd]

Hello, I have an issue with some switches that have been added to an existing network. I manually configured some VLANs (on the new switches) that are working correctly, and traffic is flowing as expected. However, I mistakenly configured the wrong VTP domain and password, so my VTP client has not downloaded the additional VLANs. The switch is still functioning properly because the initial VLANs were manually configured before it was added to the VTP domain. If I now want to change the VTP domain and password while the switch is in production, what would the procedure be, and would it cause any service disruptions, recalculations, or other issues?

[MHM Cisco World]

what can happened it can or can not effect your network, so best add correct domain and password in maintenance window

or you can make SW as transparent mode <<- this must do carefully in case you run VTP pruning

MHM 

[nucciocrd]

So, I could change the VTP mode to Transparent, then update my VTP domain and password with the correct ones, and finally revert the VTP mode back to Client. In theory, this should only add the missing VLANs and update my VLAN database without impacting traffic (hopefully)?

P.S.: VTP Pruning Mode is not enabled

[MHM Cisco World]

I will try this in lab and share result with you 

MHM

[paul driver]

Hello
you are correct 
change the switch mode to transparent which will set the vtp version of that switch to zero 
Then change the vtp domain of that switch
lastly change the mode back to client 
this should allow the switch to then receive the correct vtp database from the vtp server 

[Joseph W. Doherty]

What VTP version are you running?

Assuming VTP versions 1 or 2, I recall anytime you change domain name DB reference number is reset.  If correct, all you need to do is change domain name to correct domain name, i.e. you shouldn't need to transition through transparent mode.  However, change password to correct password first.

I assume you have a trunk to existing VTP domain, correct?

As to impact of this change, the switch to be changed is on the edge?

What variant of STP are you using, if any?

Unsure whether switch will start to generate BPDUs for VLANs learned via VTP (i.e. previously unknown) that are unused on the switch.

As a general suggestion, even changes you expect that should not impact the network (which I believe is the likely case in this instance), on production hardware, should be made during scheduled maintenance.

[nucciocrd]

The VTP version running is 1.

We do have a trunk on this switch (access layer) towards it's VTP Server (Distribution layer). On the trunk, we have included only the VLANs that were manually configured before adding the switch to the (incorrect) VTP domain. Therefore, in terms of functionality, the switch is operating correctly since it already has the only VLANs it needs.

Spanning tree mode is rapid-pvst on the access switch and pvst on the distribution switch.

[Joseph W. Doherty]

"Spanning tree mode is rapid-pvst on the access switch and pvst on the distribution switch."

In theory, that should work fine, but in practice, it's the type of thing that sometimes leads to unexpected issues.  Are you planning or working toward using just rapid PVST?

As to the rest, especially since you're manually tuning, I wouldn't expect any issues beyond possibly the VLAN names, on the access switch, being changed by VTP if they differ.

The major risk of adding a VTP "client", in versions 1 and 2, if it has the same domain name and a higher revision number, it will change the whole VTP domain to match it.  All a "client" precludes is making manual VLAN definition changes on that switch.

[nucciocrd]

The revision number on the access switches is set to zero because, when the VLANs were manually configured, the switch was in Transparent mode. Once deployed, it was switched to Client mode, which reset the revision number. Regarding VLAN names and IDs, there should be no issues as they were configured exactly the same as those on the distribution layer (VTP Server). As for Spanning Tree, the intention is to keep the current configuration without making any changes to it.

I also ran tests in Packet Tracer simulating the situation, and I did not observe any traffic interruptions. Of course, these tests were conducted on a smaller scale compared to the real scenario.

[Joseph W. Doherty · Accepted solution]

"I also ran tests in Packet Tracer simulating the situation, and I did not observe any traffic interruptions. Of course, these tests were conducted on a smaller scale compared to the real scenario."

Don't trust PT results, as PT is often not faithful to actual device operation.

Much more faithful is something like CML, but the only really, really faithful operation is same equipment, running same IOS, in lab.

"As for Spanning Tree, the intention is to keep the current configuration without making any changes to it."

Most likely, doing so, won't cause you any issues, but being curious, two questions.

First, why the mixed STP variant usage initial setup?  Did the newer switch come with rapid-pvst as its default?

Second, why keep the mixed STP variant usage?  I can understand reluctance to make "needless" configuration changes, but rapid-pvst is much, much better than the pvst.  It's generally a worthwhile upgrade, even if you're not running STP for other than to avoid accidental L2 loop creation issues.

Again, to move to your production VTP domain, all you should need to do is reset password than reset domain name, i.e. don't believe you need to transition via transparent mode, but doing so adds trivial time, so you can do that too.

[nucciocrd]

Yes, the new switches use rapid-pvst as their default, while on the distribution side, only pvst is in use. This is likely because the distribution equipment and network, being older than the newly introduced switches, have remained on pvst, reflecting the standards at the time of their deployment.

Regarding your suggestion, moving to rapid-pvst is indeed a good idea, as it offers faster convergence and better efficiency compared to pvst, especially in modern networks. However, the decision to maintain the current configuration likely stems from the desire to avoid unnecessary changes in a live environment, especially given the age of the existing infrastructure.

[MHM Cisco World]

rapid-PVST is interoperate with PVST
the issue with change from client-transparent-client are from

A- rev number 

B- transit SW

C-missing VLAN 

MHM