Hi Ankur,

Thanks for the answer.

I have another question - The scenario is this.. there are two switches 5509 and 6509.

5509

RSM - IOS - all routing and vlan configured.

CATOS - VTP server mode configured.

6509 (currently not used to do L3 stuff)

MSFC - IOS-plan to move the routing and VLAN here and assign it the same IP as the 5509 RSM.

CATOS - VTP server mode.

When I move the config to the new 6509 and turn off the 5509, is there anyting I should be taking care off?

thanks

Salil

Hi Salil,

Before moving to Cat6k I will suggest to make sure config revision number is same on both the servers i.e 5k and 6k switch and vlan information is also synched that is same on both the switches.

Also if possible make sure other switches in network also have same revision number or lower revision number.

I am not sure if this is possible for you in live network to create one dummy vlan and make sure it is getting propogates into your network which will 100% assure you that cat6k as VTP server is taling to the VTP clients in your network i.e no VTP domain and password mismatch and later you can delete that vlan from your VTP server.

HTH

Ankur

*Pls rate all helpfull post

Hi,

I got the revision number synced and also tested creating a dummy VLAN. Next step I will have only two switches in server mode and all others in client mode.

I cant change to IOS as the switch is already in use.

Once I have migrated to the new 6509 (routing and vlans) do i need to clear arp entries on the 6509 catos and also on all the other devices that I hook up to the 6509.

Any other things that I need to be aware of.

thanks

Salil

First off, is the 6509 "live" yet? if not please consider going straight in and running IOS on it. It will be easier to do it before it goes live, and you will probably end up doing it sooner or later as Cisco have announced the end of CATOS.

Hi Paul,

The 6509 is already live. So wont be able to change from CATOSto IOS.

Will plan that during the next downtime as a separate activity.

regards

Salil

No problem. I would suggest if you can trying to get your hands on a similar switch to upgrade offline if you can.

The upgrade is not too difficult, but can take a while and is a little involved, You also have the job of converting your config. If you can get hold of a switch to upgrade first you can do the real one a little more quickly. I don't know your support agreements, but if you deal with a partner, they may have one in a lab you can book some time on, or there are companies that will rent you one.

I am not saying this is a difficult or particulalrly risk job, but you will be a lot more comfortable doing it on your live switch if you have done it previously.

Paul.

P.

Vtp clients switches don't lose there vlan information when the vtp server is unavailable.

Even not when powered down.

Vlan information is either stored in the vlan.dat in flash or in the global config.

(new methode)

It just isn't possible to add/remove vlans as long as there's no vtp server in the vtp domein.

I can confirm that. I did some experiments with VTP over the weekend, just to check my facts. (Some of which were only partially correct.)

Take a VTP client, isolate it from the rest of the network, and reboot it. It does not lose its VLANs.

Here's a good one. Take a VTP client, and isolate it from the network by shutting down its trunk port. Change it to VTP server and add or delete a few VLANs. Change it back into VTP client, then re-enable the trunks. What happens? The client updates the rest of the network. Tried it Saturday, and that's what it does.

But now here is the bit that surprised me, and makes me think my previous testing must have been on a different version. Do exactly the same experiment as above, BUT, just after you have changed it back into a VTP client, but before you re-enable the trunks, reload it. This time it does not update the domain, despite the fact that it has a higher revision level. But it does not lose its changes either. The domain does not update it until the revision level catches up. (Unless you promote the VTP client to VTP server of course.)

That is different from last time I tested it. It seems that the VTP client bomb I have been talking about recently can be prevented by rebooting the switch while it is still in client mode.

There are still lots of strange behaviours in VTP still to be found.

Kevin Dorrell

Luxembourg