cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1132
Views
8
Helpful
8
Replies

Howto update Sup2T VSS (Cat65/68) when new version is not EFSU compatible?

Hi,

we're evaluating using VSS for a new customer core and distribution layer.

We already read the current Sup2T configuration guide and also the Borderless Campus Design Guide but did not found information about how to act when ios versions are not EFSU compatible.

Does anybody know how a VSS can be updated to a new IOS version if the new image is not eFSU compatible (www.cisco.com/en/US/docs/switches/lan/catalyst6500/ios/SX_SY_EFSU_Compatibility_Matrix.xlsx) ? By a reboot of both chassis with boot pointer to the new version?

Is there a possibility to prevent a downtime of the complete VSS pair?

Does quad-sup VSS solve this problem?

 

Best Regards

Thorsten Steffen

1 Accepted Solution

Accepted Solutions

When it works, FSU/eFSU will ensure both chassis will be up if you've got quad-supervisor setup.  You will loose a few pings when the supervisor cards flip control.

View solution in original post

8 Replies 8

Leo Laohoo
Hall of Fame
Hall of Fame
Is there a possibility to prevent a downtime of the complete VSS pair?

Not remotely possible.  When you have a blade booting up with a different IOS with the active supervisor, the second blade will immediately go into ROMmon.

Does quad-sup VSS solve this problem?

No it doesn't.  It only complicates the matter even further.

We already read the current Sup2T configuration guide and also the Borderless Campus Design Guide but did not found information about how to act when ios versions are not EFSU compatible.

FSU, or even eFSU, is very good if it works at all.  If it doesn't work ... let's say the process to go around this can make you stay up all night.  

 

The work-around we've developed works.  And it works far better than FSU/eFSU.  The downside with the work-around is you need to reboot the entire chassis.  It's not like FSU/eFSU where one chassis will go down with the other blade takes over.  

 

Before I discuss the process, there's a mandatory requirement:  Make sure your the MD5 hash value of your IOS matches with the MD5 hash value found in the Cisco website.  The MD5 hash value is a sure-fire guarantee the IOS you have in your TFTP server is not corrupt and is complete.  

 

Here's the work-around process: 

 

1.  Copy the IOS from your TFTP server to the active supervisor card:  copy tftp://IOS_filename.bin sup-bootflash:

2.  Copy the IOS from your TFTP server to the standby supervisor card:  copy tftp://IOS_filename.bin slavesup-bootflash:

3.  Remove the old bootstring, change the bootstring to reflect the new IOS and (optionally) configuring the old bootstring for backup.  The command sequence are: 

config t
no boot system flash sup-bootflash:OLD_IOS_filename.bin
boot system flash sup-bootflash:NEW_IOS_filename.bin
boot system flash sup-bootflash:OLD_IOS_filename.bin
end
wr

4.  Reboot.

 

 

 

Agreed with Leo

make it easy on yourself.  Have an outage window, do the command Leo provided, reboot and you will be all set.

HTH

That means EFSU is a very reliable way to update in your experience? What are the problems you experienced with EFSU?

Hence, how would EFSU work with quad sup sso? Would both chassis stay up during the update ... if it works?

Quad-Supervisor card IOS upgrade is the same thing as I've mentioned above.  Copy the IOS into the four supervisor cards and change the boot variable statement and then reboot both pairs.

 

FSU/eFSU works well if it works.  If it doesn't work ... well, you follow the work-around I have detailed above.

Thanks Leo, I understand.

Today we already use this work-around on Cat45 with Sup7/8 when we don't have to use ISSU because of minimizing the downtime.

Hence I just want to understand how upgrading of the newest quad-sup-sso (intra- + inter-chassis sso) works with EFSU. Would both chassis stay online in this case?

The method I've detailed above will cause both chassis to reboot simultaneously.  Ergo, you'll get downtime.  

maybe my english is too bad ;-)

I just try to understand how updating works when I use not your recommended method but the Cisco EFSU method. Do both chassis stay online when using EFSU with intra-chassis sso - when it works?

When it works, FSU/eFSU will ensure both chassis will be up if you've got quad-supervisor setup.  You will loose a few pings when the supervisor cards flip control.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Review Cisco Networking products for a $25 gift card