I have used the VSS since 2008, but have always built them from scratch, so please don't take my advice as gospel.
1. You'll need a few hours downtime. I would advise bouncing both boxes at the same time, but the primary just before the secondary so it comes up first.
2. The config will become 1/1 on switch 1 to 1/1/1 etc. If you have port-channels with the same config then these would cause issue.
3. For the reason above I'm not sure if you'd need to create all the vlans on switch 1 onto switch 2 and visa-vera, i'd guess that these would be merged, but.. I'd do this before as it's not too hard.
We ran SXH without any issues and SXI as soon as it was relased to supprt FWSMs - there were a few issues with these and the VSS. We're currently running SXI5 (after going through each version incrementally) on most VSS pairs (have 8 in total). I've seen two bad issues, once one chassis bounced due to the sup crashing, this then didn't come back up cleanly, it was as if SSO didn't work correctly.
Ironically we had what looks like a split brain this week on one VSS, once again this looks like one unit failed and caused issues with the VSL. Which isn't too bad for 8 units running over 3.5 years!
I've currently got a TAC case open as I'm seeing some odd behaviour with FWSM running A/A with a module in each chassis and traffic becoming out of order.
I'd personally run SXJ1 - I've had a bug scub for this and it looks good - also we have hit a lot of odd bugs in SXI5. I'd also look at the best practice white paper - follow it to the letter, we had a few issues as we implemented the VSS before this doc was released but these were rectified once we configured to the best practice.
1: What kind of "down time" am I looking at for the migration? (Reboots, configuration reloads, etc.)
You need at least 2 hours down time as a precaution, you need to make sure the configurations are ready on templates so that you can quickly push it and minimizes your down time, you also need to verfiy your Eitherchannel and VSL links. once the configuration are ready, both chasis detects a VSS and the master/primary switch take the active role.
2: I will be saving the configurations on both devices before-hand, but how does the VSS migration "merge" the configurations of both devices?
all what you need is the VSS configuration on both chasis for the VSS to be detected, all the rest of the configuration can be done on the primary switch ( The Active Supervisor Engine) and it will be replicated to the Standby Supervisor engine.
3: L2 VLANS - we have some on one switch, others on the second switch. Will these be combined, or would this be a manual process?
As I mentioned, the Active Supervisor Engine (Primary Chasis) replicate all Configuration to the Secondary/Standy by Supervisor, So you need to make sure all your vlan configuration are configured on the Primary Switch, and later the Active SUP Synch its config with the Standby SUP.
Any other things of note that I should know about before planning this migration?
I would create and make a backup for all of the Configuration, some thing like (configuration on chasis before VSS) and (Configuration on chasis after VSS), in order to make sure I have a rollback Scenarion if any issue arise or some thing goes wrong, so that you can immediately get back to your old Setup.
This is actually a pretty cool feature, i didn't even know it existed until I was looking for a solution to advertise a subnet (prefix in BGP talk), only if a certain condition existed. This is exactly what conditional advertisements does
j ai une question j ai achete un routeur cisco 887VA-k9 , je le configuré avec la configuration ci- dessous
si je le lier avec mon pc portable sur l un de ses ports directement ça marche toute est bien ( la connexion internet + m...
Attached policy provides CLI access to the Cisco 4G router over text messaging. Two files are in the attached .tar file:
2. PDF with instructions on how to load and use the .tcl file.