VSS IOS Upgrade - eFSU vs. FSU

[alf]

Hello Team,

I am planning an IOS Upgrade of a VSS cluster with 6506-E/VS720-10G.

I would like to upgrade from current 12.2(33)SXI2a to 12.2(33)SXJ6.

I am using just Standard LAN Enterprise Features.

At this time I would like to stay with IOS 12.2 although the Software Advisor actually recommends IOS 15,

because I see that the 12.2 IOS has Status MD and 15 is still ED. Thats the reason why I selected 12.2(33)SXJ6

as target (any comments welcome).

I think, I have at least two options to perform the Upgrade: eFSU/SSO and FSU/RPR.

I understood that eFSU has less impact on downtime as FSU, however according to the actual

EFSU Compatibility Matrix following the supported Upgrade Paths I would need a lot of interim steps

to reach the target: SXI2a-> SXI5a -> SXJ1 -> SXJ4 -> SXJ6

With FSU/RPR I will have some downtime, however this would be a direct Upgrade and I have a reasonable fallback path.

The maintenance window for the upgrade is planned during a weekend, so I might have some time...

Did I miss sth ? Whats your recommendation and why ?

Thx for any hint or comment.

Alfred

[Farooq Razzaque]

Dear Alfred

Have you performed the upgrade on your VSS cluster with 6506-E/VS720-10G. 

What modules you are using in the chassis ?

Did u notice any modules reset/reload during switchover in ISSU run version step.

Please share the experience. 

I also need to upgrade the VSS with 6513/VS720-10G.

[alf]

Hello,

thx for your comment.

I´ve performed the Upgrade successfully some weeks ago (to SXJ7). After some further discussion

with colleges and TAC I decided to go with FSU which means:

1. copy the new IOS to both Sups

2. setting the bootvariable to new IOS

3. reload the standby Chassis and force it to RPR mode (redundancy reload peer)

4. after completion with the standby chassis switchover from active to standby Chassis (redundancy

    force switchover). This brings downtime for ca. 4 minutes (depending on the number and type of

    linecards). After completion system is back in SSO mode, both systems are upgraded, but

    the initial primary Chassis is in standby mode.

5. Optionally you can switchback to primary Chassis as active (redundancy force switchover),

    but this gives you another downtime for 2-3 minutes.

At the end, I was successfully finished in less than one hour including all the checks, I did not

encounter any memory issue preventing modules from successfully rebooting.

I had 6506-E Chassis with 1 x VS-S720-10G, 1 x WS-X6748-GE-TX, 2 x WS-X6716-10GE in each Chassis.

regards

Alfred

[Farooq Razzaque]

Dear Alfred

Thanks for the prompt response. Really appreciated.

Can you please answer the following questions highlighted in Blue against point 3 & 4.

3. reload the standby Chassis and force it to RPR mode (redundancy reload peer).

While reloading standby chassis, only all the modules (Sup + linecards) on Standby chassis will get reloaded or all the modules (Sup + linecards) on active chassis will also get reloaded. ?

4. after completion with the standby chassis switchover from active to standby Chassis (redundancy    force switchover). This brings downtime for ca. 4 minutes (depending on the number and type of    linecards). After completion system is back in SSO mode, both systems are upgraded, but  the initial primary Chassis is in standby mode.

While switchover from active to standby chassis, only the active chassis will get reloaded ?

If in case only active chassis get reloaded during switchover then only all the modules (Sup + linecards) on Active chassis will get reloaded or all the modules (Sup + linecards) on standby chassis will also get reloaded.

[alf]

ad 3): reloading the standby-chassis (using redundancy reload peer command)

          reload Sup and line cards only on the standby chassis, not on the active chassis

ad 4): when performing the "redundancy force switchover" in RPR mode this has impact

          on both Chassis. It forces the active Chassis to reload including all line cards of this

          chassis and (because RPR mode) the standby Chassis needs to complete the

          startup procedure and taking control-plane ownership before beeing able to provide

          services to attached devices. Even if this does not mean another reload on the

          standby Chassis this is causing the downtime described under point 4.

Hope that helps

regards

Alfred

[Farooq Razzaque]

Dear Alfred.

I understand that during RPR mode redundant sup is not fully sync with Primary SUP and during switchover redundant sup will be fully sync first before become Primary SUP and there will downtime b/c of this.

I want to know that during switchover, will the all modules (linecards+service modules) on standby chassis will get reloaded or not. Did u noticed this thing while you were performing upgrade

[Farooq Razzaque]

Dear Alfred

I would appreciate if you could answer the following query.

I understand that during RPR mode redundant sup is not fully sync with Primary SUP and during switchover redundant sup will be fully sync first before become Primary SUP and there will downtime b/c of this.

I want to know that during switchover, will the all modules (linecards+service modules) on standby chassis will get reloaded or not. Did u noticed this thing while you were performing upgrade

[alf]

Hello,

as stated above, the switchover has impact and downtime for both chassis.

Remember, in this status we have no working supervisor, because the standby supervisor still needs to complete the startup and to start the control plane processes and the active supervisor is reloading. I don´t have service modules installed so I cannot comment on those.

You may also take a look into this document describing the FSU Upgrade:

http://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst6500/ios/12-2SX/configuration/guide/book/vss.html#wp1170391

See step 9:

redundancy force-switchover

Forces the VSS standby chassis to assume the role of the VSS active chassis running the new Cisco IOS image. The modules are reloaded and the module software is downloaded from the new VSS active chassis.

The old VSS active chassis reboots with the new image and becomes the VSS standby chassis.

-> This confirms that both chassis are rebooting during the force-switchover in RPR-Mode.

Hope this finally answers your question.

regards

Alfred

[eotero]

Hi,

My 2 questions:

1. Can I perform the procedure remotely?

2. This command: 

• redundancy reload peer
• redundancy force-switchover

Does it run followed (no waiting time between the two) on the VSS active?

Thank you

[alf]

yes, technically you can perform the upgrade remotely if you have terminal servers in place with access to each console. However, you should be aware, that this type of equipment has some failure risks after rebooting the chassis (known flash problem).

In this case you need to have spare parts an a CE onsite.

The commands described (redundancy reload peer + redundancy force-switchover are manually and sequentially executed with normal priviliged exec-mode prompt. Those are not both automatically executed.

regards

Alfred

[holger.moersfelder@global.ntt]

use FSU to upgrade the VSS or ask your college !