# 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:

- SNMP—The SNMP agent generates a juniSystemIssuStateChange trap with juniSystemIssuState set to upgrading to indicate that the final phase of the operation has begun. When the trap is issued with this state value, the SNMP agent stops accepting any new SNMP gets or sets and does not issue any further traps.
- CLI—Most CLI commands are disabled. Only reload, show issu, and show version commands are available to you until the service restoration phase completes. These commands are available on the console and are not available to Telnet sessions.
- External events—Externally created events from sources other than the CLI are ignored. These events typically come from user connections, RADIUS servers, SRC software and SDX software, and SNMP, and include login requests, COA requests, multicast join requests, packet mirroring requests, and so on. Logout requests are cached and processed at a later stage.
- Routing protocols—The unified ISSU process prompts you to consider raising the link costs for each routing protocol that is configured on the router. Raising the link cost for routes through the upgrading router enables neighbors to recompute better routes to those destinations. If you choose to raise the link cost, the higher costs can take some time to propagate through the network. Because the router is unable to determine when this has completed, it waits for 2 minutes before proceeding to the next step in the upgrade.

  The reason for raising the link cost is that when the upgrade of the line module control plane begins, routing protocol updates cannot be installed in the line modules until that upgrade completes. That period can be in the range 2–15 minutes. During the control plane upgrade, the routing protocols can still accept new routes and communicate with their neighbors but cannot install the routes.

- Unsupported line modules—Any unsupported line modules that are present are held down after the start of this phase when you can no longer gracefully exit from the unified ISSU process. The modules are held down for the duration of the unified in-service software upgrade and then undergo a cold boot to the original running release.
- IGMP requests—The router cannot handle IGMP requests for channel changing for IPTV implementations.

### 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

- Unified ISSU Phases Overview
- Halt of Unified ISSU During Upgrade Phase Overview
- Halting Unified ISSU During Upgrade Phase
- issu start
- show issu
- halt
- reload