Unified ISSU Upgrade Phase Overview

During the upgrade phase, the CLI supports only a reduced set of administrative commands. You cannot interrupt the upgrade phase. The upgrade phase cannot commence if any CLI commands outside of this set are executing when you issue the issu start command.

Note: Although you can use any CLI session to issue the issu start command, we recommend that you issue the command from a session to the management console port. When the standby SRP module switchover takes place, all management network connections through the Ethernet management port are dropped, and you can access the router only through a console port until the service restoration phase is completed.

When you issue the issu start command, unified ISSU performs the following operations:

  1. Verifies that the unified ISSU requirements on the router are still met.
  2. Verifies that the active and standby SRP modules are synchronized. If they are not synchronized, forces a synchronization to ensure that all configuration and file system changes are propagated to the standby SRP module before proceeding with the upgrade.
  3. Copies the NVS configuration from a backup memory area to the flash card on the standby SRP module. During the initialization phase, this configuration data was mirrored from NVS on the active SRP module and upgraded as required by the armed release.
  4. Upgrades the control plane on each line module at the same time.
  5. Switches control from the primary SRP module (running the current release) to the standby SRP module (running the armed upgrade release).
  6. Upgrades the forwarding plane on each line module at the same time. The fabric is switched and upgraded.

You can view the status of the router and the progress of the upgrade at any time by issuing the show issu command from another terminal session to the router.

Note: While a unified ISSU operation is in progress, do not remove the SRP modules or attempt to reset them. Removing the SRP modules anytime during unified ISSU has an adverse impact.

After the unified ISSU operation is completed, issue the show version command. The output from a successful upgrade indicates the following:

  • The formerly active SRP module has rebooted and come up as the new standby SRP module.
  • The newly active SRP module indicates that the formerly active SRP has rebooted and has come up as standby SRP module

You can then remove an SRP module after issuing the halt command.

Exceptions During the Upgrade Phase

Table 19 describes the behavior of the router during the upgrade phase when certain exceptional events take place outside the context of the unified in-service software upgrade.

Table 19: Router Response to Undesirable Events During the Upgrade Phase

Event

Router Action

The router reloads.

  • The unified ISSU operation halts.
  • The router undergoes a cold restart.
  • The router boots with the armed upgrade release.
  • The line modules reboot.

The primary SRP module switches over to the standby SRP module.

  • The unified ISSU operation halts.
  • The router undergoes a cold restart.
  • The router boots with the armed upgrade release.
  • The line modules reboot.

The standby SRP module reloads.

  • The unified ISSU operation halts.
  • The router undergoes a cold restart.
  • The router boots with the armed upgrade release.
  • The line modules reboot.

A line module reloads.

  • The line module is held down and prevented from rebooting until the service restoration phase is completed. The line module then undergoes a cold reboot to the running (post-upgrade) release.

An IOA is hotswapped.

  • Hot swapping is disabled during the upgrade phase. The line module undergoes a cold reboot and hot swapping is reenabled when the service restoration phase is completed,

An application that does not support unified ISSU is configured.

  • This event can take place only before the issu start command is issued, because that command disables CLI configuration commands. When you issue the issu start command, after configuring such an application, the command exits and generates an error message.

Verifications of Requirements

Because some time may have passed since unified ISSU verified the requirements for the upgrade during the initialization phase, unified ISSU reverifies all the same conditions.

Unified ISSU also verifies that no CLI configuration sessions are open, that no scripts or macros are running, and that any SNMP requests or CLI commands in progress complete within 5 seconds.

If any of the required conditions are not met, the CLI either exits the command with an error message or provides an informative message and prompts you to proceed or halt.

When all the conditions are met, the CLI prompts you to proceed. If you continue, then you can subsequently halt the upgrade only by reloading the router. If you exit the command, the router remains in the unified ISSU initialized state.

Upgrade Setup

At this stage all the preconditions have been met. The unified ISSU process shuts down all management interfaces to the router in order to prevent changes in the configuration.

Final preparation for the upgrade phase includes the following actions:

Line Module Arming

When the upgrade of the application data on the standby SRP upgrade is completed, unified ISSU temporarily arms the line modules with the upgrade release in a backup region of the memory.

Line Module Control Plane Upgrade

At this point, the upgrade release is preserved on each line module in some backup region. When signaled by the active SRP module, all supported line modules simultaneously reload and restart with the new release. Forwarding through the forwarding subsystem on the line modules—through the fabric of the system—is not affected by the reload.

The line modules then simultaneously recover any application data preserved in memory on the line module and upgrade that data into a format that the applications running on the new release can interpret. This operation can take in the range of 1–10 minutes depending on the size of the data and the upgrade path of the data. Each line module restores its operational state, running the new release with all data upgraded to a version acceptable to the new software.

If the upgrade process fails for any line module, that module undergoes a cold restart, but none of the other line modules is affected.

SRP Module Switchover

At this stage the primary SRP module is running the current release, the redundant SRP module is running the armed release, and the control plane on each supported line module is running the armed release.

When the primary SRP module has verified that all line modules are up, the redundant SRP module takes over control of the router by becoming the active SRP module. The primary, and formerly active, SRP module reboots to the armed release and serves as the standby SRP module.

All applications on the newly active SRP module are restarted. Each application reconstructs itself from the mirrored data, restoring its state and configuration as it was before the switchover. Forwarding through the fabric is interrupted for about 1 second on the E120 and E320 routers and about 4 seconds on the ERX1440 router.

The SRP switchover restarts the routing protocols and triggers a graceful restart because the routes need to be recomputed. This recalculation can take up to 90 seconds. Data continues to be forwarded through routes that were learned before the upgrade of the line module control planes.

Line Module Forwarding Plane Upgrade

While the applications on the SRP module and the line modules reconstruct themselves, they also begin to build up the new state for the forwarding subsystem. All applications on the line module signal the system when they are ready to start the forwarding upgrade.

Because upgrading the forwarding plane affects forwarding through the chassis for up to 30 seconds on the E120 and E320 routers and about 50 seconds on the ERX1440 router, unified ISSU does not proceed until the routing protocols have signaled that route reconvergence has completed. Unified ISSU then instructs all line modules to simultaneously upgrade their forwarding subsystems.

The line modules then perform the following steps:

  1. Halt forwarding through the line modules. Although any links to external devices remain up, incoming data is dropped.
  2. Update any changed programmable hardware devices.
  3. Update the forwarding subsystem with the new release and upgraded configuration data.
  4. Update the routing tables with the reconverged routes.
  5. Resume forwarding.

Related Documentation