|  BlueWolf's Howl   | Comics and Art  | Higher Level  | Photography  | Poetry and Stories  |
|  Chess  |  Letterboxing  |
|  2003 Blogathon Archive  |   2005 Blogathon Archive  | 8th Layer Archive  | Blue702 Archive  |

BlueWolf's Howl

« Pain in the Boson | Bluewolf's Howl | It's a Network Problem »

January 28, 2008

She's (not) stacked...

Catchy title, eh? But this has nothing to do with cleavage.

Ever have some 3750s that you want to stack? Great. There are quite a few pages online (and at Cisco) that you can read to know all about stacking your switches.

But what if you have some switches that are already stacked and you want to _un-stack_ them? Yeah. Can't find anything can you? I found a PDF on the Cisco site for Managing Stack Switches, but the only pertinent point in the chapter was that when you un-stack live switches, they both end up with the same configuration and could cause a duplicate IP address conflict. Other than that, I couldn't find anything.

I had a supervisor that once told me "if you can't find anything on it, then it must be so simple that there doesn't *need* to be anything on it." Although I've mostly found that to be true, it was no comfort when staring down a maintenance window for a task I had never performed before.

Luckily, the switches that I had to un-stack were relatively new and not really "in production"... There were only 5 connections on the 4 switches (two stacks to un-stack). Here's how I went about it:

1. Back up the configs (for any work you do, this is a good idea).

2. Power down the switch with the least amount of connections. This allowed me to work on one stack at a time and focus my efforts. Remove the stack cables in the back.

3. See what you have in the live stack. Make sure it knows it's the stack master. Make sure that it's at the default priority (1). Make sure that it is switch number 1. [You may have to change the switch number. The above link *will* tell you how to do that.] Save the config (wr mem). Reload the switch.

Note: These switches take a very long time to come back up. The switch comes up - and tests the hardware of the ports. Then it has to wait while the stack (now a stack of one) elects the stack master. This is in addition to the image decompressing (which always takes a while anyway). As they say in Hitchhiker's Guide: Don't Panic. This will undoubtedly take longer than you want it to - but it's working as designed.

4. Check the config after the switch comes up. Make sure that the changes you think you made actually occurred. (Again, a good idea regardless of task). Once that is done, you have one good switch. But you still have to remove the missing member. To do this, you need to use the "no" form of the provision command (for a provisioned switch). [Yeah, I had to figure that one out on the fly...]

5. Remove the connections from the switch that is currently powered down. Yes, you will have to use the console, but removing all the connections will put the second switch in a "lab" environment. Someone has to be there to physically remove the stack cables, so there has to be someone who can console into it.

6. Once you *know* there is no way that switch can talk to anything (with its duplicate IP address), power on the switch. Again, this will take quite some time to boot up. Make the IP changes that you need to make. Make the stack number and stack master changes. Remove the other switch. Save the config and reboot.

7. Check the second switch. Check it thoroughly to make sure your changes were made. Once you are confident in your new config, connect the cables.

8. Check everything again.

9. Pat yourself on the back (or wipe the sweat from your forehead).

For planning purposes, you'll want to allow for at least one hour per stack. Once you do this a few times (but, who gets to do this more than once or twice?), you may be able to shorten the time. But, from what I've seen so far - this is not something that you'll do on a regular basis. YMMV.

Posted by BlueWolf on January 28, 2008 09:30 PM