cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1430
Views
0
Helpful
5
Replies

VSS Setup, moving from SXH to SXI & Modular to non-modular

Hi all,

We currently have a pair of chassis configured with VSS running Version 12.2(33)SXH6, (modular).

With SXH being EOL'd by Cisco, and the fact we have a requirement for SXI only features (FWSM support, & better ipv6 support) it makes sense for us to move trains now.

With the rumor going around that modular ios is to be discontinued early 2011 as well, I would like to move from our current modular setup to native ios as well, but I can't seem to find a good enough white paper on the process.

With SXH having no EFSU support, we have always done our upgrades using FSU previously, meaning a period of downtime during the shift. This is always done by installing the new image to newsys, renaming old to oldsys, rebooting the standby chassis, then the primary.

However, Is there anything to take into consideration when going back from modular to native, or is it just a case of removing the bootloader statements and pointing it to the native ios .bin file as well. Will this cause issues with FSU being a mix of native & modular, etc, or should it still work as planned?

The plan I'm coming up with at the moment would be to just follow the FSU procedure located here

http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/ios/12.2SX/configuration/guide/vss.html#wp1169328

  This example shows how to perform an FSU:

 Router# config terminal 
 Router(config)# no boot system 
 Router(config)# config-register 0x2102 
 Router(config)# boot system flash disk0:image_name 
 Router(config)# end 
 Router# copy running-config startup-config 
 Router# redundancy reload peer 
 Router# redundancy force-switchover 

I don't have a lab VSS environment to test this on, but do have a stand-alone supervisor running SXI4a without problem and another box with SXH6 Modular ready to upgrade with a test configuration to SXI4a.

Any advice in regards to what procedure to follow would be appreciated.

5 Replies 5

Reza Sharifi
Hall of Fame
Hall of Fame

Hi David,

Since you are going from a modular to a non-modular code, eFSU does not work.  You have to load the new IOS (SXI4a is pretty good these days) to your supboot disk and slave supboot disk and change the boot variable to reflect the new IOS and reboot both switches. We tried to use eFSU, but after wasting some times, we found out that it does not work.  So, if you have an outage windows, the easiest way to do it is by doing what I explained above.

HTH

Reza 

many thanks Reza, I suspected that would be the case. You mention eFSU isn't going to work, but SXH has no eFSU support anyway, just FSU support. Would you still think re-booting both boxes simultaniously would be advisable rather than the typical FSU of re-boot slave, re-boot primary etc?

Also, what would the outage window be for both chassis re-booting simultaniously before traffic begins to pass again? I've read around 20 mins, which would probably be too long an outage. At least with FSU, you only get a 5 minute outage in the middle of your upgrade, as you've already reloaded the secondary chassis.

Cheers,

Dave

Dave,

If you reboot both switches at the same time, it takes approximately 20 minutes for them to load.  Of course the fewer line card you have, the faster the switch boots, but to be sure you need about 20 minutes.  I have actually timed it a couple of times.

HTH

Reza

Leo Laohoo
Hall of Fame
Hall of Fame

We're testing SXI5 since last week.  So far, so good.

Odd issue trying to upgrade this tonight.

We decided first to move from SXH6 Modular to SXH6 Native. Then we will schedule in the SXH > SXI change. So, this was just a modular/native switch of the same versions...

Didn't go as planned at all.

The standby supervisor refuses to see the new image and switch to RPR mode. it just comes back running the modular IOS and straight back to SSO.

TFTP'd software images to both SUPS ahead of schedule, and did the following.

       * No Boot System

        * Config-Register 0x2102
     
        * Boot System Flash sup-bootdisk:s72033-advipservicesk9-mz.122-33.SXH6.bin (The non-modular image installed)

        * Write mem (this should sync the bootvar across the two chassis, telling both supervisors to boot the new image upon reload)

        * Redundancy reload shelf 2 (to reload the standby)

         Secondary reloads, and came back up, but when I do “show switch virtual redundancy”, and The mode is SSO still, not RPR. And it’s still booting the modular image!

VSS#show switch virtual redundancy
                   My Switch Id = 1
                 Peer Switch Id = 2
         Last switchover reason = active unit removed
     Configured Redundancy Mode = sso
      Operating Redundancy Mode = sso

Switch 1 Slot 5 Processor Information :
-----------------------------------------------
         Current Software state = ACTIVE
                         Image Version = Cisco IOS Software, s72033_rp Software (s72033_rp-ADVIPSERVICESK9-VM), Version 12.2(33)SXH6, RELEASE SOFTWARE (fc1)
Technical Support: http://www.cisco.com/techsupport
Copyright (c) 1986-2009 by Cisco Systems, Inc.
Compiled Thu 15-Oct-09 03:31 by prod_rel_team
                           BOOT =
s72033-advipservicesk9-mz.122-33.SXH6.bin,1;
                    CONFIG_FILE =
                        BOOTLDR =
         Configuration register = 0x2102
                   Fabric State = ACTIVE
            Control Plane State = ACTIVE

Switch 2 Slot 5 Processor Information :
-----------------------------------------------
         Current Software state = STANDBY HOT (switchover target)                  Image Version = Cisco IOS Software, s72033_rp Software (s72033_rp-ADVIPSERVICESK9-VM), Version 12.2(33)SXH6, RELEASE SOFTWARE (fc1)
Technical Support: http://www.cisco.com/techsupport
Copyright (c) 1986-2009 by Cisco Systems, Inc.
Compiled Thu 15-Oct-09 03:31 by prod_rel_team
                           BOOT =
s72033-advipservicesk9-mz.122-33.SXH6.bin,1;
                    CONFIG_FILE =
                        BOOTLDR =
         Configuration register = 0x2102
                   Fabric State = ACTIVE
            Control Plane State = STANDBY

Attempted the same again, with a console connection to the secondary supervisor, and you can actually see it start to boot the modular image! seemingly ignoring the bootvar!

My next step should be "Redundancy force-switchover" But what's the point of forcing the switchover if it's just reloaded the same modular image!

Henceforth, I'm stuck! I can't get the standby sup to boot off the new image and go into RPR, and I don't want to reload both boxes at the same time with no confidence it's going to work.

Anyone any idea what's going on?

Thanks,


Dave.

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