High-Availability FAQ: Minimizing MTTR and Configuring Redundancy in Core Switch ISSU

Overview & Thematic Scope

In-Service Software Upgrade (ISSU) allows a core switch to move to a new software release while forwarding traffic, avoiding maintenance windows and SLA penalties. This FAQ focuses on the high-availability mechanics of ISSU: control-plane and data-plane redundancy, hitless failover, MTTR reduction, and the pre-checks that determine whether an upgrade can truly be performed in service. It is written for network engineers, architects, and procurement teams evaluating core switches for carrier, ISP, and enterprise datacenter deployments.

Frequently Asked Questions

Q1: What is ISSU on a core switch and how does it avoid downtime?

ISSU (In-Service Software Upgrade) is a mechanism that upgrades switch software while the forwarding plane continues to pass traffic, using redundant control planes and synchronized forwarding state. The standby supervisor or routing engine is upgraded first, then a controlled switchover occurs, so no full reboot of the chassis is required. This is what enables zero-downtime or near-hitless upgrades on high-availability core switches.

Q2: What redundancy hardware and software prerequisites are required for ISSU?

ISSU requires dual supervisor engines or dual routing engines (or a redundant control-plane architecture), non-stop forwarding (NSF), graceful restart, and stateful switchover (SSO) support. Both supervisors must run compatible software versions and the same configuration, and the target release must support the ISSU path from the current release. Without these, the upgrade falls back to a disruptive reload.

Q3: How does ISSU minimize MTTR during a core switch software upgrade?

ISSU minimizes MTTR by eliminating the full reboot cycle: failover to the upgraded standby takes seconds instead of minutes, and forwarding entries, routing adjacencies, and link states are preserved. Because traffic interruption is limited to a sub-second or hitless switchover window, recovery time and service impact are dramatically lower than a traditional maintenance-window upgrade.

Q4: Which protocols and features must support graceful restart for hitless ISSU?

For truly hitless behavior, the control-plane protocols carrying your core routes and services must support graceful restart and non-stop forwarding. This typically includes BGP, OSPF, IS-IS, MPLS/LDP, and often VRRP/HSRP and LACP. Features that lack graceful restart, such as some stateful NAT or deep packet inspection modules, may still experience brief disruption during switchover.

Q5: What pre-upgrade checks are mandatory before running ISSU on a core switch?

Mandatory pre-checks include verifying ISSU compatibility between current and target releases, confirming sufficient flash and memory, validating dual-supervisor health, and taking configuration and software backups. You should also check that both supervisors are synchronized, that no hardware alarms exist, and that a tested rollback image is available. Skipping these checks is the most common cause of failed or disruptive ISSU attempts.

Q6: Can ISSU be rolled back if the new software fails after switchover?

Yes, most enterprise and carrier core switches support ISSU rollback, provided the previous image is still present and the rollback path is compatible. Rollback uses the same redundant control-plane mechanism, so it can also be performed in service. However, rollback must be planned and tested in advance, because some configuration or database changes made after upgrade may not be reversible.

Q7: How does ISSU affect BGP, OSPF and MPLS forwarding during switchover?

With graceful restart and NSF enabled, BGP, OSPF, and MPLS forwarding states remain intact during the supervisor switchover, so peers do not flap and labels are preserved. Neighbors continue to forward using the last known good state while the control plane restarts. If graceful restart is disabled or unsupported for a protocol, that protocol will reconverge and may cause temporary route withdrawal and traffic loss.

Q8: How do I reduce MTTR and validate success after an ISSU upgrade?

After ISSU, validate success by checking supervisor redundancy state, protocol adjacencies, forwarding table consistency, and interface counters against pre-upgrade baselines. Monitoring and alerting should confirm that no silent failures occurred during switchover. Documenting the ISSU runbook and rollback criteria reduces future MTTR, because the team can act on a known, tested procedure instead of diagnosing under pressure.