VSS chassis move preparation, and several questions

NormMuelleman · ‎08-26-2013

Hello all once again;

Today's question is concerning VSS and chassis movement. I've been reading up on VSS, since our core switches are actively using VSS. We are using quad-core redundancy (2 sup engines in each chassis), with a 4-link MEC channel between the chassis. Our chassis are in separate buildings about 1/2 mile apart. This will be changing, and they will be mile or more apart. The first questions I have are redundancy questions; then I'll address movement.

1. So, both chassis are seen as one device. In actuality, I believe they each have their own IP address, and a third IP address for the total "core" switch. So if I SSH into the devices, I "should" get punted to the active device. How do I know WHICH device I'm actually in without going to the device and looking on the module for the "active" light on the module?

2. Once I determine which device I"m in, that should be the "active" chassis. If I read the documents correctly, all commands have to be made from the console of the active device. Is this correct? The reasoning is this: Let's say I have SWITCH 1 here in my local building, and SWITCH 2 in my building 1/2 mile away. So, I can just walk here to the switch, console in, and do what I need if need-be. I could SSH into it, and would be on SWITCH 1 in theory. Am I correct in this?

3. We lost power at our location; VSS redundancy kicked in, and SWITCH 2 became active. When SWITCH 1 came back online, it was left in standby mode. So again, if I SSH into the Core switch, I'm actually into SWITCH 2 as it has become active. Is that correct?

4. The issue I see is that, if we needed to do any changes physically, we'd have to go to the other building 1/2 mile away and console in. The documentation states that only the active chassis allows config changes via console. So, would it not behoove us to force a redundancy switchover to bring the active chassis back to our local building? But to do that, we'd have to physically go to SWITCH 2, console in, and issue the command, correct? I mean, we could SSH into it, but would that work? Would I not then get kicked out during the switchover?

All of the above leads to the next section, regardiing an upcoming move. I want control to be locally here in our local building. Why? Because we are going to be shutting down SWITCH 2 in the future, and moving it to it's new location about 1-2 miles away. So, SWITCH 2 will be offline for a week or two. Upper management has accepted the risk for the extended downtime. So that leads to:

1. What prepwork is needed prior to shutting down SWITCH 2? We have daily back-ups. We also have 1 backup chassis configured as well. So, besides saving the config, what should be done?

2. Assuming SWITCH 1 (local switch) is made active; should we issue the command to make SWITCH 1 a standalone device? Then power down SWITCH 2 and unplug everything?

3. Once the move is complete, what is needed to reverse the process? Any pitfalls to be avoided?

Thanks for all your help!

Leo Laohoo · ‎08-26-2013

1. So, both chassis are seen as one device. In actuality, I believe they each have their own IP address, and a third IP address for the total "core" switch. So if I SSH into the devices, I "should" get punted to the active device. How do I know WHICH device I'm actually in without going to the device and looking on the module for the "active" light on the module?

The command "sh redundancy" will tell you which one you are in. But I'm getting ahead of myself. When you configure VSS, you actually specify which chassis you want as "1" and "2". So if you issue the command "sh redundancy", you'll see under "Current Processor Information", which chassis is active and which one is standby.

Leo Laohoo · ‎08-26-2013

2. Once I determine which device I"m in, that should be the "active" chassis. If I read the documents correctly, all commands have to be made from the console of the active device. Is this correct? The reasoning is this: Let's say I have SWITCH 1 here in my local building, and SWITCH 2 in my building 1/2 mile away. So, I can just walk here to the switch, console in, and do what I need if need-be. I could SSH into it, and would be on SWITCH 1 in theory. Am I correct in this?

You'll know, from the command prompt, if you've consoled into the standby chassis. And if you do happen to miss that bit, then you'll start to realize that you're in the standby chassis because of the limited amount of commands available.

Leo Laohoo · ‎08-26-2013

3. We lost power at our location; VSS redundancy kicked in, and SWITCH 2 became active. When SWITCH 1 came back online, it was left in standby mode. So again, if I SSH into the Core switch, I'm actually into SWITCH 2 as it has become active. Is that correct?

That is correct. You may also stumble a Cisco documentation/Best Practice about "pre-empting" when the primary (not the HOT STANDBY) comes back. DON'T! Do NOT enable pre-empt.

NormMuelleman · ‎08-26-2013

We don't have pre-empt enabled. I did figure out when I plugged into the non-active sup engine on the active chassis..I got the "standby" prompt on the CLI. Leo, is there a particular reason WHY not to enable preemption? Something I can point to? I'm working with...well...I can't really say, but obviously it's a govt agency and there are people here that have a "little" knowledge..they'll read something then BAM.."we got to enable preemption". I've read elsewhere NOT to enable pre-emption, but is there something that I can say "this is WHY you don't do it?"

Any thoughts on the other parts of my questions? We are going to move SWITCH 2 in a couple months, and "they" think we can just unplug...move..power on and all will be well. I'm thinking we need to make SWITCH 1 a StandAlone device for the interim.

Leo Laohoo · ‎08-26-2013

Leo, is there a particular reason WHY not to enable preemption?

I'll give my take. Reza might chime in on this.

Ok, here goes ... Let's call your chassis 1 & 2, with 1 being the primary. Let's say 1 has a power outage and 2 goes active. So far so good, right?

Without pre-empt, when 1 comes back, nothing happens. 2 will not hand back control until something happens. That's either when someone forces the switchover or something happens to 2. When you or someone force the switchover, it's basically telling 2 to reboot.

With pre-empt enable. When 1 recovers from a power outage, 2 will reboot AUTOMATICALLY. This could be any time of the day and without any intervention or warning. Plus, let's say that 1 has a power issue or power supply problem. If this is the case, your network will be bouncing like a yo-yo.

VSS pre-empt is not like HSRP pre-empt. When VSS pre-empt is enable, you don't loose "a few pings". You loose a lot when 2 reboots and 1 takes over. Let's just say I'm an "mental" ... (ok, I really am, but that's not an issue), what if you have high-speed traffic going when pre-empts kick in. Let's say you've got SAN backup going and then pre-empts kick in.

NormMuelleman · ‎08-26-2013

Ok, that makes total sense. So, further on that. Let's go back to square one; 1 is primary, 2 is standby. 1 fails; 2 takes over as active. There should be no major loss of data, correct? Then, when you're ready, you can push active back to 1. So if you do that with a redundancy force-switchover, will it be controlled, or will there be an outage and reboot?

And what about making 1 a standalone for the time we move 2? That's the big thing I'm worried about.

Leo Laohoo · ‎08-26-2013

There should be no major loss of data, correct?

You'll loose a few pings, if I remembered correctly.

If 1 goes off and 2 takes over, any clients connected into 1 have no choice, you're dead. If you're in 2, then you'll loose a few pings.

If 2 takes over and you force the redundancy back to 1, when 2 reboots, anything connected to 2 goes down.

This is why, in the wild, you don't mess with pre-empt and only force the redundancy back if you have no choice.

And what about making 1 a standalone for the time we move 2? That's the big thing I'm worried about.

Sure, you loose all clients connected to 2.