The Cisco NX-OS in-service software upgrade (ISSU) service allows you to upgrade Cisco Nexus device software while the switch continues to operate and forward traffic. The ISSU reduces or eliminates the downtime typically caused by software upgrades. The default upgrade process is disruptive, so the ISSU needs to be enabled using the CLI. Use of the nondisruptive option helps ensure a nondisruptive upgrade. The guest shell is disabled during the ISSU process and then reactivated after the upgrade.
When you perform an ISSU process, some Layer 2 and Layer 3 protocols will extend their values to accommodate the upgrade. For example, Unidirectional Link Detection (UDLD) and Bidirectional Forwarding Detection (BFD) will increase their hello timers so that adjacency is maintained during the ISSU process. Also, Border Gateway Protocol (BGP), Open Shortest Path First (OSPF), Intermediate System-to-Intermediate System (IS-IS), and Enhanced Interior Gateway Routing Protocol (EIGRP) perform a graceful restart. Because an allocated time is needed for the ISSU to successfully complete, aggressive timers are not supported for any Layer 2 and Layer 3 protocols. For example, a Link Aggregation Control Protocol (LACP) fast timer or an OSPF fast timer is not supported. For Layer 2 and Layer 3 protocols with sensitive timers, the timeout value should be increased. For applications for which you cannot increase the timeout value, the upgrade will be disruptive. Different Nexus hardware platforms have different ISSU results. Here, we discuss the Nexus 5000, Nexus 7000, and Nexus 9000 ISSU:
Nexus 9000 ISSU: The Cisco Nexus 9500 Platform switches are modular switches that are similar to Nexus 7000 switches; they require two supervisors. The minimum configuration required is two system controllers and two fabric modules.
Modular Cisco Nexus 9000 Series switches support parallel upgrades as the default method. The parallel method upgrades the modules in batches instead of one after the other for a faster upgrade. In the upgrade sequence, first the supervisors are upgraded (requires a switchover), then the line cards, fabric modules, system controllers, and the Fabric Extender (FEX). After switchover is performed in a parallel upgrade, the secondary supervisor takes over, and the installer determines the current line cards and fabric modules. It then divides the components into buckets. It places the first half of the line cards in the first bucket, the first half of the fabric modules in the second bucket, the second half of line cards in the third bucket, the second half of the fabric modules in the fourth bucket, the first system controller in the fifth bucket, and the second system controller in the sixth bucket (see Figure 6-5). Each bucket is upgraded successfully before the upgrade process starts for the next bucket. The console shows which modules are assigned to which bucket and status of the upgrade. You have the option to choose a serial upgrade using the CLI.
Figure 6-5 Nexus 9500 Parallel Upgrade Process
Cisco Nexus 9300 Series Switches are standalone switches with single supervisors. The ISSU on the Cisco Nexus 9300 Series switches causes the supervisor CPU to reset and load the new software version. The control plane is inactive during this time, but the data plane keeps forwarding packets leading to an upgrade with no service disruption. After the CPU loads the updated version of NX-OS, the system restores the control plane to a previous known configuration and runtime state and gets in-sync with the data plane, thereby completing the ISSU process. Because the data plane keeps forwarding packets while the control plane is upgraded, any servers connected to the Cisco Nexus 9300 Series switch access layer should see no traffic disruption.
When an upgrade is performed, the control plane is reset. This reset causes spanning tree to time out to its neighboring devices, which results in a spanning tree topology change. In addition, if the switch undergoing the ISSU is the spanning tree root, it might not be able to send bridge protocol data units (BPDUs) during the ISSU process. If there are downstream switches connected to devices undergoing the ISSU, as a best practice, you should use a vPC design for the ISSU. The vPC offers the advantage of running even if the two vPC peer devices operate with different NX-OS releases. During the transition phase, the vPC continues to work even if the peer devices use different NX-OS code. A configuration lock during the ISSU prevents synchronous upgrades on both vPC peer devices simultaneously (configuration is automatically locked on the other vPC peer device when the ISSU is initiated). This feature enables support for a nondisruptive upgrade for the vPC domain.
When the spanning tree primary switch undergoes the ISSU, it notifies the spanning tree secondary switch so that it can tune its spanning tree timers. If the switches are spanning tree root switches, the peer switch should be enabled. The peer switch allows both devices to share a common bridge ID when sending BPDUs. Because the peer switch is enabled, the spanning tree secondary switch continues to send BDPUs to its connected devices to avoid a spanning tree topology change while the spanning tree primary switch undergoes the ISSU.
