Switchover/failover command.

Answered Question
Feb 11th, 2010

What is the switchover/failover command I would use if I need to switch/fail over to another chasis? And what are the requirements in order to do such?

Both switches are configured as L2 devices, if that helps. Is it possible in this scenario?

I have this problem too.
0 votes
Correct Answer by Jon Marshall about 6 years 9 months ago

klambert1218 wrote:

Jon,

There is an HP Blade that is connected to both (or will be) and there is an uplink connected to the only running switch at this time. All switching is VLAN determined.

Okay you should definitely do this out of hours. You would need to connect a new uplink to the new switch and obviously interconnect the 6500 pair of switches.

If you then wanted to take the old switch out of the equation while upgrading it simply shutdown the uplink and HP blade port. Traffic will then go via the new 6500 and when you have finished upgrading the old switch active the uplink and HP blade ports again.

All of this will cause outages ie.

1) adding the new switch could cause an outage because STP will need to reconverge

2) If you manipulate the STP costs so that after you have added the new switch all traffic is going via the new switch then you can work on the old switch with no downtime but obviously when you bring it back online STP kicks in again.

I'm not talking about huge outages, 50 seconds + with standard STP, a lot faster if using Rapid STP but you will drop packets so that's why it's better to schedule downtime.

Jon

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (1 ratings)
Loading.
Reza Sharifi Thu, 02/11/2010 - 10:32

Is this in VSS environment or 2 Sups in the same switch?

redundancy force-switchover

HTH

Reza

klambert1218 Thu, 02/11/2010 - 10:40

Actually neither. What I'm trying to accomplish here is standing up the second of two 6506-Es that will need IOS upgrades. One switch is already running in production, so my plan was to power on, configure, upgrade the secondary switch and then switch/fail over the primary switch to the secondary one so that there is little to no downtime. As previously stated, these are configured as L2 devices, so they are definitely being under-utilized. These need to be in an HA pair with a heartbeat in between, too.

Reza Sharifi Thu, 02/11/2010 - 10:51

klambert1218 wrote:

Actually neither. What I'm trying to accomplish here is standing up the second of two 6506-Es that will need IOS upgrades. One switch is already running in production, so my plan was to power on, configure, upgrade the secondary switch and then switch/fail over the primary switch to the secondary one so that there is little to no downtime. As previously stated, these are configured as L2 devices, so they are definitely being under-utilized. These need to be in an HA pair with a heartbeat in between, too.

Ok, then you need to look at VSS.  It will provide what you need.  You basikly take 2 physical switches and turn them into 1 logical switch.

The switches have 2 be 6500-E with the exact same software and hardware.  You would need Sup-720-VS with 2 10Gig uplinks.

Take a look at this paper for more info:

http://www.cisco.com/en/US/docs/solutions/Enterprise/Data_Center/DC_3_0/DC-3_0_IPInfra.html#wp1044715

http://www.cisco.com/en/US/docs/solutions/Enterprise/Campus/HA_campus_DG/hacampusdg.html#wp1108021

HTH

Reza

klambert1218 Thu, 02/11/2010 - 11:01

That's where the problem lay. The switches were purchased prior to my being here, so I had no say in the module types. We have SUP-720's in each switch, but they're not 10 GE, and I don't want to failover from one supervisor to another, I want to fail the entire switch over to another switch, so that I can perform the IOS upgrades. This is a production system that is currently running with one switch, and I want to stand up the other switch for redundancy and HA. My thinking is that I should get the second switch up and running and the IOS upgraded, and then move the production traffic over to the new switch, so that I can upgrade the IOS on the old switch.

Reza Sharifi Thu, 02/11/2010 - 11:22

You could do that.  If the users default gateway is on this box you can add a second one and run VRRP or HSRP and give the new switch a higher priority so it is the primary switch and then upgrade to old box and bring it back up and continue running VRRP or HSRP in your environment.

Reza

Jon Marshall Thu, 02/11/2010 - 12:00

klambert1218 wrote:

That's where the problem lay. The switches were purchased prior to my being here, so I had no say in the module types. We have SUP-720's in each switch, but they're not 10 GE, and I don't want to failover from one supervisor to another, I want to fail the entire switch over to another switch, so that I can perform the IOS upgrades. This is a production system that is currently running with one switch, and I want to stand up the other switch for redundancy and HA. My thinking is that I should get the second switch up and running and the IOS upgraded, and then move the production traffic over to the new switch, so that I can upgrade the IOS on the old switch.

The issue here is that both switches are simply acting as L2 devices. So the best you could do to influence which one is used for traffic is to manipulate the STP costs so that one switch is seen as more favourable than the other. You can't use VSS as you have said so it's important to understand that 2 6500s in a pair don't really exist as active/standby with a hearbeat like a firewall pair for example. They are in effect active/active and both are capable of forwarding traffic.

Even if they were L3 and responsible for inter-vlan routing you could influence the HSRP active gateways but not all traffic uses HSRP ie. it is really only for end devices.

So you need to stop thinking of them as pair with one active and one standby with a heartbeat or it won't really make any sense.

If you want to use one then the other while you upgrade you must first ensure that all the connections your existing switch has are replicated on the new switch. Obviously this means any interconnects to other switches/routers etc. So by removing one of the 6500s you still have L2 paths to get from A to B in your network. Correct me if i am wrong but i think you said in another thread that there were no end devices connected into these switches ?

Also bear in mind when changing between switches at L2 there is downtime. Might not be long but it will be there because of STP. This really has to be done out of hours with a scheduled outage.

Jon

klambert1218 Thu, 02/11/2010 - 12:12

Jon,

There is an HP Blade that is connected to both (or will be) and there is an uplink connected to the only running switch at this time. All switching is VLAN determined.

Reza Sharifi Thu, 02/11/2010 - 12:21

So, where are the SVIs for your VLANs?

Can you provide a simple diagram of what you have and what you want to acheive?

Correct Answer
Jon Marshall Thu, 02/11/2010 - 12:38

klambert1218 wrote:

Jon,

There is an HP Blade that is connected to both (or will be) and there is an uplink connected to the only running switch at this time. All switching is VLAN determined.

Okay you should definitely do this out of hours. You would need to connect a new uplink to the new switch and obviously interconnect the 6500 pair of switches.

If you then wanted to take the old switch out of the equation while upgrading it simply shutdown the uplink and HP blade port. Traffic will then go via the new 6500 and when you have finished upgrading the old switch active the uplink and HP blade ports again.

All of this will cause outages ie.

1) adding the new switch could cause an outage because STP will need to reconverge

2) If you manipulate the STP costs so that after you have added the new switch all traffic is going via the new switch then you can work on the old switch with no downtime but obviously when you bring it back online STP kicks in again.

I'm not talking about huge outages, 50 seconds + with standard STP, a lot faster if using Rapid STP but you will drop packets so that's why it's better to schedule downtime.

Jon

klambert1218 Thu, 02/11/2010 - 13:11

We have already scheduled an outage, so we're definitely good there. We just didn't want to be down for hours if we could help it, hence, asking all of these questions as I think of them. I appreciate EVERYONE's time and effort in assisting my colleague and me in this endeavor.

Jon,

What you were describing is exactly what a colleague and I had just finished up discussing, so that must mean we're on the right track. As far as the interconnecting of the switches is concerned, I know that in a previous thread we had discussed Etherchannel, and that's what I'm planning on using, but I had a few additional questions with that. I can use gi5/1 and gi5/2 on both switches and connecting them with fiber, right? My question is, we don't have any Cisco SFP GBIC connectors on hand, but we have some HP ones. Will those work?

Reza Sharifi Thu, 02/11/2010 - 13:41

It is going to come down to testing it.  I have seen it work and you just see a cosmetic error on the screen saying "this is a none approved device"

I also have seen you get the error and the port is disabled.  If Cisco and HP buy their SFPs from the same 3rd party vender you should be fine

Reza

Jon Marshall Thu, 02/11/2010 - 13:28

klambert1218 wrote:

Jon,

I can use gi5/1 and gi5/2 on both switches and connecting them with fiber, right? My question is, we don't have any Cisco SFP GBIC connectors on hand, but we have some HP ones. Will those work?

Short answer is i don't know. To be honest with 6500 switches and the cost and complexity involved i tend to stay with Cisco kit even down to the SFPs.

Bear in mind that you can mix and match fibre and copper in etherchannel as long as they are the same speed/duplex etc. But it is a good idea to include at least one of the supervisor ports in the etherchannel interconnect.

Jon

Jon Marshall Thu, 02/11/2010 - 13:56

Reza is right, it comes down to testing.

All i would add is it depends on whether you can test before implementing and also how visible this change is to the business. At my last place of work getting an outage in our Data Centre took weeks of planning and we had to notify and get agreement from numerous depts. The last thing we could afford was to have to back out on the night because we had the wrong connectors. Never mind that we would have looked unprofessional we may not have kept our jobs for very long 

Jon

klambert1218 Tue, 02/23/2010 - 05:56

Follow-up to the new switch addition.

Overall, things went pretty well. The whole project took longer than we expected, but at least it is finished. The SFP GBIC connectors that I used would not work with the 6506-E, so I wasn't able to use those, so we had to settle with interconnecting the switches via copper GigabitEthernet ports. After transferring the IOS from the TFTP server to disk0, I copied disk0 to disk1 so that I could just insert the CF in disk1 into the primary switch's disk0, and change the boot command for the primary switch to boot from disk1. As good as that sounds, it didn't appear to have worked, because it kept indicating that disk1 had no files on it, even though during the copy, it never indicated any errors. At any rate, I had to settle for TFTPing the IOS to disk1 on the primary switch and proceed accordingly. One other thing that we encountered, and I hope that someone else has some input/insight into this, and that is after the IOS upgrade and subsequent reloading of the switch, whenever we would secure-shell to the switch, it would prompt us for a password three times and none of our passwords would work, and then it would finally give us the normal [email protected] password prompt and we would be able to get in without issue. Anyone else ever had this happen, and if so, how did you fix it?

Actions

This Discussion