The following SNMP traps are raised when pairing is done with an incompatible release.

The following are the known limitations of the feature:

• When the peer version is determined to be lower than the supported N-4 version, the association/pairing is allowed. However, functional aspect of the same isn't guaranteed.

  Caution

  Don't attempt to upgrade from incompatible versions. Contact your Cisco Account representative for the upgrade path and steps.

  SNMP traps are raised by the node on the latest version with respect to the StarOS version. For details, see the SNMP Trap section of this chapter.

• From release 21.24.1, RCM is checkpoint agnostic to enable support for future UP releases. Currently RCM does not support N-4 compatibility and only supports N-1 compatibility.

Perform the following health checks after every operation of upgrade, downgrade, or reload of chassis.

1. Check the Service Redundancy Protocol (SRP) information on the Active chassis to avoid issues during an SRP switchover and decide if proactive analysis must be done before the SRP switchover. Use the following CLI commands:

   • srp validate-configuration srp validate-switchover

   • show srp info

   The following is a sample output.

   Peer Configuration Validation: Complete
   Last Peer Configuration Error: None
   Last Peer Configuration Event: Wed Mar 18 15:34:02 2019  (1602 seconds ago)
   Last Validate Switchover Status: None
   Connection State: Connected

   Check the following parameters:

   • Peer Configuration Validation: Complete—If it shows "In Progress", you must wait and then execute the show srp info again after 15 seconds (approximately).

   • Last Peer Configuration Error: None—If you see "Peer Checksum Validation Failure", then it indicates that there are configuration differences between Active and Standby chassis that must be fixed.

   • Last Validate Switchover Status: None—The output must show as "None". And, output should be Remote Chassis - Ready for Switchover (XX seconds ago) when the srp validate-configuration and srp validate-switchover CLI commands are triggered.

   • Connection State: Connected—The output must show as "Connected".

2. Check subscriber count on both Active and Standby chassis.

   After sessions are up, execute show subscribers summary | grep Total CLI command in the Active chassis. The following is a sample output.

   show subscribers summary | grep Total 
      Total Subscribers:  100

   On Standby chassis, execute show srp checkpoint statistics | grep allocated CLI command. The following is a sample output.

   show srp checkpoint statistics | grep allocated 
      Current pre-allocated calls:  100

3. Check the status of the license by executing show license information CLI command. It should be in "Good (Redundant)" and not in "Expired" state.

4. Check the Session Recovery Status by executing the show session recovery status verbose CLI command. The following is a sample output.

   Session Recovery Status:
     Overall Status        : Ready For Recovery
     Last Status Update    : 7 seconds ago
   
                 ----sessmgr---  ----aaamgr----  demux
    cpu state    active standby  active standby  active  status
   1/0  Active     8      1        8      1        17     Good

5. Verify all the SessMgrs are in Standby-Connected state on Standby chassis by executing show srp checkpoint statistics | grep Sessmgrs CLI command. The following is a sample output.

   Number of Sessmgrs:        1
   Sessmgrs in Active-Connected state:  0
   Sessmgrs in Standby-Connected state: 8
   Sessmgrs in Pending-Active state:    0

6. Verify the status of all the cards to see if they are in Active or Standby state. The following is a sample output.

   show card table
   
   Slot          Card Type              Oper State  SPOF  Attach
   ----------- ------------------------ ----------- ----- ------
   1: VC        5-Port Virtual Card     Active        -

7. Execute show task resources | grep -v good CLI command and its output must only display the total number of SessMgrs and sessions.

8. Execute the show crash list CLI command to check if there were any new crashes.

9. Execute the show service all CLI command to verify that the state is displayed as "Started" and not "Initialized".

Backup Configuration

1. Back up the current configuration—save current configuration, that will be used in case of downgrade, which probably has all the features and configuration present until now.

2. Collect the show support details on both Active and Standby chassis before making any changes or Upgrade.

3. Perform Health Checks.

Upgrade Procedure

1. Perform chassis Health Checks on both the nodes.

2. On the secondary chassis (ICSR), which is in Standby state, change boot priority with N build.

3. Reload to latest 21.xx.xx build.

4. Do the new configuration change on Standby chassis (For example, any new CLI, license, or configuration changes.).

5. Do Health Check on the reloaded chassis. Check for any crashes or errors.

Perform Switchover

1. Before SRP switchover from Active to Standby on both chassis, check:

   1. On Active chassis: show subscriber summary | grep Total

   2. On Standby chassis: show srp checkpoint statistics | grep allocated

      Note	The count must be same for both.

   3. On Active and Standby chassis: show sx peer

      For example:

      |||||  Sx Service                                               No of
      |||||  ID                                                                Restart
      |||||  |                                               Recovery              |    Current    Max        Peer
      vvvvv  v     Group Name    Node ID         Peer ID     Timestamp             v    Sessions   Sessions   State   
      ----- ---- ----------------- ------------------------- ------------------- ------ --------- --------- -------- 
      CAAXD  22    CPGROUP21   209.165.200.225   50331649    2021-03-17:02:33:55    0        0          0      NONE     
      
      Total Peers:    1
      

      Note	Peer state must be Active and associated. Peer ID must match on both the chassis.

   4. On Standby chassis: show srp checkpoint statistics | grep Sessmgrs

      Note	"Number of Sessmgrs" must be equal to the "Sessmgrs in Standby- Connected state".

   5. On Active chassis:

      1. srp validate-configuration : This CLI command is for initiating a configuration validation check from the ACTIVE chassis. If the validation doesn't have any error, output of this CLI command is blank.

      2. srp validate-switchover : Validates both Active and Standby chassis are ready for a planned SRP switchover. If chassis is ready for switchover, then the output of this CLI command is blank.

      3. show srp info | grep "Last Validate Switchover Status" : Output of this CLI command must be as follows.

         Last Validate Switchover Status: Remote Chassis - Ready for Switchover

      4. show srp info debug : Active and Standby chassis must have the same output.

2. On Active chassis: srp initiate-switchover

   1. Perform chassis Health Checks on both the nodes. Also check Step 1a and Step 1c under the Performing Switchover section. There can be a difference of 5%.

   2. Perform call testing since new sessions are serviced on the new Active chassis.

   3. Upgrade the old Active as mentioned in Step 2 through Step 5 under the Upgrade Procedure section.

This section describes the procedure for CP-only upgrade.

1. Perform Health Check procedure on both CP nodes as mentioned in the Health Checks section.

2. Perform Upgrade on Standby CP as mentioned in the Build Upgrade section.

   Note	If the context names on CP and UP are different, then execute debug pgw pfd-mgmt CLI command on the upgraded CP before making it Active.

3. Perform Health Check on both chassis, and then do CP switchover to the upgraded chassis.

4. Verify that the new chassis is taking the new sessions, there are no new crashes, or session drop due to error scenarios. Do Health Check on both the CP and UP.

5. Upgrade the new Standby CP as mentioned in the Build Upgrade section.

This section describes the procedure for UP-only upgrade.

1. Perform Health Check procedure on both the UP nodes as mentioned in the Health Checks section.

2. Perform Upgrade on Standby UP as mentioned in the Build Upgrade section.

3. Do "sx-peer configuration" on the upgraded Standby chassis.

4. Perform Health Check on both the UP nodes, and then do UP switchover.

5. Upgrade the new Standby UP as mentioned in the Build Upgrade section.

This section describes the procedure for upgrading the CP first and then upgrading the UP, or the other way round.

Upgrading CP First

1. Perform Health Check procedure on both CP and UP, as mentioned in the Health Checks section.

2. Perform Upgrade on Standby CP as mentioned in the Build Upgrade section.

   Note	If the context names on CP and UP are different, then execute debug pgw pfd-mgmt CLI command on the upgraded CP before making it Active.

3. Perform Upgrade on Standby UP as mentioned in the Build Upgrade section.

4. Upgrade both Standby CP and UP to N build.

5. Perform Health Check on both chassis, and then do CP switchover to the upgraded chassis.

6. Verify that the new chassis is taking the new sessions, there are no new crashes, or session drop due to error scenarios.

7. Perform Health Check on both the UP nodes, and then do UP switchover.

8. Perform Health Check on newly Active UP. Verify that there are no call drops, and data is flowing through the new chassis.

9. Upgrade new Standby CP and UP as mentioned in the Build Upgrade section.

Upgrading UP First

1. Perform Health Check and build transfer procedure on both CP and UP.

2. Perform Upgrade on Standby UP as mentioned in the Build Upgrade section.

3. Do "sx-peer configuration" on the upgraded Standby chassis.

4. Perform Health Check on both the UP nodes, and then do UP switchover.

5. Perform Upgrade on new Standby UP as mentioned in the Build Upgrade section.

6. Perform Upgrade on Standby CP as mentioned in the Build Upgrade section.

7. Perform Health Check on both the CP nodes, and then do CP switchover.

   Note	If the context names on CP and UP are different, then execute debug pgw pfd-mgmt CLI command on the CP.

8. Upgrade new Standby CP chassis. Perform Health Check.

9. Perform Health Check on both the Active and Standby UP.

10. If everything is working as expected, then do the configuration changes on the Standby CP first. Then do the similar changes on the Active CP and execute push config-to-up all CLI command. New changes are pushed to the new Active UP.

Downgrade – Both CP and UP

If there are new configurations and/or configuration changes needed on CP as part of Upgrade, then follow the steps to upgrade the UP first.

1. Do Health Check on both CP and UP.

2. Change boot priority to the N-1/N-2/N-3/N-4 build on the Standby UP. Reload Standby UP.

3. Do "sx-peer configuration" on downgraded Standby UP.

4. Do Health Check on both the UP nodes and then do UP switchover.

5. Perform Step 1 to Step 3 on new Standby UP.

6. Change boot priority to N-1/N-2/N-3/N-4 build on the Standby CP. Reload the Standby CP.

   Note	If the context names on CP and UP are different, then execute the debug pgw pfd-mgmt.. CLI command on the CP.

7. Load the configuration that has been saved in Step 1 mentioned in Backup Configuration section in Build Upgrade.

8. Do Health Check on both CP nodes and then do the CP switchover.

9. Perform Step 6 and Step 7 to downgrade old Active.

10. On Active CP, execute push config-to-up all CLI command so that changes in the configuration are pushed to the UP.

Downgrade – CP Only

Perform Step 6 through Step 10 mentioned in the Downgrade – Both CP and UP section.

Downgrade – UP Only

Perform Step 1 through Step 5 mentioned in the Downgrade – Both CP and UP section.