jon,

Is this disruptive to promote the switch this way?

Am I looking at configuration revision for up to date information?

At the moment, all switches are showing "client" and the same revision number.

By the way, this core switch is one of the reasons I asked all the questions about flash disks.

We lost power to this switch on Tuesday and it would not boot to the bootflash image.

It turned out it would not boot to any image from any source.

I was able to use all of the information you guys gave me to my advantage, but it ended up being the sup and backplane had to be replaced.

But I had a much greater understanding that allowed me to use the flash disks, by copying the image from the other core switch and trying to boot from it in rommon.

It's not disruptive. If all the revs and hashes look the same on everything you're fine. Provided its vtp domain name is the same and rev # is lower than your other clients, make the replaced switch a client and it will grab its vlan config from another client. Then bump it to server mode and you're done. If, for whatever reason, the name is the same and the rev is *higher* change the name to something else then change it back and the rev will go to 0.

To be super paranoid safe, you can put one of the switches into VTP transparent mode, and then copy the VLAN config out of the running config. That way if something goes south you can paste that into a VTP server and get everything back to normal in short order. Put it back into client mode. None of the stuff said thusfar should break anything. Like I said super paranoid safe :-)

Troubleshooting VLAN Trunk Protocol (VTP)

http://www.cisco.com/en/US/tech/tk389/tk689/technologies_tech_note09186a0080890613.shtml

Richard,

Sorry to hear that you had to go through all the mess. Sounds like you had a hardware issue with the switch.

You have some valuable input from both the previous posts. With VTP revision # is the key. A client with a higher revision # can overwrite VTP server's database and that's exactly what appears to have happened in your case. Follow the directions from the previous post and do whatever it takes to bump up the revision # of the core switch and you should be ok.

I would just add make another switch a VTP server (backup) as Jon said earlier to avoid repeat of the same problem in the future.

HTH

Sundar

Thanks Sundar,

So I can make both core switches "server" if everything has the same rev number with no danger?

These switches are a HSRP failover pair and the core switches for the network, there are two other 3560s trunked to the one that failed.

One of the 3560s has been offline since the 6509 failure, but no VLANs have been created, only members added.

That's fine. You *can* change them all to server if you want. All the server designation does is allow you to make changes to the VTP database through the cli.

Richard

Yes you can make both switches VTP servers if they have the same revision number. You just need to ensure that if one VTP server has a higher revision mumber than the other then this should be the one with the vlan database you want to propogate.

A useful thing to know is if you want to set the revision number back to 0 then you can change the VTP mode to transparent then back to VTP server/client depending on which one you want.

Jon

Thanks all,

For example in my situation, the server had died and was being replaced, what precautions do I implement on the switch once it has been booted (but not attached to the network)?

Just make sure it is a client?

If the database is only progated from the server, does the new client just stay at the revision it is when put in the network?

And how do you copy the vlan database from the switch?

1. Configure the new core switch as VTP Server enter VTP domain name, password etc..

2. Do not connect the new switch to the network yet.

3. Configure all the VLANs from the vlan database.

4. Make sure the VTP revision # of this switch is higher than that of every switch in your network running either client or server mode.

5. VTP revision # can be increased by adding/deleting VLANs in the switch from the vlan database.

6. Once you have verified the revision # of the new switch is higher than any other switch then connect it to the network.

7. If you want to add a second VTP server then make a client switch a Server and it would inherit the VLAN information from the already existing VTP server switch.

HTH

Sundar

Thanks sundar,

If I have an archived config from the night before,

Why not copy that rather than step #3?

You can do that Richard. Just make sure the revision # is higher any other switch in production. You can add and delete bogus vlans to increase the revison #.

VTP is great for ease of management. However, if you aren't careful while adding switches to the network it could cause unpleasent experience. If possible, schedule this change during off hours or scheduled downtime.

HTH

Sundar

Hehe, this has gotten much more complicated than it needs to be. OK, on your new switch, set VTP domain to yours and change mode to server. Connect to network. You're done, seriously. The other VTP clients will overwrite the server's lower rev # DB.

If you're that unsure about what's going on here, maybe you should take a bit to read up on VTP so that what we're telling you makes sense.

Thanks for the reply,

but if the potential is to take down the entire network by adding a new switch,

Complicated or not, I am asking as many questions as it takes.

Richard,

I understand your concern. Something like this even I would take every precaution before I do anything as it has the potential of taking the entire network down.

The new switch you are trying to connect to the network if it's going to a VTP server then all you have to do is configure all the VLANs currently in use, it doesn't matter whether you are manually entering them or dumping an archived configuration, and make sure the VTP configuration revision # of this switch is higher than that of any switch that's currently in production.

Instead, if you have an another VTP server switch in production and if you want the new switch to inherit the VLAN information from that switch then set the configuration revision to 0, configure it as a server, connect it to the network and it will learn all the VLAN information from the existing server switch and it would act as a second VTP Server switch.

HTH

Sundar