--- title: "During a Switch Upgrade, Forwarding Can Continue While Control Software Restarts" description: "Leviathan Systems — Technical content Published 2026-10-20; updated 2026-10-20." canonical: "https://www.leviathansystems.co/articles/switch-issu-control-plane-forwarding-scope" last-updated: "2026-10-20" --- # During a Switch Upgrade, Forwarding Can Continue While Control Software Restarts Leviathan Systems — Technical content Published 2026-10-20; updated 2026-10-20. An applicable in-service software upgrade, or ISSU, can preserve packet forwarding while control software restarts or changes over. That capability answers one continuity question. Continuous management access, response to a network change and completed application work require evidence at their own boundaries. Evaluate the exact supported hardware and software transition before deciding whether an offer meets the required outcome. ## Separate forwarding, control and management A switch upgrade offer becomes useful when it names the function expected to remain available. A packet crossing the switch, a routing decision changing and an operator accessing the device are different events. RFC 7426, an informational architecture taxonomy published in January 2015, distinguishes forwarding resources from control functions that determine packet treatment and update forwarding tables. It separately describes management functions for monitoring, configuration and maintenance. These functional distinctions help interpret an offer; they do not promise a particular switch implementation. A management session addresses an interface on the device. Transit traffic has a different destination and purpose. Losing that session therefore does not, by itself, show that transit packets stopped. Equally, forwarded traffic does not demonstrate that the operator could inspect or change the device throughout the interval. Ask which function the supplier's continuity claim actually covers. References: [R1](https://www.rfc-editor.org/rfc/rfc7426.html) ## Retained state can keep doing work while control recovers Retaining usable forwarding state can let it keep doing work while control software recovers. RFC 3746's April 2004 ForCES framework illustrates retained forwarding tables during a control-element graceful restart, with expiry of that retained state. This architectural example does not identify Cisco's implementation or promise indefinite forwarding. Consider a simplified lookup. Stipulate that an installed entry associates a destination with an output, that the output remains usable and that a packet needs only that existing treatment. Applying the entry requires no fresh control decision for that packet. If the required path or treatment changes, the system's ability to update that state becomes a separate question. Flow age does not settle the distinction. A new flow's packet might match a usable entry; an established flow might encounter a changed path. Neither all new flows fail nor all existing flows continue follows from control-plane restart. Ask what state and functions the actual packet needs. References: [R2](https://www.rfc-editor.org/rfc/rfc3746.html#section-4.3.1) ## Cisco describes different ways to preserve continuity Cisco's Nexus 9000 NX-OS 10.6(x) ISSU chapter, updated August 23, 2026, describes a standard-ISSU example for single-supervisor Top-of-Rack switches. The supervisor CPU resets, loads the new software, then restores configuration and runtime state in synchronization with the data plane. Cisco describes packet forwarding continuing during that process. Its enhanced-ISSU example uses Linux containers and a standby supervisor instance. The chapter specifies 16G memory and excludes enhanced ISSU when underlying kernels differ; it describes non-disruptive ISSU with control-plane impact instead. The distinction matters when comparing offers. Preserving forwarding during a control restart and maintaining control through a switchover describe different behavior. A claim about the former cannot silently answer a requirement for the latter. These dated Nexus examples also establish no ISSU capability for an arbitrary SONiC switch or another hardware/software combination. References: [C1](https://www.cisco.com/c/en/us/td/docs/dcn/nx-os/nexus9000/106x/upgrade/cisco-nexus-9000-series-nx-os-software-upgrade-and-downgrade-guide-106x/upgrade-or-downgrade-the-n9000-series-nx-os-software/in-service-software-upgrade.html) ## Apply support evidence to the offered transition A platform family name is too broad to settle applicability. In the same dated guide's platform-support page, Cisco states that standard ISSU is unsupported on N93180YC-FX3 and FX3S beginning with NX-OS 10.3(3)F. Its tables also qualify support by features and release-specific notes. A historical support-start entry cannot be read in isolation from later restrictions. The guide's Upgrade paths page directs readers to the particular release's release notes and Cisco's Upgrade and ISSU Matrix for release compatibility. Thus, an offer needs evidence connecting the exact running release to the exact proposed target. Showing that both releases exist or that the hardware belongs to a listed family does not establish support for that transition. Have the proposing network/software provider explain how the actual platform, selected upgrade type and enabled feature set fit that evidence. Include the network context needed to understand the claim: which devices and paths it covers, which surrounding functions it depends on, and which outcomes remain to be demonstrated. This article selects no supported transition for a customer and supplies no upgrade procedure. References: [C2](https://www.cisco.com/c/en/us/td/docs/dcn/nx-os/nexus9000/106x/upgrade/cisco-nexus-9000-series-nx-os-software-upgrade-and-downgrade-guide-106x/upgrade-or-downgrade-the-n9000-series-nx-os-software/issu-platform-support.html), [C3](https://www.cisco.com/c/en/us/td/docs/dcn/nx-os/nexus9000/106x/upgrade/cisco-nexus-9000-series-nx-os-software-upgrade-and-downgrade-guide-106x/upgrade-or-downgrade-the-n9000-series-nx-os-software/upgrade-paths.html) ## What six packets in twenty seconds establish Fictional interval IS-01 lasts 20 seconds. A management session is stipulated unavailable throughout. Packets A1, A2 and A3 are stipulated forwarded on one already-established path; B1, B2 and B3 are stipulated forwarded on a second already-established path. There is no observation of a new route event or a completed application request. These are invented premises, not a capture or an actual upgrade result. The premises demonstrate that forwarding those six packets and interruption of that management session can coexist. They do not identify why the session was unavailable. In particular, a management interruption is not itself a measurement of control-plane downtime. The six packets are the identified forwarding successes in this fiction, not an inventory of all traffic offered during the interval. Calling this universal 6/6 availability would invent coverage: the premises give no total traffic population, loss record or delay distribution. Nor does 20 seconds become an allowed outage or a product specification. There is also no evidence about the response to a new route event, because none is observed. And no completed application request is identified. The useful conclusion is limited but concrete: management access and some data forwarding had different stipulated outcomes. Whether the required application remained usable, or an actual upgrade completed successfully, remains unanswered. ## Make the offer answer the required outcome Consider two fictional offers. Offer A says zero-downtime ISSU but names no source release, target release, feature configuration or continuity boundary. Offer B identifies those inputs, cites applicable vendor support evidence and explains the forwarding, control and management behavior it proposes. B gives the buyer a defined claim to assess; its specificity is not proof that the required outcome has occurred. If the requirement is continuous management access, an explanation of retained forwarding does not close the comparison. The supplier needs to address the required management function. If the requirement concerns reaction to a topology change, evidence for an unchanged path leaves that behavior unresolved. If the requirement concerns completed application work, identify the operation, participating endpoints and relevant dependencies, then ask what evidence will address that outcome. This does not require turning every offer into a universal availability promise. It requires matching the claimed result to the result being bought. IS-01 could support the narrow statement that the identified packets forwarded despite the unavailable session. It could not close an application-continuity requirement. Likewise, applicable vendor ISSU support is a necessary basis for the proposed mechanism, while the buyer's network and application context determines what further evidence is relevant. ## Connect the software decision to the physical handoff Where a network lifecycle project includes physical cabling, Leviathan's structured cabling service can discuss routing, dressing, labeling and connection records for the approved assemblies and endpoints. The physical return helps the appointed network team identify the connections covered by its own operating decisions. Use the service and project-inquiry links below to share the approved endpoint and patching plan, routes, materials responsibilities, site constraints and required physical handoff. Identify the network/software owner receiving those records. Software-upgrade execution and application-continuity assessment remain with that appointed owner; a physical installation inquiry does not establish a Leviathan switch-software service. References: [L1](https://www.leviathansystems.co/services/structured-cabling) ## Primary sources - [R1 — RFC 7426: Software-Defined Networking—Layers and Architecture Terminology](https://www.rfc-editor.org/rfc/rfc7426.html). Checked 2026-10-20. January 2015 informational taxonomy, sections 2 and 3.1–3.4. Functional distinctions do not establish product behavior. - [R2 — RFC 3746: Forwarding and Control Element Separation (ForCES) Framework](https://www.rfc-editor.org/rfc/rfc3746.html#section-4.3.1). Checked 2026-10-20. April 2004 informational framework, section 4.3.1. Illustrates retained state and expiry; establishes no Nexus implementation or outage allowance. - [C1 — Cisco Nexus 9000 NX-OS 10.6(x): In-Service Software Upgrade](https://www.cisco.com/c/en/us/td/docs/dcn/nx-os/nexus9000/106x/upgrade/cisco-nexus-9000-series-nx-os-software-upgrade-and-downgrade-guide-106x/upgrade-or-downgrade-the-n9000-series-nx-os-software/in-service-software-upgrade.html). Checked 2026-10-20. Updated August 23, 2026. Standard/enhanced mechanisms, memory and kernel conditions; no timing guarantee adopted. - [C2 — Cisco Nexus 9000 NX-OS 10.6(x): ISSU platform support](https://www.cisco.com/c/en/us/td/docs/dcn/nx-os/nexus9000/106x/upgrade/cisco-nexus-9000-series-nx-os-software-upgrade-and-downgrade-guide-106x/upgrade-or-downgrade-the-n9000-series-nx-os-software/issu-platform-support.html). Checked 2026-10-20. Updated August 23, 2026. Platform, release and feature qualifications, including the stated FX3/FX3S standard-ISSU restriction; not a selected customer upgrade path. - [C3 — Cisco Nexus 9000 NX-OS 10.6(x): Upgrade paths](https://www.cisco.com/c/en/us/td/docs/dcn/nx-os/nexus9000/106x/upgrade/cisco-nexus-9000-series-nx-os-software-upgrade-and-downgrade-guide-106x/upgrade-or-downgrade-the-n9000-series-nx-os-software/upgrade-paths.html). Checked 2026-10-20. Updated August 23, 2026. Identifies release notes and the Upgrade and ISSU Matrix as compatibility references; no source-to-target transition is selected here. - [L1 — Leviathan Systems: Structured Cabling & Fiber Installation](https://www.leviathansystems.co/services/structured-cabling). Checked 2026-10-20. Physical routing, dressing, identification and connection-record scope for approved assemblies. Actual work, materials responsibilities and availability require the agreed engagement. ## Related Leviathan resources - [SONiC switch identity and physical handoff](/articles/sonic-switch-physical-installation-records) - [Hardware, software and operating support coverage](/articles/gpu-rack-support-coverage-handoff) - [Cut-through and store-and-forward latency boundaries](/articles/gpu-switch-cut-through-versus-store-and-forward-latency) - [Structured cabling for approved network connections](/services/structured-cabling) - [Discuss the physical connection and handoff scope](/contact?service=structured-cabling&from=/articles/switch-issu-control-plane-forwarding-scope) ## Define the physical connections and receiving network owner Share the approved endpoint plan, specified assemblies, routes, material responsibilities and required records to discuss physical cabling scope and availability. [Discuss the scope](/contact?service=structured-cabling&from=/articles/switch-issu-control-plane-forwarding-scope)