krahmani323 Thu, 05/20/2010 - 08:25

Hello Tami,

If in IOS, in order to determine which module is active in the chassis use show redundancy command. Depending on the redundancy mode configured under 'redundancy' configuration mode*** For example for SSO you should see ACTIVE for the primary module and STANDBY HOT....

If not in expected state you can configure, check the hardware configuration guidelines restriction and/or the configuration

(for example for SSO : http://www.ciscorouters.biz/en/US/docs/switches/lan/catalyst6500/ios/12.2SXF/native/configuration/guide/nsfsso.html#wp1095529)

--------------------------------------------------------------------------------------------

Otherwise, the first supervisor module to successfully boot up becomes the active  supervisor for the chassis. The other supervisor remains in a standby role,  waiting for the active supervisor to fail.

If you want to change the behaviour you can perform a switchover (reload of the active module) =>

"To force a switchover ----> from the active to the  standby supervisor engine <-----, use the redundancy  force-switchover command."

(http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/ios/12.1E/native/command/reference/R1.html#wp1079728)

If I want to see the switchover history use show redundancy switchover.

*** About redundancy

You can use the following redundancy modes on Catalyst  switches:

  • Route Processor Redundancy  (RPR) The redundant supervisor is only partially booted and initialized.  When the active module fails, the standby module must reload every other module  in the switch and then initialize all the supervisor functions.

  • Route Processor Redundancy Plus  (RPR+) The redundant  supervisor is booted, allowing the supervisor and route engine to initialize. No  Layer 2 or Layer 3 functions are started, however. When the active module fails,  the standby module finishes initializing without reloading other switch modules.  This allows switch ports to retain their state.

  • Stateful Switchover (SSO) The  redundant supervisor is fully booted and initialized. Both the startup and  running configuration contents are synchronized between the supervisor modules.  Layer 2 information is maintained on both supervisors so that hardware switching  can continue during a failover. The state of the switch interfaces also is  maintained on both supervisors so that links don't flap during a failover.

Hope it helps.

Kind regards.

Karim

Actions

This Discussion