Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

Guide That Contains This Content
[+] Expand All
[-] Collapse All

    Unified ISSU Overview

    In software releases numbered lower than Release 6.0, all line modules are reloaded when an SRP switchover occurs. This reload disconnects user sessions and disrupts forwarding through the chassis. Stateful SRP switchover was introduced in JunosE Release 6.0 to minimize the impact to the router of a stateful switchover from the active SRP module to the standby SRP module. Stateful SRP switchover (high availability) maintains user sessions during the switchover and data forwarding through the router continues to flow with little impact, thus improving the overall availability of the router.

    The unified in-service software upgrade (unified ISSU) feature further extends router availability. Unified ISSU enables you to upgrade the router to a higher-numbered software release without disconnecting user sessions or disrupting forwarding through the chassis.

    A conventional software upgrade—one that does not use the unified ISSU process—causes a router-wide outage for all users. Only static configurations (stored on the flash card) are maintained across the upgrade; all dynamic configurations are lost. A conventional upgrade takes 30-40 minutes to complete, with additional time required to bring all users back online.

    When you perform a unified in-service software upgrade on a router that has one or more modules that do not support unified ISSU, these modules alone are upgraded by means of the legacy, conventional upgrade process. The unsupported modules undergo a cold reboot at the beginning of the unified ISSU process, and are held down until the in-service software upgrade is completed. Connections that pass through the unsupported modules are lost. The interfaces on these modules pass into a down state, which causes the physical layer and link layer to go down during the unified in-service software upgrade for those modules.

    Applications that do not support unified ISSU applications cannot maintain state and configuration with minimal traffic loss across the upgrade to a higher-numbered release. When you attempt a unified in-service software upgrade on a router on which a unified ISSU-challenged application is configured, the unified in-service software upgrade cannot proceed. You must unconfigure the unified ISSU-challenged application to successfully perform the unified ISSU.

    Router Behavior During a Unified In-Service Software Upgrade

    The following behaviors are characteristic of a unified in-service software upgrade.

    • Connections that were established before you begin the unified ISSU are maintained across the upgrade. Any such connection that was forwarding data continues to do so during and after the upgrade.
    • New connections are denied until the upgrade is completed.
    • Packet loss during the upgrade is limited. Bandwidth through the modules is reduced, but the impact is minimal.
    • Graceful restart protocols do not time out during the unified ISSU.
    • The unified in-service software upgrade has a minimal effect on the control and data planes. During the SRP module upgrade phase, forwarding through the fabric is interrupted for about 1 second on the E120 and E320 routers and about 4 seconds on the ERX1440 Broadband Services Router. During the line module upgrade phase, forwarding through the chassis is interrupted for about 15 seconds on the E120 and E320 routers and for about 50 seconds on the ERX1440 router.
    • Diagnostic software is not run on any modules during a unified in-service software upgrade.
    • The router undergoes a cold restart if you attempt to upgrade the software to a lower-numbered version with unified ISSU. The unified in-service software upgrade must be to a higher-numbered release than the running release.
    • Additional memory is consumed during a unified in-service software upgrade. Available memory on a line module might not be sufficient due to the module’s configuration. Unified ISSU can detect this limitation during the upgrade procedure and exit the process, gracefully.
    • During the unified ISSU process, with a high availability line-module pair configured on a router, the primary line module supports unified ISSU. In such a scenario, the secondary line module is disabled when unified ISSU is performed and is cold booted after the unified ISSU procedure is complete. High availability mode is reactivated after the secondary line module comes back online, if the line module HA configuration continues to remain enabled on the secondary module. For more information about how the stateful line module switchover functionality behaves during a unified ISSU process, see Unresolved xref.

    Published: 2014-08-12