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 that follow:

  • 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 master 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 master 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.

    Figure 1: Device Status Before Starting a Unified ISSU
    Device Status Before Starting
a Unified ISSU
  2. After the validation succeeds, the management process installs (copies) the new software image to the backup Routing Engine.
  3. The backup Routing Engine is rebooted.
  4. 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 master Routing Engine.
    Figure 2: Device Status After the Backup Routing Engine Is Upgraded
    Device Status After
the Backup Routing Engine Is Upgraded
  5. After the configuration file and the kernel state are synchronized to the backup Routing Engine, the chassis process (chassisd) on the master 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.
  6. 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
  7. 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 master Routing Engine.Note

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

  8. After all Packet Forwarding Engines have sent a READY message using the chassis process on the master 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.

  9. The Routing Engine switchover occurs, and the Routing Engine (re1) that was the backup now becomes the master Routing Engine.
    Figure 5: Device Status After the Routing Engine Switchover
    Device
Status After the Routing Engine Switchover
  10. 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
  11. 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 master Routing Engine of the TX Matrix router (global master) 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 master 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 master 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 master 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 master 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 master 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 master Routing Engine.
  13. The management process initiates Routing Engine switchover on the master 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 master Routing Engines. Then the chassis manager and Packet Forwarding Engine manager on the T640 router FRUs connect to the new master Routing Engines on the T640 routers.
  16. The management process on the global master Routing Engine initiates the upgrade process on the old master 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 masters on the T640 routers are upgraded, the management process initiates the upgrade of the Routing Engine that was previously the global master 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.

Understanding the Unified ISSU Process on the TX Matrix Plus Router and on the TX Matrix Plus Router with 3D SIBs

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

Note

A routing matrix is a multichassis architecture. In this topic, the term TX Matrix Plus router denotes a routing matrix based on a Juniper Networks TX Matrix Plus router and its connected T1600 LCCs. The term TX Matrix Plus router with 3D SIBs denotes a routing matrix based on a Juniper Networks TX Matrix Plus router and its connected T1600 and T4000 LCCs.

Each router has dual Routing Engines.

Unified ISSU Process on the TX Matrix Plus Router and on the TX Matrix Plus Router with 3D SIBs

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

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

    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.

  2. After successful validation of the configuration, the management process copies the new image to the backup Routing Engines on the TX Matrix Plus router and the connected T1600 router LCCs.
  3. The kernel synchronization process (ksyncd) on the backup Routing Engines synchronizes the kernels on the backup Routing Engines with the kernels on the master 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 master Routing Engine.
  5. 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.
  6. After receiving messages from the software processes indicating that the processes are ready for unified ISSU, the chassis process on the global master Routing Engine sends messages to the chassis process on the routers to start the unified ISSU.
  7. The chassis process on the routers sends ISSU_PREPARE messages to the field-replaceable units (FRUs), such as FPCs and intelligent PICs.
  8. 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.
  9. 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. The chassis process on each router, in turn, sends an ISSU_IN_PROGRESS message to the chassis process on the global master Routing Engine.
  10. After the unified ISSU reboot, the Packet Forwarding Engines restore the saved state information and connect back to the router. Then the chassis process on each router sends an ISSU_READY message to the chassis process on the global master Routing Engine. The CM_MSG_READY message (this message is sent from the LCC chassisd to the global master’s chassisd) indicates that the unified ISSU is complete on the FRUs.
  11. The unified ISSU control moves back to the management process on the global master Routing Engine.
  12. The management process initiates a Routing Engine switchover on the master Routing Engines.
  13. Routing Engine switchover occurs on the TX Matrix Plus router and all the connected LCCs.
  14. After the switchover, the FRUs connect to the new master Routing Engines, and the chassis manager and Packet Forwarding Engine manager on the connected LCC FRUs connect to the new master Routing Engines on the connected LCCs.
  15. The management process on the global master Routing Engine initiates the upgrade process on the Routing Engines that were previously the masters on the connected T1600 router LCCs. (This step is skipped if you have specified the no-old-master-upgrade option in the request system software in-service-upgrade command.)
  16. After the Routing Engines that were previously the masters on the connected T1600 router LCCs are upgraded, the management process initiates the upgrade of the Routing Engine that was previously the global master on the TX Matrix Plus router and all its connected LCCs.
  17. After a successful unified ISSU, the TX Matrix Plus global Routing Engine (re1) that was previously the master and is now the backup and the LCC Routing Engines that were previously the masters and are now the backups are rebooted if you specified the reboot option in the request system software in-service-upgrade command.