12.7 Unified ISSU: Requirements and Verification

What Unified ISSU Adds

Unified in-service software upgrade (ISSU) coordinates a supported move between Junos releases while maintaining control-plane service and minimizing traffic disruption. An ordinary reboot upgrade restarts the device through a software change. GRES preserves kernel/forwarding state during an RE switchover; NSR preserves supported routing protocol state; NSB preserves supported Layer 2 control state. ISSU uses the appropriate mechanisms as part of a software-upgrade sequence, including compatibility checks and staged component changes.

These mechanisms solve related but different problems. A chassis can be ready for GRES yet run a release pair that does not support ISSU. A valid software package can be installable using a disruptive method while incompatible with an in-service upgrade. A device with one RE or a particular line card may have a different upgrade procedure entirely. Exam questions often test this dependency reasoning, rather than the ability to recite a single upgrade command.

Establish the Supported Upgrade Path

Before a maintenance action, identify the exact hardware and source/target versions, then consult the platform’s release notes and unified ISSU requirements. Check supported REs, line cards, software packages, protocol features and configuration restrictions. Confirm that the target is a supported step from the current release; do not assume two releases with familiar version numbers can be connected directly.

Use show version, show chassis hardware, show chassis alarms and applicable redundancy status views. Compare configuration synchronization and protocol readiness instead of treating a powered-on backup RE as ready. Check storage and package integrity through the platform’s supported workflow. Resolve an active alarm or unsynchronized standby before interpreting the system as safely redundant.

Validation Before Upgrade

On platforms supporting the unified ISSU command family, a separate validation command can detect compatibility issues before the upgrade action:

request system software validate in-service-upgrade /var/tmp/<supported-package>.tgz

This command illustrates a platform-dependent maintenance workflow; it is not an instruction to run it on an arbitrary switch. Read validation output and investigate incompatibilities. A failed validation is evidence to repair the plan, rather than a reason to bypass validation with a convenient option. Some platforms and software families use different commands or package formats, so the requirements determine the syntax.

For the documented command family, the upgrade action has this shape:

request system software in-service-upgrade /var/tmp/<supported-package>.tgz

The operation changes device software and can disrupt service. It should follow a reviewed maintenance plan with an appropriate fallback. A study guide can explain the sequence without claiming that this command has been tested on the reader’s hardware. Distinguish command syntax recognition from operational authorization and readiness.

Monitoring the Sequence

Monitor applicable upgrade status and logs during the operation. Determine which RE or component is active, which stage has completed and whether a reported condition is expected. An SSH session reconnecting does not prove the routing protocols or line cards recovered. Avoid issuing overlapping upgrades, reboots or switchovers simply because a stage takes longer than expected; use the documented status and recovery procedure for the current state.

Compare protocol observations with the baseline: OSPF and IS-IS adjacency counts, BGP session and route counts, STP port roles, LACP collecting/distributing state, VRRP ownership and BFD sessions. Do not assume NSR covers every enabled protocol on every release. If a timer is shorter than a supported interruption, a peer can still declare failure even though the local upgrade mechanism is working as designed.

Post-Upgrade Acceptance and Failure Analysis

Verify the intended version on all relevant components and that the backup is healthy and synchronized again. Check alarms, interface status, errors and forwarding-table installation. Send representative traffic through the real required paths, including large packets where MTU behavior matters. Compare sustained counters and protocol state with pre-upgrade observations; a single successful ping tests only a small part of the service.

If a validation fails because of an unsupported feature, choose a supported remediation or a planned disruptive upgrade instead of relabeling the task ISSU. If the upgrade reports completion but the backup remains unavailable, the service may be forwarding while redundancy is still degraded. Restore redundancy and verify it before declaring the maintenance complete.

Keep unified ISSU, platform-specific nonstop software upgrade (NSSU) and an ordinary reboot upgrade distinct. Similar names do not establish identical hardware requirements or interruption guarantees. The reliable exam answer states the desired outcome, required support and state-preservation dependencies, then selects the supported workflow.

Official references checked 2026-10-18: unified ISSU requirements, validation command, and upgrade command.