cancel
Showing results forĀ 
Search instead forĀ 
Did you mean:Ā 
cancel
1149
Views
0
Helpful
3
Replies

NX-OS ISSU upgrade on N7k

anazarenko
Level 1
Level 1

At the moment i am running 6.2.2a. According to Cisco CCO, it's advised to use an interim release 6.2.8a towards the the final version 6.2.12 or 6.2.14. Is there any special reason behind this step?

Should i make the interim release 6.2.8a on both vPC peers before starting an update to the final one?

I tried to make an ISSU directly to 6.2.12 and it worked well in the LAB.

3 Replies 3

InayathUlla Sharieff
Cisco Employee
Cisco Employee

HI,

Table 6 Supported Direct ISSU and ISSD Paths for the Cisco Nexus 7000 Series Chassis

Current Release
Releases That Support Direct ISSU to the Current Release
ISSD

NX-OS Release 6.2(14)

6.2(12),6.2(10),6.2(8a),
6.2(8b)

No Support

Table 8 Multi-hop ISSU Paths

Starting Release
Intermediate Release
Destination Release

6.2(2), 6.2(2a), 6.2(6), 6.2(6a), 6.2(8)

6.2(8a)

6.2(12), 6.2(14)

6.1(3), 6.1(4), 6.1(4a), 6.1(5)

6.2(8a)

6.2(12), 6.2(14)

5.2(7), 5.2(9)

6.2(8a)

6.2(12), 6.2(14)

6.1(5a)

6.2(8b)

6.2(12), 6.2(14)

5.2(9a)

6.2(8b)

6.2(12), 6.2(14)

I saw this document. I am more interested to hear about reasons behind this Intermidiate release 6.2(8a). Maybe it's just some feature requires it, and if it's not enabled I can jump straight to 6.2(12).

 

REason:

Before the introduction of the ISSU capability, the SSO mode of operation required each RP to be running like versions of Cisco IOS software. The operating mode of the system in a redundant HA configuration is determined by exchanging version strings when the standby RP registers with the active RP.

The system entered SSO mode only if the versions running on the both RPs were the same. If not, the redundancy mode was reduced to ensure compatibility. With ISSU capability, the implementation allows two different but compatible release levels of Cisco IOS images to interoperate in SSO mode and enables software upgrades while packet forwarding continues. Version checking done before ISSU capability was introduced is no longer sufficient to allow the system to determine the operating mode.

ISSU requires additional information to determine compatibility between software versions. Therefore, a compatibility matrix is defined that contains information about other images with respect to the one in question. This compatibility matrix represents the compatibility of two software versions, one running on the active and the other on the standby RP, and to allow the system to determine the highest operating mode it can achieve. Incompatible versions will not be able to progress to SSO operational mode.

The Cisco IOS infrastructure has been internally modified and redesigned to accommodate subsystem versioning with ISSU. Cisco IOS subsystems correspond to feature sets and software component groupings. Features or subsystems that maintain state information across RPs are HA-aware or SSO clients. A mechanism called ISSU Framework, or ISSU protocol, allows subsystems within Cisco IOS software to communicate RP to RP and to negotiate the message version for communication between RPs. Internally, all NSF- and SSO-compliant applications or subsystems that are HA-aware must follow this protocol to establish communication with their peer across different versions of software. (For further information on operating modes, see the Stateful Switchover document.)

Compatibility Matrix

You can perform the ISSU process when the Cisco IOS software on both the active and the standby RP is capable of ISSU and the old and new images are compatible. The compatibility matrix information stores the compatibility among releases as follows:

ā€¢Compatibleā€”The base-level system infrastructure and all optional HA-aware subsystems are compatible. An in-service upgrade or downgrade between these versions will succeed with minimal service impact. The matrix entry designates the images to be compatible (C).

ā€¢Base-level compatibleā€”One or more of the optional HA-aware subsystems is not compatible. An in-service upgrade or downgrade between these versions will succeed; however, some subsystems will not be able to maintain state during the transition. The matrix entry designates the images to be base-level compatible (B).

ā€¢Incompatibleā€”A core set of system infrastructure exists that must be able to interoperate in a stateful manner for SSO to function correctly. If any of these required features or protocols is not interoperable, then the two versions of the Cisco IOS software images are declared to be incompatible. An in-service upgrade or downgrade between these versions is not possible. The matrix entry designates the images to be incompatible (I).

If you attempt to perform ISSU with a peer that does not support ISSU, the system automatically uses Fast Software Upgrade (FSU) instead.

The compatibility matrix represents the compatibility relationship a Cisco IOS software image has with all of the other Cisco IOS software versions within the designated support window (for example, all of those software versions the image "knows" about) and is populated and released with every image. The matrix stores compatibility information between its own release and prior releases. It is always the newest release that contains the latest information about compatibility with existing releases in the field. The compatibility matrix is available within the Cisco IOS software image and on Cisco.com so that users can determine in advance whether an upgrade can be done using the ISSU process.

Before attempting an ISSU, you should determine the compatibility level between the Cisco IOS software versions on the active and the standby RPs. To display the compatibility matrix data between two software versions on a given system, enter the show issu comp-matrix negotiated command.

Review Cisco Networking for a $25 gift card