Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
ON THIS PAGE
 

Understanding Unified ISSU

Unified in-service software upgrade (ISSU) is a feature that minimizes traffic loss during the software upgrade process.

Getting Started with Unified In-Service Software Upgrade

The unified in-service software upgrade (ISSU) feature enables you to upgrade between two different Junos OS releases with no disruption on the control plane and with minimal disruption of traffic.

To quickly access the information you need, click on the link in Table 1.

Table 1: Locating the Information You Need to Work With ISSU

Task You Need to Perform

Where The Information Is Located

Verify unified ISSU support for your device

Unified ISSU System Requirements

Perform a unified ISSU

Example: Performing a Unified ISSU

Verify that the unified ISSU is successful

Verifying a Unified ISSU

Understand how the unified ISSU process works

Understanding the Unified ISSU Process

Unified ISSU takes advantage of the redundancy provided by dual Routing Engines and works in conjunction with the graceful Routing Engine switchover feature and the nonstop active routing feature.

Unified ISSU provides the following benefits:

  • Eliminates network downtime during software image upgrades

  • Reduces operating costs, while delivering higher service levels

  • Allows fast implementation of new features

See Also

Understanding the Unified ISSU Process

This topic explains the unified ISSU processes that take place on a router, on a TX Matrix router, on a TX Matrix Plus router and its connected line-card chassis (LCCs), as well as on a TX Matrix Plus router with 3D SIBs and its connected LCCs.

Understanding the Unified ISSU Process on a Router

This topic describes the processes that take place on a router with dual Routing Engines when you initiate a unified in-service software upgrade (ISSU).

Unified ISSU Process on a Router

After you use the request system software in-service-upgrade command, the following process occurs.

In Figure 1 through Figure 6 below:

  • A solid line indicates the high-speed internal link between a Routing Engine and a Packet Forwarding Engine.

  • A dotted line indicates the messages exchanged between the Packet Forwarding Engine and the chassis process (chassisd) on the Routing Engine.

  • RE0m and RE1b indicate primary and backup Routing Engines, respectively.

  • The check mark indicates that the device is running the new version of software.

Note:

Unified ISSU can only upgrade up to three major releases ahead of the current release on a device. To upgrade to a release more than three releases ahead of the current release on a device, use the unified ISSU process to upgrade the device to one or more intermediate releases until the device is within three major releases of the target release.

Note:

The following process pertains to all supported routing platforms except the TX Matrix router and TX Matrix Plus router. On most routers, the Packet Forwarding Engine resides on a Flexible PIC Concentrator (FPC). However, on an M120 router, the Forwarding Engine Board (FEB) replaces the functions of a Packet Forwarding Engine. In the illustrations and steps, when considering an M120 router, you can regard the Packet Forwarding Engine as an FPC. As an additional step on an M120 router, after the FPCs and PICs have been upgraded, the FEBs are upgraded.

  1. The primary Routing Engine validates the router configuration to ensure that it can be committed when you use the new software version.

    Checks are made for the following:

    • Disk space is available for the /var file system on both Routing Engines.

    • The configuration is supported by a unified ISSU.

    • The PICs are supported by a unified ISSU.

    • Graceful Routing Engine switchover is enabled.

    • Nonstop active routing is enabled.

    These checks are the same as the checks made when you enter the request system software validate in-service-upgrade command. If there is insufficient disk space available on either of the Routing Engines, the unified ISSU process fails and returns an error message. However, unsupported PICs do not prevent a unified ISSU. If there are unsupported PICs, the system issues a warning to indicate that these PICs will restart during the upgrade. Similarly, if there is an unsupported protocol configured, the system issues a warning that packet loss might occur for the unsupported protocol during the upgrade.

    Note:

    Starting in Junos OS Release 24.2R1, the primary Routing Engine will also run a check to see if the INDB has crashed. If an INDB crash is detected, the unified ISSU process will be cancelled.

  2. Figure 1: Device Status Before Starting a Unified ISSU Device Status Before Starting a Unified ISSU

  3. After the validation succeeds, the management process installs (copies) the new software image to the backup Routing Engine.

  4. The backup Routing Engine is rebooted.

  5. After the backup Routing Engine is rebooted and is running the new software, the kernel state synchronization process (ksyncd) synchronizes (copies) the configuration file and the kernel state from the primary Routing Engine.

    Figure 2: Device Status After the Backup Routing Engine Is Upgraded Device Status After the Backup Routing Engine Is Upgraded

  6. After the configuration file and the kernel state are synchronized to the backup Routing Engine, the chassis process (chassisd) on the primary Routing Engine prepares other software processes for the unified ISSU. The chassis process informs the various software processes (such as rpd, apsd, bfdd, and so on) about the unified ISSU and waits for responses from them. When all the processes are ready, the chassis process sends an ISSU_PREPARE message to the FPCs installed in the router. You can display the unified ISSU process messages by using the show log messages command.

  7. The Packet Forwarding Engine on each FPC saves its state and downloads the new software image from the backup Routing Engine. Next, each Packet Forwarding Engine sends an ISSU_READY message to the chassis process.

    Figure 3: Device Status After One Packet Forwarding Engine Downloads the New Software Device Status After One Packet Forwarding Engine Downloads the New Software

  8. After receiving an ISSU_READY message from a Packet Forwarding Engine, the chassis process sends an ISSU_REBOOT message to the FPC on which the Packet Forwarding Engine resides. The FPC reboots with the new software image. After the FPC is rebooted, the Packet Forwarding Engine restores the FPC state, and a high-speed internal link is established with the backup Routing Engine running the new software. The chassis process link is also reestablished with the primary Routing Engine.

    Note:

    The Packet Forwarding Engine reboots that occur during a unified ISSU are known as the "dark window". You can expect to see up to 2 seconds of traffic loss during this window of downtime.

  9. After all Packet Forwarding Engines have sent a READY message using the chassis process on the primary Routing Engine, other software processes are prepared for a Routing Engine switchover. The system is ready for a switchover at this point.

    Figure 4: Device Status Before the Routing Engine Switchover Device Status Before the Routing Engine Switchover
    Note:

    For M120 routers, the FEBs are upgraded at this point. When all FEBs have been upgraded, the system is ready for a switchover.

  10. The Routing Engine switchover occurs, and the Routing Engine (re1) that was the backup now becomes the primary Routing Engine.

    Figure 5: Device Status After the Routing Engine Switchover Device Status After the Routing Engine Switchover

  11. The new backup Routing Engine is now upgraded to the new software image. (This step is skipped if you have specified the no-old-master-upgrade option in the request system software in-service-upgrade command.)

    Figure 6: Device Status After the Unified ISSU Is Complete Device Status After the Unified ISSU Is Complete

  12. When the backup Routing Engine has been successfully upgraded, the unified ISSU is complete.

Understanding the Unified ISSU Process on the TX Matrix Router

This topic describes the processes that take place on a TX Matrix router when you initiate a unified in-service software upgrade (ISSU).

Unified ISSU Process on the TX Matrix Router

This section describes the processes that take place on a TX Matrix router and the routers acting as connected line-card chassis (LCCs).

Note:

A routing matrix is a multichassis architecture that consists of a TX Matrix router and from one to four T640 routers. From the perspective of the user interface, the routing matrix appears as a single router. The TX Matrix router controls all the T640 routers in the routing matrix.

Each router has dual Routing Engines.

After you use the request system software in-service-upgrade command on a TX Matrix router, the following process occurs:

  1. The management process (mgd) on the primary Routing Engine of the TX Matrix router (global primary) checks the current configuration.

    Checks are made for the following:

    • Disk space is available for the /var file system on all Routing Engines.

    • The configuration is supported by a unified ISSU.

    • The PICs are supported by a unified ISSU.

    • Graceful Routing Engine switchover is enabled.

    • Nonstop active routing is enabled.

  2. After successful validation of the configuration, the management process copies the new image to the backup Routing Engines on the TX Matrix router and the T640 routers.

  3. The kernel synchronization process (ksyncd) on the backup Routing Engines synchronizes the kernels on the backup Routing Engines with the kernels on the primary Routing Engines.

  4. The global backup Routing Engine is upgraded with the new software. Next the global backup Routing Engine is rebooted. Then the global backup Routing Engine synchronizes the configuration and kernel state from the global primary Routing Engine.

  5. The LCC backup Routing Engines are upgraded and rebooted. Then the LCC backup Routing Engines connect with the upgraded global backup Routing Engine and synchronize the configuration and kernel state.

  6. The unified ISSU control moves from the management process to the chassis process (chassisd). The chassis process informs the various software processes (such as rpd, apsd, bfdd, and so on) about the unified ISSU and waits for responses from them.

  7. After receiving messages from the software processes indicating that the processes are ready for unified ISSU, the chassis process on the global primary Routing Engine sends messages to the chassis process on the routing nodes to start the unified ISSU.

  8. The chassis process on the routing nodes sends ISSU_PREPARE messages to the field-replaceable units (FRUs), such as FPCs and intelligent PICs.

  9. After receiving an ISSU_PREPARE message, the Packet Forwarding Engines save the current state information and download the new software image from the backup Routing Engines. Next, each Packet Forwarding Engine sends ISSU_READY messages to the chassis process. You can display the unified ISSU process messages by using the show log messages command.

  10. After receiving an ISSU_READY message from the Packet Forwarding Engines, the chassis process sends an ISSU_REBOOT message to the FRUs. While the upgrade is in progress, the FRUs keep sending ISSU_IN_PROGRESS messages to the chassis process on the routing nodes. The chassis process on each routing node, in turn, sends an ISSU_IN_PROGRESS message to the chassis process on the global primary Routing Engine.

    Note:

    The Packet Forwarding Engine reboots that occur during a unified ISSU are designed to have a very short window of down time.

  11. After the unified ISSU reboot, the Packet Forwarding Engines restore the saved state information and connect back to the routing nodes. The chassis process on each routing node sends an ISSU_READY message to the chassis process on the global primary Routing Engine. The CM_MSG_READY message from the chassis process on the routing nodes indicate that the unified ISSU is complete on the FRUs.

  12. The unified ISSU control moves back to the management process on the global primary Routing Engine.

  13. The management process initiates Routing Engine switchover on the primary Routing Engines.

  14. Routing Engine switchover occurs on the TX Matrix router and the T640 routers.

  15. After the switchover, the FRUs connect to the new primary Routing Engines. Then the chassis manager and Packet Forwarding Engine manager on the T640 router FRUs connect to the new primary Routing Engines on the T640 routers.

  16. The management process on the global primary Routing Engine initiates the upgrade process on the old primary Routing Engines on the T640 routers. (This step is skipped if you have specified the no-old-master-upgrade option in the request system software in-service-upgrade command.)

  17. After the Routing Engines that were previously the primaries on the T640 routers are upgraded, the management process initiates the upgrade of the Routing Engine that was previously the global primary on the TX Matrix router.

  18. After a successful unified ISSU, the TX Matrix router and the T640 routers are rebooted if you specified the reboot option in the request system software in-service-upgrade command.

See Also

Understanding In-Service Software Upgrade (ISSU)

An in-service software upgrade (ISSU) enables you to upgrade between two different Junos OS releases with minimal disruption on the control plane and with minimal disruption of traffic. During an ISSU, the Junos OS runs in two separate virtual machines (VMs)—one VM is in the primary role acting as the primary Routing Engine, and the other VM is in the backup role acting as the backup Routing Engine. The Junos OS is upgraded on the backup VM. After a successful software upgrade, the backup VM then becomes the primary VM, and the original primary VM is no longer needed and is shut down.

ISSU provides the following benefits:

  • Eliminates network downtime during software image upgrades

  • Reduces operating costs, while delivering higher service levels

  • Allows fast implementation of new features

In-Service Software Upgrade Process

When you request an ISSU on a standalone device:

  1. The management process (mgd) verifies that non-stop routing (NSR), graceful Routing Engine switchover (GRES), and non-stop bridging (NSB) are enabled.

  2. The switch downloads and validates the software package.

  3. The ISSU state machine spawns the backup Routing Engine (RE) with the newer software.

  4. The ISSU state machine checks to see if the backup RE has synchronized all of the data with the primary RE.

  5. The ISSU state machine moves the devices (for example, forwarding ASIC, FPGA, management port and serial console) from the primary RE to the backup RE.

  6. The primary role is switched between the REs, so the backup RE becomes the primary RE.

  7. The old primary RE is shut down.

See Also

Understanding In-Service Software Upgrade (ISSU) in ACX5000 Series Routers

An in-service software upgrade (ISSU) enables you to upgrade between two different Junos OS releases with minimal disruption on the control plane and with minimal disruption of traffic. During an ISSU, the Junos OS runs in two separate virtual machines (VMs)—one VM is in the primary role acting as the primary Routing Engine, and the other VM is in the backup role acting as the backup Routing Engine. The Junos OS is upgraded on the backup VM. After a successful software upgrade, the backup VM then becomes the primary VM, and the original primary VM is no longer needed and is shut down.

Note:

ISSU is supported in Junos OS Release 15.1X54–D60 or later for ACX5000 Series routers.

ISSU provides the following benefits:

  • Eliminates network downtime during software image upgrades

  • Reduces operating costs, while delivering higher service levels

  • Allows fast implementation of new features

In-Service Software Upgrade Process

When you request an ISSU on a standalone device:

  1. The management process (mgd) verifies that non-stop routing (NSR), graceful Routing Engine switchover (GRES), and non-stop bridging (NSB) are enabled.

  2. The router downloads and validates the software package.

  3. The ISSU state machine spawns the backup Routing Engine (RE) with the newer software.

  4. The ISSU state machine checks to see if the backup RE has synchronized all of the data with the primary RE.

  5. The ISSU state machine moves the devices (for example, forwarding ASIC, FPGA, management port and serial console) from the primary RE to the backup RE.

  6. The primary role is switched between the REs, so the backup RE becomes the primary RE.

  7. The old primary RE is shut down.