03-04-2011 08:25 AM - edited 03-06-2019 03:53 PM
I've got a 5 switch stack of 3750G switches I plan to replace with a 4 switch stack of 3750X switches. I use vtp to populate vlans on at least 10 other switches around our network.
What would the impact on these switches be if I shutdown my existing 3750G stack and bring up a 3750X stack with the same vtp settings and ip address?
Is this type of cutover a good idea or should I add the 3750X switches to my 3750G stack, configure them, move the connected devices and remove the 3750G switches?
The 3750G is running IPServices but it's not at a compatible IOS with the 3750x so an upgrade would be required. The 3750x switches are IPBase.
Solved! Go to Solution.
03-04-2011 10:57 AM
Build you new 3750X switches off line, stack them, upgrade them to IP services (if you need to) and cut them over from the old once during an outage window. Since they are all 3750s, you can download the config to a TFTP server and load it back to the new 3750X switches. Just watch out for port numbering and any error messages you may see during the upload.
This is just my opinion. I am sure, there are other ways to do this.
03-04-2011 01:40 PM
Make a stack offline (as Reza suggested) which is ready to replace existing stack and is VTP server. Keep all the vlan interfaces down on new stack, just create a trunk b/w existing stack and new stack. make sure VTP info along with configuratin revision number is updated on the new stack, disconnect the trunk link b/w the two stacks. do no shut on all the VLan interfaces and connect the cables accordingly.
03-04-2011 10:57 AM
Build you new 3750X switches off line, stack them, upgrade them to IP services (if you need to) and cut them over from the old once during an outage window. Since they are all 3750s, you can download the config to a TFTP server and load it back to the new 3750X switches. Just watch out for port numbering and any error messages you may see during the upload.
This is just my opinion. I am sure, there are other ways to do this.
03-04-2011 12:00 PM
I think, it depends how this particular stack is fitted in to your infrastructure.
is this your VTP server?
Is it serving Vlan interfaces which are being used as gateways at the client machines?
How other switches are connected to this stack (dual link, uplink fast etc)?
03-04-2011 01:14 PM
The stack is our core network switch where everything connects and it is our vtp server.
Spanning-tree is disabled, no dual link and no uplinkfast.
The only service the core provides to other cisco switches is vtp. We use 802.1Q to trunk between the core and outlying switches.
I'm not using vtp pruning. We're not using dynamic trunking.
The stack is also handling all our vlan routing with each vlan interface set with an ip address.
We are using static routes to send traffic out our firewall.
03-04-2011 01:40 PM
Make a stack offline (as Reza suggested) which is ready to replace existing stack and is VTP server. Keep all the vlan interfaces down on new stack, just create a trunk b/w existing stack and new stack. make sure VTP info along with configuratin revision number is updated on the new stack, disconnect the trunk link b/w the two stacks. do no shut on all the VLan interfaces and connect the cables accordingly.
03-04-2011 01:42 PM
Make sure the your VTP configuration revision number is smaller than the existing revision# in your old stack.
03-07-2011 09:23 AM
I'll give this a try this week and let you know how it goes.
03-10-2011 07:59 AM
Thanks for the help. I have my new core set up and I connected it as Reiza suggested through a trunk interface. The new core downloaded the vlan config as expected. I then disconnected the core from the network and set the IP and configuration. I could not reuse my config from the old core becuase I'm rearranging my connected devices to take advantage of the stackwise plus technology now available on the new core.
I changed the vtp domain name to a random value to clear the "configuration revision:" field to 0 so I'm ready to go for this weekend. Thanks again!
03-10-2011 11:41 AM
Make sure that you have not reset the revision number on the new Core switch. You must go with the same or higher revi
sion number after you synced with the existing VTP domain.
Earlier, I meant to have the lower revision number on the new Core switch so that it could sync with the existing VTP domain. Once new core is synced then you don't need to change its revision number else you may bring your network down.
03-10-2011 03:51 PM
ok so that's going to be a problem then. I reset the new core so it's revision is 0 and my current core revision is 2548. So to fix this would I reset my current core revision to 0 also? Or is there some way to edit the revision value manually on the new core to be higher?
03-10-2011 03:56 PM
On the new core, shutdown all the vlan interfaces so that no client can use it as gateway. then configure the same vtp
domain and password , keep it vtp server. make a trunk link again so that new core can sync with the existing vtp. once synced then do not change vtp info. remove trunk, and disconnect new core. Then offline do "no shut" on the vlan interfaces and then follow your further procedure.
03-10-2011 04:20 PM
So reseting my current core vtp configuration won't fix this problem? My new core has the same ip configuration so it's going to be some work to reconnect it to my existing core.
Could I back up my new core config, reset it to factory, connect it again to the current core to set the vtp info and then restore my old config?
03-10-2011 04:25 PM
You can shut those IP interfaces and then connect new core through a trunk. or you may repeat the same process if you like.
03-11-2011 02:03 PM
So I backed up the configuration using a TFTP server and also using Cisco Network Assistant. I reset to factory on the new core and trunked it back to the old core to download the vlans again using vtp. This worked as before and the vtp revision changed to match my old core. I then disconnected the cores and restored the config using CNA and the vtp revision changed back to 2.
I reset the core again and performed the same procedure except when I restored the config I did it from the TFTP server, not CNA. This time the vtp revision was maintained.
03-10-2011 04:39 PM
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide