Switchover/failover command.

[klambert1218]

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?

[spremkumar]

Hi

What kinda switch models you are referring over here?

regds

[klambert1218]

6500 series

[Reza Sharifi]

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

redundancy force-switchover

HTH

Reza

[klambert1218]

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]

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]

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]

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]

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]

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]

So, where are the SVIs for your VLANs?

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

[Jon Marshall · Accepted solution]

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]

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?

[Jon Marshall]

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

[Reza Sharifi]

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