3750-X Rolling Stack Upgrade?

[hensleeds]

Hello All,

Is it possible to perform a rolling stack upgrade on 3750X switch stack when the uplinks are configured in an LACP Cross-Stack Etherchannel?

The documentation seems to be a bit vague on that topic for IOS 12.2.58. http://www.cisco.com/en/US/customer/docs/switches/lan/catalyst3750x_3560x/software/release/12.2_58_se/configuration/guide/swstack.html#wp1295104

It mentions configuring one uplink as active and the other as stand-by. Which leads me to believe the uplink redundancy in the documentation implies STP is utilized to block one link. My setup consists of a two member 3750X switch stack connecting via Cross-Stack Etherchannel to a Catalyst 6500 VSS pair. Servers attached to the switch will be dual homes VMware ESXi hosts.

I know this is an extremely new feature, but any support from the community would be awesome!

Best regards,

DH

[Reza Sharifi]

Hi DH,

As far as I can remember, we only one other post asking about this very new feature.  And as you noted the info in the config guide is not clear enough to try this in a VSS environment. It would logically make scene to be able to perform it in a VSS setup, as this is designed to minimize downtime for hosts connected via an Etherchannel to 2 different 3750s, but again it is not mentioned anywhere in the guide. 

Cisco Rolling Stack Upgrade (RSU) on Cisco  Catalyst 3750-E and 3750-X: With previous releases, whenever Cisco IOS  Software was upgraded on a stack of switches, a complete stack reload  was required, which resulted in hosts losing network connectivity for  several minutes. Starting from this release, in networks that use  redundant uplinks and downlinks to the hosts, the intrinsic redundancy  of the network can be used to perform a stack upgrade one member at a  time with minimal traffic disruption. In this case, hosts with  connectivity (either wireless or wired) to two different switches in the  same stack would experience minimal traffic loss when switching from  one uplink path to the redundant one while the rolling upgrade is being  performed.

http://www.cisco.com/en/US/prod/collateral/switches/ps5718/ps10745/product_bulletin_c25-658743_ps7078_Products_Bulletin.html

HTH

[hensleeds]

Thank you Reza for your response. Logically I think it will work too. I hope to be able to test this scenario in coming months. I will try and post an update after my testing.

[wavargas]

Greetings,

According to my research the rolling stack upgrade will not work on this setup because of the following software bug:

ID:CSCts07947

RSU reloads whole 2 switch stack during upgrade

Symptom: When performing Rolling Stack Upgrade (RSU) on a  stack of 2 switches, once Switch1 with RSU Active Interface is  reloaded, Switch2 with RSU Standby Interface will reload whole stack due  to:"%ERROR: Rolling Stack Upgrade: Active port is down so reloading all switches in the stack"Conditions: Stack of 2 switches.Workaround: None.

The fixed release is still pending.

Best regards,

Warner Vargas

Cisco TAC engineer

[Dusan Kaufmann]

Hello,

this issue is fixed in 15.0(1)SE1, RSU is working now also for 2 switches in stack.

Firstly, I upgraded 3750X stack to 15.0(1)SE1 in standard way (whole stack reload) and then I tested downgrade to 15.0(1)SE using RSU.

archive download-sw /rolling-stack-upgrade /force-reload tftp://x.x.x.x/c3750e-universalk9-tar.150-1.SE.tar

--status during the 2nd switch upgrade:

ACC#sh switch stack-upgrade status

Upgrade Time Remaining: 7 minutes

Unupgraded Stack:

Switch#                 Status

   1                   RSU in Progress

   2                   Reload In Progress

--status during the 1st switch upgrade:

ACC#sh switch stack-upgrade status

Upgrade Time Remaining: 7 minutes

Unupgraded Stack:

Switch#                 Status

   1                   Reload In Progress

Upgraded Stack:

Switch#                 Status

   2                   Upgrade Completed

Switches are sequentially upgraded without whole stack outage (few seconds of outage were seen during the "switchover")

Both portchannels (dowlink to server, resp uplink to aggregation) are configured as L2 portchannels. Now,  I am going to test L3 portchannel to server with routing configured on access stack (but I am afraid, that L3 design is not supported with RSU).

best regards,

Dusan

[Jeffrey Ness]

Did you get a chance to test this on a Layer 3 routed link of an access switch and how did it work out?

[Dusan Kaufmann]

yes, I tested also L3 design and I found following issue already opened on Cisco TAC:

CSCtx05704 - Incomplete ARP entries after RSU

But finally, after this issue will be fixed I believe that RSU can work also with L3.

[techonethree]

I decided to document the steps as I couldn't find the exact process on the interwebs.  It's posted on my blog @

http://tech13.com/blog/2013/3/13/main1

Hope this helps.

Tech13

[Kevin Dorrell]

I have to do one of these tomorrow. The 2-member stack has layer-3 SVIs, and most of its connections are LACP-defined cross-stack etherchannels.  I shall be upgrading from 15.0(2)SE3 to 15.0(2)SE4 because SE3 has some nasty bugs and has been withdrawn.

So, if my active RSU interface is effectively a cross-stack etherchannel, how do I do this?  Do I declare the Po interface as the RSU active and have nothing as the RSU standby, or do I declare one of the member links as RSU active and the other as RSU standby?

It seems strange to me that you declare interfaces as RSU active and RSU standby, when what you are really trying to establish is which stack member is RSU active, and therefore should be upgraded last.

Anyone got any useful tips on this?  I am already aware of document 64898 (the upgrade instructions using CLI) and the excellent work done by tech13.

Kevin Dorrell

Luxembourg

[Kevin Dorrell]

Bump ... anyone?