cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2614
Views
0
Helpful
6
Replies

Catalyst 6500 Dual-Supervisor 720-10G-3C Problem

Toi Seng Chang
Level 1
Level 1

Hi,

There is some questions about 6500 Dual-Supervisor (Single Chassis) failover functions, hope that someone can help:)

1. We now have SupA & SupB in the chassis, due to some mistake we have same IOS version but different feature set on them, although we configured redundancy mode sso, in the "show redundancy" we see Operating Redundancy Mode = rpr due to Software mismat, we now need to fix them as same feature set image, if I use "copy sup-bootdisk0:/xxxx slavesup-bootdisk0:/xxx", then write memory, does this cause any service/network interuption? If so, what is the best method to do this, please advise!

       Available system uptime = 1 year, 1 week, 4 days, 9 hours, 21 minutes

Switchovers system experienced = 2

              Standby failures = 0

        Last switchover reason = active unit removed

                 Hardware Mode = Duplex

    Configured Redundancy Mode = sso

     Operating Redundancy Mode = rpr    Reason: Software mismat

              Maintenance Mode = Disabled

                Communications = Up

2. We did a failover test with this status, found that if we triggered supervisor failover, all modules will reload thus the services if interupped. How about after we make the Operating Redundancy Mode as sso, will this behaviour shows again? Or a stateful failover will happens, then modules no need reload?

3. We are using OSPF as our L3 routing protocol, after reference to the configuration, nsf should be enabled, we want to ask in the OSPF-domain nsf should be configured in all OSPF-enabled router or only 6500 which have dual-sup?

4. We also found that the interfaces(3 * Gig & 2 * TenG) in Standby supervisor cannot be use even enabled & configured, is it because we are running rpr mode now or will be the same even change to sso? Before customer have some older supervisor in 6500 non-e chassis, and they can use the standby supervisor interfaces as traffic forwarding, they use rpr-plus mode before, how about in sso mode?

6 Replies 6

Giuseppe Larosa
Hall of Fame
Hall of Fame

Hello Toi,

>>  if I use "copy sup-bootdisk0:/xxxx slavesup-bootdisk0:/xxx", then write memory, does this cause any service/network interuption?

No you are only copying a file from a filesystem to another fylesystem no impact on this.

After you achieve SSO, STANDBY HOT on stanby supervisor the switchover time is much lower as linecards are not reset.

You can use the following procedure prepared by Cisco expert Ivan Shirshin in a recent thread

Also, by different amount of memory I meant DRAM on Switch and Route processor. You can check the mmeory about using the "show ver | i memory" for RP and "remote command switch show ver | i memory" for SP on active supervisor.

Standby could be checked before insertion by following this guide, see Figure 3-6:

http://www.cisco.com/en/US/docs/routers/7600/Hardware/Hardware_Guides/Supervisor_Engine_and_Route_Switch_Processor_Guide/SupE03_ps368_TSD_Products_Installation_Guide_Chapter.html#wp1165752

I suggest to proceed with that plan:

1)  Check the memory on standby before inserting it per the above mentioned steps.

2)  Insert a flash disk into active RSP:

   - format it

   - copy IOS image on a flash disk. You can find the location of currently used image from "show version" command.

2)  Plug your laptop into the console port of the standby supervisor and get your terminal program working.

3)  Insert the flash disk into a standby supervisor, then insert standby supervisor into the chassis, firmly seating the supervisor into the chassis.

4)  Watch the standby supervisor come up, making sure that it boots properly and doesn't get stuck in . If it does, make sure the config-register is correct and that there is image to load from:

    rommon> confreg 0x2102

    rommon> sync

    rommon> reset

5)  Log in to the current active supervisor.

6)  Run the command: show redundancy            

             You're looking to see that the new supervisor is listed as or .

7) If the above is true continue to step 8, if the state is or - check whether the new supervisor is in rommon.

8)  Run the command "copy "

    Example:

        copy bootflash:s72033-advipservicesk9_wan-mz.122-33.SRE1.bin slavebootflash:s72033-advipservicesk9_wan-mz.122-33.SRE1.bin  

9)  Run the command "dir " and confirm that the IOS is in the expected standby flash file system, e.g. slavebootflash:.

        dir slavebootflash:

10) Run the command "verify " and confirm the CRC is correct:

        verify slavebootflash:s72033-advipservicesk9_wan-mz.122-33.SRE1.bin  

11) Run the command "hw-module module reset" to reload standby and make it come up with correct image.

    The value is the slot number of the standby module. If you enter this incorrectly you may reload the entire chassis, use with caution. x in you case will likely be 6.

12) Wait for the standby supervisor to fully load.

13) Run the command "show redundancy". It should show the state of the standby supervisor as "Standby Hot".

14) Now you're done.

Hope to help

Giuseppe

Reza Sharifi
Hall of Fame
Hall of Fame

Hi

1. We now have SupA & SupB in the chassis, due to some mistake we  have same IOS version but different feature set on them, although we  configured redundancy mode sso, in the "show redundancy" we see  Operating Redundancy Mode = rpr due to Software mismat, we now need to  fix them as same feature set image, if I use "copy sup-bootdisk0:/xxxx  slavesup-bootdisk0:/xxx", then write memory, does this cause any  service/network interuption? If so, what is the best method to do this,  please advise!

Copying the ios image from the primary sup to the stand-by sup does not effect anything. Once the copy is completed, you would need to change the mode to SSO and reboot the stand-by chassis.  When the stand-by finish rebooting, now sh redu should show that the mode is SSO. with the second sup as stand-by.  It is of course a good idea to do the reboot during an outage window in case something goes wrong.

2. We did a failover test with this status, found that if we triggered  supervisor failover, all modules will reload thus the services if  interupped. How about after we make the Operating Redundancy Mode as  sso, will this behaviour shows again? Or a stateful failover will  happens, then modules no need reload?

The modules should not rebbot.  Try SSO and test again.

3. We are using OSPF as our L3 routing protocol, after reference to the  configuration, nsf should be enabled, we want to ask in the OSPF-domain  nsf should be configured in all OSPF-enabled router or only 6500 which  have dual-sup?

NSF should be enabled for OSPF on the 6500 when you have dual sups.  For simplicity you can enable it on all, but you don't have to.

4. We also found that the interfaces(3 * Gig & 2 * TenG) in Standby  supervisor cannot be use even enabled & configured, is it because we  are running rpr mode now or will be the same even change to sso? Before  customer have some older supervisor in 6500 non-e chassis, and they can  use the standby supervisor interfaces as traffic forwarding, they use  rpr-plus mode before, how about in sso mode?

You should be able to create an Etherchannel using a 1gig from the primary sup and one from the stand-by. The same for 10Gig interfaces.

HTH

Hi,

Would like to add some detail along with Reza,

Answer for Question 2:

In SSO mode, Layer 2 protocols and PFC hardware contents are synchronized from the active supervisor to the standby supervisor. Upon switchover, Layer 2 traffic can be forwarded without disruption.

Even though SSO helps ensure stateful switchover for many protocols, some packet loss occurs in most circumstances during SSO switchover due to fabric and bus data plane reestablishment. The SSO switchover could cause data-plane traffic loss in the order of 0 to 3 seconds depending on the conditions

In RPR redundancy, during switchover, all switching modules are powered on again. So there is be a few minutes of downtime. During normal switchovers, if the operational redundancy is SSO, the installed switching modules are not reloaded, as both the startup and running config are synchronized continually from active to standby supervisor engine

http://www.cisco.com/en/US/products/hw/switches/ps708/products_configuration_example09186a0080a98f3c.shtml

Answer for Question 4:

Yes, You can use the interfaces on redundant supervisor. When a redundant supervisor engine is in standby mode, the two Gigabit Ethernet interfaces on the redundant supervisor engine are always active unless you enter the fabric switching-mode allow dcef-only command

With a Supervisor Engine 720, if all the installed switching modules have DFCs, enter the fabric switching-mode allow dcef-only command to disable the Ethernet ports on both supervisor engines, which ensures that all modules are operating in dCEF mode and simplifies switchover to the redundant supervisor engine

http://www.cisco.com/en/US/partner/docs/switches/lan/catalyst6500/ios/12.2SX/configuration/guide/nsfsso.html

Supervisor Engine 720-10GE Restrictions

In RPR redundancy mode, the ports on a Supervisor Engine 720-10GE in standby mode are disabled.

http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/ios/12.2SX/release/notes/hardware.html

Regards,

Aru

Regards, Aru *** Please rate if the post useful ***

Reza Sharifi
Hall of Fame
Hall of Fame

BTW, are your Sups 720 or 720-VS?

Toi Seng Chang
Level 1
Level 1

Thanks for all you guys support!!! I know the procedure now, will go for it on next maintenance window.

We are using VS-720-10G-3C supervisor right now, but didn't enable VSS at the moment, only 2 * VS-720-10G-3C model supervisor in the same chassis, anything we need to take care in future if we deploy quad-supervisor VSS ?

Besides, as my understanding quad-sup VSS also will use sso/nsf for intra-chassis failover, am I right?

Hi Toi,

Thanks for your kind response.

Virtual Switching System (VSS) Quad-Supervisor Uplink Forwarding

Cisco IOS Software Release 12.2(33)SXI4 introduces support for dual-supervisors in each of the active and standby VSS chassis, together forming a quad-supervisor VSS system. These secondary supervisors can also be used to forward traffic on the uplink ports thereby enabling all four supervisors in a VSS system to actively forward traffic under normal conditions. Furthermore, the additional supervisors can act as standby supervisors within each chassis to provide resilient network connectivity to single-homed devices and maximum bandwidth availability to both upstream and downstream connected devices

http://www.cisco.com/en/US/prod/collateral/switches/ps5718/ps708/product_bulletin_c25_603217.html

VSS rely on SSO+NFS to offer High Availability services

A VSS uses interchassis NSF/SSO as the primary mechanism for high availability between the two chassis. One virtual switch member chassis will act as the active virtual switch member, while the other member will be in hot standby state for the control plane

Note that the data planes of both chassis are active and hence forward traffic at full combined capacity of 1440 Gbps. When one of the virtual switch members fails, there is no reconvergence of protocols in the network. The access layer or core layer switches continues to forward traffic because they only detect a link failure in an EtherChannel bundle and hence do not need to reconverge any protocols. No disruption occurs to the traffic flowing through the VSS. The VSS mechanism during switch failure is far superior when comparison with the traditional model where one switch failure results indeterminist convergence of multiple control protocols like STP, HSRP and routing protocol.

http://www.cisco.com/en/US/prod/collateral/switches/ps5718/ps9336/prod_qas0900aecd806ed74b.html

Regards,

Aru

Regards, Aru *** Please rate if the post useful ***
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:

Innovations in Cisco Full Stack Observability - A new webinar from Cisco