Activating VTP in an existing network

[IanMurphy]

I've inheirited a network of some 50 older cisco switches which are being upgraded to 9300/9200 units. VTP was never configured on this network. When I replaced the old core switch with a new 9300 stack vtp showed as being in server mode. I don't remember if I configured a vtp password but I don't have it recorded if I did.

The core switch change had no effect on the vlans which were configured in the older switches (mostly old 3560s)

I've just started swapping some of the old access switches for 9200s and I found that they come up and detect the vlans from the 9300... i.e vtp seems to have autoconfigured.

I've only ever configured vtp on a new network, built from scratch where I could configure everything cleanly. On this network I'd like to lock down the vtp config before I continue. However I'm nervious about cutting off the 9200s which I've already connected. 

I don't fancy just enabling a vtp password and then running around the building to reconfigure the other switches while the users get mad at me. I'm guessing theres a better way to do this. I've read that you can put vtp in a transparent mode but I'm not sure if this is going to help.

I have read some guides to vtp on the cisco site but they aren't very clear on what effect changing the config will have on an existing network.

Could someone point me in the direction of a good guide on how to do this or let me know roughly what the procedure is to enable vtp, activate a domain and password and then enforce it on a working network, all without having the world crash down around me?

[MHM Cisco World]

I will check something in my mind and update you.

[DanielP211]

Hello!

I would recommend turning of VTP (setting to mode transparent), and having vlans on switches staticaly. VTP can cause you a lot of issues (trust me). But if you insist the best way is to setup a new VTP server, set a new VTP domain with a password (check if you have password on the existing with show vtp password) and build everthing around the new server - migrate the existing switches to the new domain (first set them to transparent then change the domain/password and set the mode to client). 

BR

[paul driver]

Hello
Suggest you migrate to vtp version 3, all the new switches should support it and its backward compatiable with ver1/2, also suggest NOT to append prunning, I have found it to be undeterministic in what vtp actually prunes, If you need to prune the trunks then doing it manually is a much better way.

Server

• Choose switch to become vtp 3 primary server
  Change vtp ver to 3 ( this WILL NOT change or erase the current vtp DB)
  Promote switch to vtp primary and hide the password

conf t
vtp ver 3
vtp mode server
vtp password xxxx hidden
exit
vtp primary  force

Client

• Choose the switchs to become vtp 3 clients
  Change vtp ver to 3 (Making sure the password /domain are the same ,this WILL NOT change or erase the current vtp DB) the switches should then synchronize its own vtp DB to that of the new vtp3 primary server vtp D/B )
  
  

conf t
vtp ver 3
vtp mode client
vtp password xxxx hidden
exit

[Joseph W. Doherty]

"i.e vtp seems to have autoconfigured"

That's a bit concerning, as it implies you might be running a VTP configuration that easily could be corrupted by adding a switch.

BTW, because of the risk of rather easily taking down a whole VTP (vers. 1/2) domain, many suggest not using VTP at all.  Personally, I like using VTP, but I also understand the inherent risks which can be much mitigated by (more or less) bullet proofing your VTP (vers. 1/2) setup (like using an explicit domain name and password) and using good change management procedures.

(BTW, I've never used VTP v.3, but it's supposed to be, inherently, much more difficult to accidentally corrupt your network.)

Anyway, if you elect to continue to use VTP, first you need to decide whether to use version 1/2 or version 3 (the latter not supported on very old switches).

For a version 1/2 conversion, first I would change all switches to VTP mode "off", if supported, or "transparent" if not.

Then, staring with your VTP "server" configure an explicit VTP domain and password.  (Doing both, avoids some "accidents" adding switches with the default null settings.)

Then, working out from your "server", configure other switches to be VTP "client" mode.

The above, is basically the same conversion approach recommended by @DanielP211.

@paul driver recommends not using VTP pruning.  It works, but it has some "quirks" in how it works, that can cause issues.  So, I agree with Paul, if you want to prune, you're probably better off doing it manually.

Also, like Paul, I would suggest you consider using VTP v3, if supported.

[IanMurphy]

This particular network is manually configured. Each switch has the vlans locally created and I enable or disable vlans on each trunk which limits the use of most vlans to just the main core switch.

It might be easier to just disable vtp on the access switches. At least this way I can be sure nothing untoward is going to happen. The protocol in itself makes me nervious as a single bug could be used to take down all vlans... like the bug in cdp a while back.

[Jon Marshall]

Haven't used VTP in years and don't intend to any time soon  

If your environment is relatively static and you are not continually modifying vlans I would just stick with transparent, lot less to go wrong. 

Jon

[Joseph W. Doherty]

Well, disabling VTP, for fear of a VTP bug, bringing down a network is a valid consideration, although "accidentally" misusing it, I think, is much more likely.  Both, though, should be precluded by turning it off.

@Jon Marshall mentions, unless you're continuing modifying VLANs, you might not bother with it.  I understand this viewpoint, but I see value in VTP for usage across multiple switches even without on-going VLAN changes.  Why?

Well, understand for decades I worked as a programmer/analyst.  One recommendation I found useful, was to have "information" as close as possible to the actual code, or embedded with the code.  For example, variable names and/or procedure/function names as meaningful as possible, and/or code comments.  This applies to VTP how?

Consider VTP a shared depository of all known VLAN IDs with (hopefully meaningful) VLAN names seen on every switch in the VTP domain.

VTP does have other features, which you may never use.

Further, as L3 switches have become so prevalent, and they break up VTP domains, this negates much of the common VLAN information repository aspect of VTP.

So do I recommend using VTP?  I do not.  However, do I recommend not using VTP.  Again, I do not.

I recommend you consider all the pros and cons of using VTP, and decide what's best for you.

[r.heitmann]

I'd recommend for most cases "turn off VTP", too.

Instead learn Ansible and start to normalize the management-plane of your 50 devices - add identical SNMP, SSH, NTP, including ACLs, you name it ... Syslog, AAA, ... to all devices.

And try to keep VLANs as local, with minimal diameter, to keep failure domains (= broadcast domains) as small as possible.

Connect those domains using Routing.

A well designed network doesn't need VTP!

//Exceptions prove the rule

[MHM Cisco World]

As @Jon Marshall @r.heitmann mentioned no running VTP is better 
but for you I run lab
config domain/ver/passowrd/mode in Server
config domain/ver/mode in client 
there is no change in VLAN 
until I add password in client  then the vlan change (meaning the VTP start working )

[Joseph W. Doherty]

"there is no change in VLAN 
until I add password in client  then the vlan change (meaning the VTP start working )"

Hopefully, all understand, by "meaning the VTP start working", means the switch started participating in the VTP domain, as noted, VLAN information is updated.  I.e. this confirms expected behavior, VTP domain and passwords need to match across devices within the same VTP domain.  (One "gotcha" with VTP domain names [vers. 1/2], a switch with a null VTP domain name, I recall, will accept a neighbor's VTP domain name and use/copy it.)

As an aside, often misunderstood in VTP vers. 1 or 2, the only real difference between a "server" and a "client", the former allows you to manually revise the VLANs, the latter does not.  Both, though, updates VTP the same way (which can lead to one of "usual" ways VTP can "accidentally" corrupt VLAN configurations - make concurrent VLAN revisions on more than one VTP "server" or add a VTP device, with a higher revision number, to VTP domain).

[IanMurphy]

I think I'm going to just disable it. Everything works fine as it is. I can still disable it on the couple of new switches I've connected by going physically to the units, so no risk of losing connection.

anyway, thanks for the recommendations.

Ian

[MHM Cisco World]

It better.