This configuration assigns a chassis mode and priority, and also configures the redundancy link between the primary and backup chassis:

configure
  context srp_ctxt_name
    service-redundancy-protocol
      chassis-mode { primary | backup }
      priority priority
      peer-ip-address ip_address
      hello-interval dur_sec
      dead-interval dead_dur_sec
      end

Notes:

Guard timers ensure that local failures, such as reboots and task restarts, do not result in ICSR events which can be disruptive.

The guard timer command configures the redundancy-guard-period and monitor-damping-period for SRP service monitoring.

configure
  context context_name
    service-redundancy-protocol variable
      guard-timer { aaa-switchover-timers { damping-period seconds | guard-period seconds } | diameter-switchover-timers { damping-period seconds | guard-period seconds } | srp-redundancy-timers { aaa  { damping-period seconds | guard-period seconds } | bgp { damping-period seconds | guard-period seconds } | diam  { damping-period seconds | guard-period seconds } }
      end

Notes:

• aaa-switchover-timers – sets timers that prevent back-to-back ICSR switchovers due to an AAA failure (post ICSR switchover) while the network is still converging.

  • damping-period – configures a delay time to trigger an ICSR switchover due to a monitoring failure within the guard-period.

  • guard-period – configures the local-failure-recovery network-convergence timer.

• diameter-switchover-timers – sets timers that prevent a back-to-back ICSR switchover due to a Diameter failure (post ICSR switchover) while the network is still converging.

  • damping-period – configures a delay time to trigger an ICSR switchover due to a monitoring failure within the guard-period.

  • guard-period – configures the local-failure-recovery network-convergence timer.

• srp-redundancy-timers – sets timers that prevent an ICSR switchover while the system is recovering from a local card-reboot/critical-task-restart failure.

  • aaa – local failure followed by AAA monitoring failure

  • bgp – local failure followed by BGP monitoring failure

  • diam – local failure followed by Diameter monitoring failure

You can enable separate DSCP marking of SRP control and checkpoint messages. The dscp-marking command sets DSCP marking values for SRP control and checkpoint (session maintenance) messages.

configure
  context context_name
    service-redundancy-protocol
      dscp-marking { control | session } dscp_value

Notes:

The ICSR framework reduces switchover disruption for VoLTE traffic by enabling VoLTE traffic on the newly active gateway prior to reconciling the billing information and enabling communication with the newly active gateway when accounting is not deemed critical.

Figure 4. Call Flow: Reduce Non-VoLTE Data Outage

The switchover allow-all-data-traffic SRP Configuration mode CLI command allows all data traffic (VoLTE and non-VoLTE) during switchover transition. This command overwrites the switchover allow-volte-data-traffic command if enabled on a P-GW.

configure
  context context_name
    service-redundancy-protocol
      switchover allow-all-data-traffic

The switchover allow-volte-data-traffic SRP Configuration mode CLI command allows VoLTE data traffic during ICSR switchover transition.

configure
  context context_name
    service-redundancy-protocol
      switchover allow-volte-data-traffic [ maintain-accounting ]

Notes:

The SRP Configuration mode switchover allow-all-data-traffic command allows all data traffic (VoLTE and non-VoLTE) during switchover transition. This command overwrites the switchover allow-volte-data-traffic command if enabled on a P-GW. This feature reduces data traffic outage during the switchover.

All data traffic is allowed on the active chassis during flushing and internal auditing. The billing information is reconciled in the background once the flush is complete.

The SRP Configuration mode switchover allow-early-active-transition command enables early transition to active state during an ICSR switchover. By default this feature is disabled.

Use this command in concert with the switchover allow-all-data-traffic or allow-volte-data-traffic (without maintain accounting option) command to further reduce data outage during a planned switchover. The outage window is the amount time between initiating an ICSR switchover and when the newly active chassis starts processing data.

During an Audit on the gateways (P-GW/S-GW/GGSN/SAE-GW) after Session Recovery or an ICSR event, if any critical information, internally or externally related to a subscriber session seems inconsistent, ICSR will locally purge the associated session information.

Since external gateways (peer nodes) are unaware of the purging of this session, the UE session may be maintained at other nodes. This leads to hogging of resources external to the gateway and an unreachable UE for VoLTE calls.

When this feature is enabled, graceful cleanup for an ICSR audit of failed calls occurs. External signaling notifies peers of session termination before purging the session. The gateway will attempt to notify external peers of the removal of the session. External nodes to the local gateway include S-GW, P-GW, SGSN, MME, AAA, PCRF and IMSA.

Audit failure can occur because of missing or incomplete session information. Therefore, only the peers for which the information is available will be notified.

configure
  require graceful-cleanup-during-audit-failure [ del-cause non-ims-apn   { system-failure | none } ]

The ICSR framework minimizes control outage time associated with the flushing of critical full checkpoint statistics, network convergence and internal auditing.

The amount of time consumed by the following activities affects control outage time during switchover:

The switchover control-outage-optimization CLI command allows new calls during the Accounting Flush, as soon as the Audit is completed. This SRP Configuration mode command enables the quicker restoration of control traffic (call-setup, modification, deletion) following an ICSR switchover.

configure
  context context_name
    service-redundancy-protocol
      switchover control-outage-optimization
      end

You can optionally enable LZ4 compression algorithm for SRP messaging payload. The zlib algorithm remains as the default.

LZ4 is a very fast lossless compression algorithm with near-linear scalability for multi-threaded applications.

The compression keyword in the SRP Configuration mode checkpoint session command allows you to enable the use of the LZ4 compression algorithm.

The following command sequence enables the use of LZ4 compression:

configure
   context context_name
      service-redundancy-protocol 
         checkpoint session compression lz4
         end

LZ4 compression is effective only if both chassis are configured with LZ4. If any one chassis has zlib (default) configured, the compression algorithm reverts to zlib. The algorithm is negotiated only during initial socket establishment. Once agreed no more negotiation takes place until the TCP socket connection is reset.

The default method for synchronizing the SRP database requires tens of seconds of delay whenever the TCP connection between the Active and Standby session managers is established. Once the TCP connection is established, heart beat messages are exchanged between both ICSR chassis every 3 seconds. The standby chassis waits for seven heart beat messages from the active chassis before it is ready to accept data. This may cause significant delay in session manager database synchronization on the standby chassis.

You can enable an aggressive method for synchronizing the session manager database reduces recovery time in the following scenarios:

The aggressive method reduces the number of heartbeat messages and amount of housekeeping information exchanged between ICSR chassis.

The SRP Configuration mode standby database-recovery aggressive command allows you to select normal or aggressive restoration of the SRP database.

The following command sequence enables the aggressive recovery mode:

configure
   context context_name
      service-redundancy-protocol 
         standby database-recovery aggressive
         end

The default form of this command restores the normal mode of SRP database recovery.

Verify that your SRP contexts were created and configured properly by running the show srp info command (Exec Mode) on each chassis.

Notes:

• The interval is specified as an integer divisible by 15 in the range from 30 through 1440 (Default = 45 minutes). The interval range for sending full checkpoints is 30 minutes to 24 hours (1140 minutes).

Use the following example to create the BGP context and network addresses.

configure
  context source_ctxt_name
    router bgp AS_num
      network gw_ip_address
      neighbor neighbor_ip_address remote-as AS_num
      end

Notes:

Use the following example to configure the BGP context and IP addresses in the SRP context.

neighbor_ip_address can be entered in IPv4 dotted-decimal or IPv6 colon-separated-hexadecimal notation. Multiple IP addresses can be added per context as IPv4 and/or IPv6 IP addresses.

An ICSR failover is triggered when all BGP peers within a context are down.

Optionally, you can configure SRP peer groups within a context. ICSR failover would then occur if all peers within a group fail. This option is useful in deployments in which a combination of IPv4 and IPv6 peers are spread across multiple paired VLANs, and IPv4 or IPv6 connectivity is lost by all members of a peer group.

A sample configuration for SRP peer groups within a context ("PGWin") appears below.

monitor bgp context PGWin 10.1.1.16 group 1
monitor bgp context PGWin 10.1.1.17 group 1
monitor bgp context PGWin 69.2.215.0 group 2
monitor bgp context PGWin 69.2.215.1 group 2
monitor bgp context PGWin 2001:4333:201:1102:103:2a1:: group 3
monitor bgp context PGWin 2001:4333:201:1102:103:2a1:0:1 group 3

In the above sample configuration, ICSR failover would occur if both addresses in group 1, 2 or 3 lost connectivity.

For additional information refer to the description of the monitor bgp, monitor diameter and monitor authentication-probe commands in the Service Redundancy Protocol Configuration Mode Commands chapter of the Command Line Interface Reference.

Verify your BGP configuration by entering the show srp monitor bgp command (Exec Mode).

Use the following example to create the BGP context and network addresses.

configure
  context dest_ctxt_name
    router bgp AS_num
      network gw_ip_address
      neighbor neighbor_ip_address remote-as AS_num
      end

Notes:

Use the following example to configure the BGP context and IP addresses in the SRP context.

Use the following example to set the subscriber mode to default.

Verify your BGP configuration by entering the show srp monitor bgp command (Exec Mode).

Health checks are a series of Exec mode show commands to determine the readiness of the system to handle a software update.

Service Redundancy Protocol (SRP) checks verify that the mechanism for monitoring ICSR system status is operational.

Border Gateway Protocol (BGP) checks are only required when BGP is used to support redundant interchassis communication. These checks are run per context and per service type.

You must add a new boot stack entry for the recently downloaded software image (.bin) file.

Synchronize the local file systems by entering the following Exec mode command:

[local]host_name# filesystem synchronize all 

Reboot the StarOS by entering the following command:

[local]host_name# reload [-noconfirm]

As the system reboots, it loads the new operating system software image and its corresponding CLI configuration file using the new boot stack entry configured earlier.

After the system reboots, establish a CLI session and enter the show version command to verify that the active software version is correct.

Optional for PDSN: If you are using the IP Pool Sharing Protocol during your upgrade, refer to Configuring IPSP Before the Software Upgrade in the PDSN Administration Guide.

Features in the new operating system may require changes to the configuration file. These changes can be done manually or facilitated by custom scripts prepared by Cisco TAC. Make whatever changes are necessary prior to saving the updated configuration file.

After the system has successfully booted, verify that the new StarOS version is running by executing the Exec mode show version command.

You can run the Exec mode show build command to display additional information about the StarOS build release.

Use the Exec mode save configuration command to save the currently running configuration to the /flash device and to an off-chassis location (external memory device or network URL). The off-chassis copy assures that you will have a fallback, loadable configuration file should a problem be encountered.

Allow time for session synchronization to occur between the ICSR chassis before preceding to the next steps.

An SRP switchover places the primary chassis in standby mode and makes the backup chassis active. The secondary chassis is now processing sessions with the upgraded software.

If your network deployment requires communication with AAA servers, log into the newly active system and perform an AAA monitor check. You will be checking for the existence of any SNMP traps that indicate the system cannot communicate with AAA servers (starSRPAAAUnreachable).

Log into the backup (standby) system and repeat the following tasks to complete the upgrade process on the backup (standby) system:

• Updating the Boot Record
• Reboot StarOS
• Updating the Configuration File
• Verifying the Software Version
• Saving the Configuration File
• Synchronizing File Systems
• Performing Health Checks
• Performing SRP Checks
• Performing BGP Checks
• Waiting for Session Synchronization

This SRP switchover places the primary system in active mode and returns the backup system to the standby. The primary chassis is now processing sessions with the upgraded software.

Once the chassis state is verified and subscribers are migrated, perform new call testing to make sure calls are successful.