Introduction

Cisco Networking Software—Cisco IOS Software, Cisco IOS XE Software, and Cisco IOS XR Software, collectively referred to as Cisco IOS Software in this guide, and Cisco NX-OS Software—continue to evolve to meet the rapidly changing requirements of the most demanding enterprise and service provider networks. To meet these requirements, Cisco has implemented software release models and practices that supplement the support provided directly by the software. This guide provides an overview of the release models and practices for the current, primary Cisco IOS Software and Cisco NX-OS Software releases, including the various release families and trains, release-naming conventions, packaging architectures, and image-naming conventions. This guide also provides an overview of the software lifecycle and examples of migration paths for common migration scenarios.

Software Release Families and Trains

To better meet the requirements of different market segments, Cisco IOS Software and Cisco NX-OS Software releases are organized into software release families and trains. A software release family is software that shares a code base, applies to related hardware platforms, and has some overlap in the timeframe when it is actively supported. Each software release family consists of one or more trains. A train provides a vehicle for delivering software with a specific set of features to a specific set of platforms. As such, it consists of individual software releases. For example, Cisco IOS Software Release 15.6(3)M is a release from the Cisco IOS Software Release 15M&T train. Because different software release families can apply to different platforms or market segments, several trains can be current at any point in time. For example, the Cisco IOS Software Release 15SY train coexists with the Cisco IOS Software Release 15M&T train. Each train has a corresponding latest release that incorporates the latest features and hardware support for the platforms on which it runs.

To expedite availability of new hardware support, a software release family may include a short-lived release train, which is a train that branches from a longer-term train. For example, the Cisco IOS Software Release 15.1GC train was a short-lived train that included current features from the Cisco IOS Software Release 15M&T train and introduced support for Cisco 5940 Embedded Services Routers. Starting with Release 15.4(3)M&T, support for Cisco 5940 Embedded Services Routers was integrated into the Cisco IOS Software Release 15M&T train, which rendered subsequent, additional releases from the Release 15.1GC train unnecessary.

Provides Cisco IOS Software functionality and hardware support for enterprise, access, and commercial networks. This software release family incorporates hardware support and software features that were introduced in the Cisco IOS Software 12.4T and 12.4 Mainline trains.

15E

Provides Cisco IOS Software functionality in a converged release train that is designed primarily for Cisco Catalyst Switches and Cisco Industrial Ethernet Switches.

15S

Provides Cisco IOS Software functionality and hardware support for routers that were designed primarily for service providers, such as Cisco 7200 Series Routers, Cisco 7300 Series Routers, and Cisco 7600 Series Routers.

15SY

Provides Cisco IOS Software functionality and hardware support for Cisco Catalyst 6500 Series Switches running Supervisor Engine 2T and later models. This train is designed primarily for enterprise campus distribution and core applications. The first release in this train, Release 15.0SY, inherits hardware-enabled services from Cisco IOS Software Release 12.2(50)SY.

15 Special and Early Deployments

Provides Cisco IOS Software functionality and hardware support for emerging platforms and features. These trains are intended to be short-lived and ultimately integrated into the 15M&T train.

Provides an open and flexible operating system that is optimized for a new era of enterprise networks. The software provides standards-based programmable interfaces that automate network operations and enable deep visibility into user, application, and device behavior. In addition, it reduces business and network complexity by providing a single operating system for enterprise wired and wireless access, aggregation, core, and WAN. New services can be qualified and deployed faster.

This software release family uses a cross-platform integrated model and is the result of merging the Cisco IOS XE Software Release 3E and 3S trains.

Provides Cisco IOS XE Software functionality that is optimized for compact routers at the network edge, delivering in-service software upgrades and software redundancy in a form factor that is much smaller than was previously possible. The software also provides Cisco IOS command-line control to provide a familiar look and feel for Cisco IOS Software users, and it includes the ability to restart processes individually, with emphasis on fault-management features and in-service software upgrades.

Provides a modular and fully distributed network operating system that is designed to address the terabit scaling, secure virtualization, high availability, and distributed processing requirements of large, next-generation, service provider networks. The software is based on a microkernel that supports preemptive multitasking and memory protection. The software also provides Cisco IOS command-line control to provide a familiar look and feel for Cisco IOS Software users.

Provides an extensible, open, and programmable operating system that is built to meet the demands of both physical and virtual data center deployments. The software delivers critical features, such as a modular and flexible architecture, continuous system availability, switch virtualization capabilities, network automation, and programmatic provisioning and configuration of switches via comprehensive APIs. Based on the industry-proven Cisco SAN-OS Software, Cisco NX-OS Software helps ensure continuous availability and sets the standard for mission-critical data center environments.

This software release family primarily supports the Cisco Nexus family of products and the Cisco MDS family of products. The software is available and runs in either of two modes, standalone mode or Application Centric Infrastructure (ACI) mode. ACI mode is designed and optimized for use with Cisco Application Policy Infrastructure Controllers (APICs).

Common Hardware Families and Platforms

Software selection depends on a number of factors, including hardware and software feature requirements, the status of applicable trains and releases in the software lifecycle, and outstanding caveats. The following sections correlate the most common Cisco hardware families and platforms to the primary software release families and trains for Cisco IOS Software and Cisco NX-OS Software. For guidance on selecting software that meets specific requirements, use the Cisco Feature Navigator or the Software Center on Cisco.com (registered customers only).

Cisco IOS Software

The following table (Table 2) identifies common Cisco hardware platforms, organized by hardware family, and the primary Cisco IOS Software trains that support each platform:

Cisco IOS XE Software

The following table (Table 3) identifies common Cisco hardware platforms, organized by hardware family, and the primary Cisco IOS XE Software trains that support each platform. Note that support for a specific platform by a Cisco IOS XE Software Release 16 train may be available in only specific releases from that train—for example, Denali 16.1, Everest 16.4, or Fuji 16.7. To verify support for a specific platform, see the release notes for the platform.

Release Naming

To effectively manage Cisco IOS Software and Cisco NX-OS Software in a network environment, it is important to understand the release models and release-naming conventions for the various software release families, trains, and individual releases. The following sections explain the naming conventions and relevant relationships for releases from the Cisco IOS Software Release 15 trains and the current, primary trains for Cisco IOS XE, IOS XR, and NX-OS Software.

For information about the naming conventions for individual software images from these trains, see the Software Image Naming section of this guide.

Cisco IOS Software

The name of each release in the Cisco IOS Software Release 15 family contains various components that indicate key aspects of the release, such as which train the release derives from, whether the release contains new features, and the scope of changes and fixes to the software. Therefore, to understand the release-naming conventions for the Cisco IOS Software Release 15 family, it helps to also understand the release models for the Cisco IOS Software Release 15 trains, especially the Cisco IOS Software Release 15M&T train.

The Cisco IOS Software Release 15M&T train uses a release model that is different from the model that was used for previous Cisco IOS Software releases. For all releases prior to Cisco IOS Software Release 15.6(3)M, the 15M&T train does not diverge into separate trains for extended maintenance releases, referred to as M releases, and standard maintenance releases, referred to as T releases. Instead, it is a single train that delivers both types of maintenance releases according to a specific release sequence. For example, an early release from the Cisco IOS Software Release 15M&T train is Release 15.0(1)M, where M indicates that the release is an extended maintenance release. A subsequent release from the 15M&T train is Release 15.1(1)T, where T indicates that the release is a standard maintenance release. Figure 1 illustrates the relationship between extended (M) and standard (T) maintenance releases for all releases from the Cisco IOS Software Release 15M&T train prior to Release 15.6(3)M.

In this release model, a standard maintenance (T) release incorporates the latest features and hardware support, and it provides rebuilds for 18 months after the initial software release. An extended maintenance (M) release incorporates all the features and hardware support of all the preceding standard maintenance (T) releases in the train, but it is optimized for long-term maintenance because it provides rebuilds for 44 months after the initial software release. Each rebuild integrates fixes for high-severity issues that exist in an individual release and should be addressed on an accelerated schedule. A rebuild typically includes fixes for a limited number of issues, which reduces the potential impact on customers who have already certified and deployed a release. Figure 2 illustrates the code-based relationship between the different types of releases, including rebuilds, for all releases from the 15M&T train prior to Release 15.6(3)M.

Starting with Cisco IOS Software Release 15.6(3)M, the Cisco IOS Software Release 15M&T train uses a more simplified release model that eliminates standard maintenance (T) releases and provides only extended maintenance (M) releases, typically one extended maintenance release each year for the first 36 months after the initial software release. It also provides rebuilds to integrate new features and bug fixes, including fixes for security vulnerabilities and issues.

Each extended maintenance release provides rebuilds for 54 months after the initial software release. The first two rebuilds—for example, 15.6(3)M1 and 15.6(3)M2—integrate bug fixes and optionally introduce new features. If a subsequent rebuild is released less than 36 months after the initial software release, the rebuild integrates bug fixes only. If a subsequent rebuild is released 36–54 months after the initial software release, the rebuild integrates fixes only for security vulnerabilities and issues. Figure 3 illustrates the relationship between releases from the Cisco IOS Software Release 15M&T train for Releases 15.6(3)M and later, using Releases 15.6(3)M, 15.7(3)M, and 15.8(3)M as an example.

Figure 3. Relationship Between Releases from the Cisco IOS Software Release 15M&T Train—Releases 15.6(3)M and Later

In the preceding example (Figure 3), Release 15.6(3)M is the first release in the release sequence. The second extended maintenance release is Release 15.7(3)M, which is released 12 months after Release 15.6(3)M. The third extended maintenance release is Release 15.8(3)M, which is released 24 months after Release 15.6(3)M. The first three rebuilds (M1, M2, and M3) of each extended maintenance release are released with a four-month interval between each release. The first rebuild (M1) integrates new features and bug fixes. The second rebuild (M2) also integrates new features and bug fixes. The third rebuild (M3) integrates only bug fixes. All the remaining rebuilds are released with a six-month interval between each release. Rebuilds M4 through M7 integrate only bug fixes. Rebuilds M8 through M10, which are the last three rebuilds for the release, integrate fixes only for security vulnerabilities and issues.

To help administrators determine the release type of a specific software release, the release-naming conventions for Cisco IOS Software include uppercase letters that indicate whether a release is an extended (M) or standard (T) maintenance release. The conventions also include components that indicate other relevant characteristics of the release. Figure 4 outlines the components of release names for the Cisco IOS Software Release 15M&T train.

Minor release number: Increases by an increment of 1 for each release that introduces significant changes to the software, support for new hardware platforms, and enhancements and bug fixes for existing features and functions.

Feature release number: Increases by an increment of 1 for each release that introduces new features or functions. The number resets to 0 for each new minor release.

Maintenance rebuild number: Indicates whether the release is a rebuild and, if present, which rebuild it is. This number typically increases by an increment of 1 for each new rebuild. For example, and continuing with the examples in Figure 4, Cisco IOS Software Release 15.0(1)M1 is the first rebuild of Release 15.0(1)M and Cisco IOS Software Release 15.1(1)T2 is the second rebuild of Release 15.1(1)T.

The release-naming conventions for releases from other Cisco IOS Software Release 15 trains—15E, 15S, 15SE, 15SG, and 15SY—are similar to those for the 15M&T train. The release names start with a main release number, followed by major and minor feature release numbers, a release train identifier, and a maintenance rebuild number. Figure 5 shows how these components comprise a release name, using the first maintenance rebuild of Cisco IOS Software Release 15.0(1)SY release as an example.

Major feature release number: Increases by an increment of 1 for each release that introduces significant changes to the software, support for new hardware platforms, and enhancements and bug fixes for existing features and functions. The number resets to 1 with each new extended maintenance release.

Minor feature release number: Increases by an increment of 1 for each release that introduces new features or functions. The number resets to 1 for each new major feature release.

Train identifier: Indicates the applicable software train.

Maintenance rebuild number: Indicates whether the release is a maintenance rebuild that integrates bug fixes for a limited number of high-severity issues and, if present, which rebuild it is. For example, and continuing with the example in Figure 5, the release is the first rebuild of Release 15.0(1)SY. This number typically increases by an increment of 1 for each new rebuild. Note that some rebuilds may use a different naming convention—a lowercase letter after the minor feature release number or the maintenance rebuild number. For example, Cisco IOS Software Release 15.2(2)E received fixes for a few defects and the resulting rebuild was named 15.2(2a)E. Similarly, Release 15.2(2)E5 received a single fix for a significant defect and the resulting rebuild was named Release 15.2(2)E5a.

Cisco IOS XE Software

Cisco IOS XE Software releases contain many components—for example, the Cisco IOS daemon (IOSd), Interface Manager, Forwarding Manager, and Chassis Manager—that are packaged together and delivered as a single release. To reflect this architecture and help administrators manage the software in their network environments, the names of Cisco IOS XE Software releases adhere to a cohesive set of naming conventions that apply to the overall collection of components in a release.

The naming conventions also define identifiers that indicate the version and type of a release and the scope of the changes to the software. These identifiers derive primarily from a fixed, time-based release schedule for Cisco IOS XE Software. The schedule specifies three individual software releases at four-month intervals within a 12-month cycle—typically March, July, and November of each calendar year. The March and November releases are short-lived and ultimately integrated into the July release.

Within that time-based framework, each Cisco IOS XE Software release is classified as a standard maintenance (SM) release, also referred to as a standard-support release, or an extended maintenance (EM) release, also referred to as an extended-support release. A standard maintenance release has a sustaining support lifetime of one year from the first customer shipment (FCS) date, with two scheduled rebuilds that are typically released at an eight-week interval and a 10-week interval after the FCS date for the release. An extended maintenance release provides a sustaining support lifetime of two years from the FCS date, with four scheduled rebuilds during that lifetime. The first two rebuilds are released at an eight-week interval and a 10-week interval after the FCS date for the release. The second two rebuilds are released at 16-week intervals thereafter. For more information about the release types and timelines for Cisco IOS XE Software, see Cisco IOS XE Software Support Timeline.

Note: Starting with Cisco IOS XE Software Release Fuji 16.9, the release interval for extended maintenance releases changes from every 48 months to every 36 months. Consequently, Release 16.9 and each subsequent, third EM release, such as 16.12 and 16.15, is released at a 36-month interval with seven scheduled rebuilds. The rebuilds are sequentially released at varying intervals after the FCS date for the extended maintenance release, as follows: first rebuild, three months; second rebuild, four months; third rebuild, four months; fourth rebuild, seven months; fifth rebuild, six months; sixth rebuild, six months; and seventh rebuild, six months. The release interval for standard maintenance releases continues to be every 12 months, with two scheduled rebuilds that are typically released at six-month intervals. For more information, see the Cisco IOS XE Software Support Timeline for Cisco IOS XE Software Release Starting with 16.x.x Product Bulletin.

The release-naming conventions for the current, primary Cisco IOS XE Software release trains include components that map to and identify the version and type of each software release. However, there are currently two sets of release-naming conventions, one for the Cisco IOS XE Software Release 16 trains and another for the 3E, 3S, 3SE, 3SG, and 3SP trains. Figure 6 outlines the components of release names for the Cisco IOS XE Software Release 16 trains, using a release from the Everest 16.5 train as an example.

Major release number: Indicates the applicable software release family—for example, 16 for a release from a Denali, Everest, or Fuji train.

Release version number: Increases by an increment of 1 for each release that introduces significant changes to the software, support for new hardware platforms, and enhancements and bug fixes for existing features and functions. For example, the March 2017 release is Release 16.5.1, the July 2017 release is Release 16.6.1, and the November 2017 release is Release 16.7.1. This number also indicates whether a release is a standard or extended maintenance release, based on the time-based release cadence for the software.

Rebuild number: Increases by an increment of 1 for each release that integrates fixes for high-severity issues that exist in an individual release and should be addressed on an accelerated schedule. The numbering starts with 1. For example, there is no Release 16.5.0. Instead, Release 16.5.1 is the first release from the Everest 16.5 train, and the first rebuild of Release 16.5.1 is Release 16.5.2.

Optional special release identifier: Indicates whether the release is a special release that provides support for a specific hardware platform or integrates fixes for a select set of defects and, if present, which special release it is. This value increases by an increment of one lowercase, English alphabetical letter for each special release. A special release typically provides support for a hardware platform that was not available when the applicable major release version was released, or it integrates fixes for critical defects or security vulnerabilities that should be addressed on an accelerated schedule.

The release-naming conventions for releases from the Cisco IOS XE Software 3E, 3S, 3SE, 3SG, and 3SP trains are very similar to those for releases from the Cisco IOS XE Software Release 16 trains. They include a train identifier, a major release number, and release version and rebuild numbers. However, they also include an identifier that indicates which version of the IOSd is included in the release.

The IOSd is a very visible component of Cisco IOS XE Software, and its origins derive from the Cisco IOS Software Release 12.2S family. The IOSd incorporates the routing protocol functionality of Cisco IOS Software and is essentially Cisco IOS Software code that runs as a separate process on a device. This modular architecture increases network resiliency by distributing operating responsibility among separate processes. Although each Cisco IOS XE Software release includes a version of the IOSd, IOSd versioning uses the versioning schema of traditional Cisco IOS Software trains; the IOSd does not use the same versioning schema as Cisco IOS XE Software. Consequently, the IOSd version number is exposed in the names of releases that derive from the Cisco IOS XE Software Release 3E, 3S, 3SE, 3SG, and 3SP trains. (The IOSd version number is not exposed in the names of releases from Cisco IOS XE Software Release 16 trains; starting with Cisco IOS XE Software Release Denali 16.1.1, an IOSd version number is not included in release names.)

The following figure (Figure 7) outlines the components of release names for the Cisco IOS XE Software Release 3E, 3S, 3SE, 3SG, and 3SP trains, using a release from the Cisco IOS XE Software Release 3S train as an example:

Major release number: Indicates the applicable software release family—for example, 03 for a release from the 3S or 3E train.

Release version number: Increases by an increment of 1 for each release that introduces significant changes to the software, support for new hardware platforms, and enhancements and bug fixes for existing features and functions. This number also indicates whether a release is a standard or extended maintenance release, based on the time-based release cadence for the software.

Rebuild number: Increases by an increment of 1 for each release that integrates fixes for high-severity issues that exist in an individual release and should be addressed on an accelerated schedule. The numbering starts with 0. For example, and continuing with the example in Figure 7, the release is the fourth rebuild of Release 3.17S.

Train identifier: Indicates the applicable software train.

IOSd version identifier: Indicates which version of the IOSd is included in the release, according to the versioning schema that is used for traditional Cisco IOS Software trains—for example, and continuing with the example in Figure 7, Release 15.6(1)S4.

An additional way to see which version of the IOSd is included in a Cisco IOS XE Software 3E, 3S, 3SE, 3SG, or 3SP release is to visit the Software Center on Cisco.com, navigate to the Cisco IOS XE Software releases for the applicable platform, and refer to the name of the software image for the release. The name of each Cisco IOS XE Software image indicates the version of the IOSd that is included in the release. For more information, see the Cisco IOS XE Software Image Naming section of this guide. The release notes and other documentation for some products also provide a mapping table that indicates which version of the IOSd is included in specific releases of Cisco IOS XE Software:

For Cisco Catalyst 3650 Series Switches and Cisco Catalyst 3850 Series Switches, it may also be helpful to know which Cisco Wireless Control Module version and which Access Point version map to specific Cisco IOS XE Software releases. For these switches, see the “Finding the Software Version and Feature Set” section of the release notes for the switch to see the mapping between Cisco IOS XE Software releases, Cisco IOSd versions, Cisco Wireless Control Module versions, and Access Point versions—for example, Cisco IOS XE Release 3.7.xE Release Notes for Cisco Catalyst 3650 Series Switches.

Cisco IOS XR Software

Cisco IOS XR Software is released in modular packages. A package contains the components that support a specific set of features or functions, such as routing, security, or modular services card (MSC) support. Every supported device includes a basic set of required packages, which are contained in a Cisco IOS XR Software Core Bundle for the device, and additional, optional packages that can be added to and activated on the device to enable additional specific features.

Unlike Cisco IOS Software, where feature sets are defined at image build time and remain static while the system is in operation, Cisco IOS XR Software can dynamically load and unload software packages that deliver one or more features. In addition, Cisco IOS XR Software packages are created in versions and can be upgraded or patched as necessary to add features or resolve problems, which allows system enhancement and maintenance to take place without requiring a system restart or disrupting traffic that is traversing the system. To upgrade a package, administrators activate a newer version of the package. To patch a package, administrators activate the patch.

There are currently three primary types of releases for Cisco IOS XR Software packages:

Feature release: Introduces new features or functions, including infrastructure and architectural changes, support for new hardware platforms, and enhancements and bug fixes for existing features and functions. This type of release, also referred to as a major release, consists of multiple minor releases.

Maintenance release: Delivers critical bug fixes for existing features and functions. Each maintenance release is cumulative for the feature release that it supports. That is to say, the latest maintenance release includes all critical fixes that have been released for a feature since the feature release was introduced.

Software Maintenance Unit (SMU): Provides point fixes for critical issues that should be addressed between regular maintenance releases of a software package. SMUs are not intended to deliver new features and, therefore, are not a replacement for maintenance releases. In addition, each SMU is specific to both a release and a platform. The impact of an SMU on a running system varies. Some SMUs, referred to as hitless SMUs, are designed to allow uninterrupted operation of a system while the SMU is installed and activated. To determine how installation and activation of an SMU will impact a running system, see the release notes for the SMU.

The naming conventions for Cisco IOS XR Software releases reflect the different release types, as shown in the following figure (Figure 8):

Figure 8: Release Name Components—Cisco IOS XR Software

The components are:

Major release number: Increases by an increment of 1 for each feature release that introduces significant changes to the software, including infrastructure and architectural changes, support for new hardware platforms, and enhancements and bug fixes for existing features and functions. This type of release consists of multiple minor releases.

Release version number: Increases by an increment of 1 for each release that introduces new functions and features in addition to enhancements and bug fixes for existing features and functions.

Maintenance release number: Increases by an increment of 1 for each maintenance release that delivers critical bug fixes for existing features and functions.

The resulting release name is then reflected as a value (release) in the larger naming schema for Cisco IOS XR Software packages. The following diagram (Figure 9) outlines the components of Cisco IOS XR Software package names:

Figure 9. Package Name Components—Cisco IOS XR Software

The components are:

Name: Indicates the platform and functionality that the software supports. In this example, the package was built for Cisco Network Convergence System 5500 Series Routers, and it contains the Cisco IOS XR Multiprotocol Label Switching (MPLS) Package.

Version: Indicates the version of the package. In this example, the file contains version 1.0.0.0 of the package.

Release: Indicates which release of the software is included in the package. In this example, the package is part of Cisco IOS XR Software Release 6.0.0, where r stands for release.

Architecture: Indicates the node processor architecture that the package is compatible with. In this example, the package is compatible with hardware that uses an x86 or 64-bit architecture.

File format: The file is formatted as an RPM Packet Manager file, as indicated by the .rpm filename extension. Note that base packages use the ISO (.iso) file format instead of the RPM Packet Manager file format.

Note that SMUs have slightly different naming conventions because they are designed to be release-specific, platform-specific patches. The key differences are the file format and an additional value that indicates which bug an SMU addresses. SMUs are released as software maintenance upgrade (.smu) files, not RPM Packet Manager files. In addition, SMU filenames include the ID of the bug that the SMU addresses. This ID is inserted between the release and architecture values in the filename. For example, and continuing with the example in Figure 9, the filename of an SMU that addresses Cisco bug CSCab12345 would be ncs5500-mpls-1.0.0.0-r600.CSCab12345.x86_64.rpm. For more information about SMU-naming conventions and SMUs overall, see Cisco IOS XR Software Maintenance Updates.

Cisco NX-OS Software

Cisco NX-OS Software is a data-center-class operating system that provides high availability with a modular design. The software is based on Cisco MDS 9000 SAN-OS Software, and it supports Cisco Nexus Series Switches and Cisco MDS Series Multilayer Switches. There are currently three primary types of Cisco NX-OS Software releases:

Major release or software train: Introduces significant new features or functions and support for new hardware platforms. Each major release consists of multiple minor releases.

Minor release: Enhances a major release by providing new features.

Maintenance release: Primarily addresses defects in a minor release and typically does not include any new features. This approach ensures that each maintenance release preserves the integrity and stability of the applicable minor release.

To integrate fixes for high-severity issues that should be addressed on an accelerated schedule, Cisco may also release a rebuild of a Cisco NX-OS Software release. This type of release, sometimes referred to as a support patch, reduces the possible impact on customers who have already certified and deployed a release.

The release-naming conventions for Cisco NX-OS Software clearly reflect the different types of software releases. The name of each release contains a major release number, a minor release number, a maintenance release number, and, if appropriate, a rebuild identifier. There are two sets of release-naming conventions for the software. One set applies to Cisco NX-OS Software releases for Cisco Nexus 7000 Series Switches and Cisco MDS 9000 Series Multilayer Switches prior to Release 7.3. The other set applies to Cisco NX-OS Software Releases for all other supported hardware platforms and for Releases 7.3 and later for any supported platform.

Figure 11 outlines the components of Cisco NX-OS Software release names for other supported hardware platforms and for Releases 7.3 and later for any supported platform. Unlike the preceding conventions, these naming conventions include a combination of platform-independent and platform-dependent identifiers.

Figure 11. Release Name Components—Cisco NX-OS Software for Other Platforms

With these naming conventions, valid values for the platform designator are: I for Cisco Nexus 3000 Series Switches and Cisco Nexus 9000 Series Switches; N for Cisco Nexus 5000 Series Switches; and S for Cisco Nexus 1000 Series Switches. For Cisco Nexus 1000V Virtual Switches, the platform designator is a two-letter platform designation where the second letter indicates the hypervisor vendor that the virtual switch is compatible with, SM for Microsoft Hyper-V and SV for VMware vSphere. All applicable features, functions, and fixes in the platform-independent code are present in each platform-dependent release. For example, and continuing with the example in Figure 11, all applicable features, functions, and fixes in Cisco NX-OS Software Release 7.1(0) are present in Release 7.1(0)N1(1b).

Note: Cisco NX-OS Software Release 9.2(1) is the first release that adopts new, unified version-numbering conventions. Because support for more platforms has been added to the software, there is no longer a need to have the platform designator that was used in the past.

Software Packaging

Cisco IOS Software uses software packaging models and architectures that are designed to meet the requirements of specific service and market categories and to simplify the selection process for software images. The following sections explain the packaging models and architectures for Cisco IOS, IOS XE, and IOS XR Software. There is no special packaging model for Cisco NX-OS Software; each Cisco NX-OS Software system image is a single file.

Cisco IOS Software

The Cisco IOS Software packaging model is designed to simplify the image selection process and the deployment of critical functionality. It does so by consolidating packages to reduce the total number of packages and by using consistent package names across all hardware products. The current packaging model was introduced in the Cisco IOS Software Release 12.3 Mainline train and has since been used for other Cisco IOS Software release families and trains. The packages provide similar functionality and logical feature parity across platforms, while also meeting the unique requirements of each platform.

Cisco IOS Software packaging for Cisco Catalyst 3560-E and 3560-X Series Switches, Cisco Catalyst 3750-E and 3750-X Series Switches, Cisco Catalyst 4500E Series Supervisor Engine 7-E Modules, and Cisco Integrated Services Routers Generation 2 (ISR G2) Routers supports services on demand through use of the Cisco Software Activation feature. This feature is an orchestrated collection of processes and components that enables administrators to activate specific Cisco IOS Software feature sets by obtaining and validating Cisco software licenses for those feature sets. With the Cisco Software Activation feature, administrators can enable licensed features and register licenses by using the Cisco Product License Registration portal, issuing EXEC commands directly on a device, or using Cisco License Manager to register, obtain, and install licenses in a bulk fashion for network-wide deployments. For more information about the Cisco Software Activation feature, see Cisco IOS Software Activation Conceptual Overview.

Consequently, these switches and routers ship with a single, universal Cisco IOS Software image that contains all available features. Administrators can then obtain specific licenses to enable the corresponding feature sets. There are two types of universal software images:

universalk9_npe: Images with the universalk9_npe designation in the image name offer all Cisco IOS Software features except strong payload cryptography features. The strong enforcement of encryption capabilities provided by the Cisco Software Activation feature satisfies requirements for exporting encryption capabilities. However, the import requirements of some countries require that the platform not support any strong cryptography functionality, such as payload cryptography. To satisfy the import requirements of these countries, the npe universal image does not include any support for strong payload encryption.

IPBase: As the default image for most switches and routers, provides support for the baseline set of services and technologies that are required to operate a switch or router in a data environment, including Border Gateway Protocol (BGP), Enhanced Interior Gateway Routing Protocol (EIGRP), Intermediate System-to-Intermediate System (IS-IS), Open Shortest Path First (OSPF), Routing Information Protocol (RIP), and policy-based routing Internet Group Management Protocol (PBR IGMP)

Cisco IOS Software for other models of Cisco switches and routers can use any of seven different software packages, depending on the model, to meet the requirements of different market categories. The software packages are:

Layer 2 Base: Provides the baseline set of services and technologies that are required for a Layer 2 Ethernet switched environment, including support for IEEE 802.1D, 802.1X point authentication, 802.3ad EtherChannel, 802.1s/w Rapid Spanning Tree, Port Security, SmartPorts, and Secure Shell Version 2 (SSHv2)

LAN Base: Includes all the features in the Layer 2 Base package plus support for advanced IEEE 802.1X, advanced quality of service (QoS), and advanced access control lists (Layer 2 through 4 filtering, time-based access control lists, and port-based ACLs)

Advanced IP Services: Includes all the features in the IP Services package plus support for IP Version 6 (IPv6), Intermediate System-to-Intermediate System (IS-IS), Multiprotocol Label Switching (MPLS), Layer 2 VPNs, and Layer 3 VPNs

Enterprise Services: Includes all the features in the IP Services package plus support for IPv6 and additional features for Layer 3 multiprotocol environments, such as AppleTalk Routing, IPX Routing, and IBM Networking Services

Advanced Enterprise Services: Includes all the features in the IP Services and Enterprise Services packages

The name of a software image indicates which software package the image contains and whether the image includes strong cryptography features. If an image name contains the k9 designation, the image includes strong cryptography features. For example, if an image name contains adventerprisek9, the image contains an Advanced Enterprise Services package that includes strong cryptographic features. For more information, see the Cisco IOS Software Image Naming section of this guide.

Cisco IOS XE Software

Cisco IOS XE Software is released in consolidated packages and optional individual subpackages. A consolidated package is a single software image that contains a collection of software subpackages. A subpackage is an individual software file that provides a specific set of functionality or controls a different element or elements of a router or switch. For example, the Cisco IOS kernel is provided by the RPIOS (Route Processor IOS) subpackage, which is one of the subpackages included in each consolidated package of Cisco IOS XE Software.

Using the Cisco ASR 1000 Series Route Processor (RP1) as an example, the following diagram (Figure 12) provides an overview of the individual subpackages that may comprise a consolidated Cisco IOS XE Software package, and it summarizes the purpose of each subpackage. The diagram also shows how each subpackage provides a different set of functionality that complements or supports the functionality provided by one or more other subpackages in the same consolidated package.

The consolidated package architecture enables administrators to install and upgrade the software by using a holistic or modular approach. Administrators can install and run all the subpackages in a consolidated package or only specific subpackages in a consolidated package. In addition, administrators can upgrade the software by performing a single, complete upgrade process that upgrades all the subpackages in a consolidated package or they can upgrade each software subpackage independently.

For more information about the advantages and disadvantages of running individual subpackages or complete consolidated packages, and the process of extracting individual subpackages from a consolidated package, see the Cisco ASR 1000 Series Aggregation Services Routers Software Configuration Guide. For information about which consolidated packages are available for a specific release of Cisco IOS XE Software, see the release notes for the release.

Cisco IOS XR Software

Cisco IOS XR Software is released in modular packages. Each package contains components that support a specific set of features or functions, such as routing, security, or modular services card (MSC) support. In addition, each supported device ships with a preinstalled set of required packages, which are contained in a Cisco IOS XR Software Core Bundle for the device. Administrators can then add and activate additional optional packages and software maintenance updates (SMUs) on the device as necessary to provide additional specific features and to address issues.

Unlike Cisco IOS Software, where feature sets are defined at image build time and remain static while the system is in operation, Cisco IOS XR Software can dynamically load and unload software packages that deliver one or more features. In addition, Cisco IOS XR Software packages are created in versions and can be upgraded or patched as necessary to add features or resolve problems, which allows system enhancement and maintenance to take place without requiring a system restart or disrupting traffic that is traversing the system. To upgrade a package, administrators activate a newer version of the package. To patch a package, administrators activate the patch.

Cisco NX-OS Software

There is no special packaging model for Cisco NX-OS Software. Each Cisco NX-OS Software system image is a single file.

Software Image Naming

A Cisco IOS Software or Cisco NX-OS Software image is an executable file that contains one or more feature sets for a specific platform. The filename of a software image indicates the target platform, the applicable feature set, and other information about the software image contained in the file. Administrators can determine which software image and release is running on a device by issuing the show version command in the CLI and reviewing the output of the command. By using examples, this section explains the image-naming conventions for the current, primary Cisco IOS Software and Cisco NX-OS Software release families.

Cisco IOS Software

The name of each Cisco IOS Software image indicates the applicable hardware, feature set, software release, and other information about the image. Figure 13 outlines the components of an image name, using the Cisco IOS Software image on a Cisco 2921 Integrated Services Router (ISR) as an example.

Figure 13. Components of Software Image Names—Cisco IOS Software

In the example, the software image has the following characteristics:

Hardware: The image was built for a Cisco 2900 Series ISR.

Feature set: The image contains the universal feature set and, as indicated by the k9 designation, includes support for strong cryptography features. If an image does not include support for these features, the k9 designation is omitted from the image name—for example, c2900-universal-mz.SPA.154-3.M3.bin. Note that support for payload encryption is indicated by a different naming component. If an image does not include support for strong encryption of payloads, the npe (no payload encryption) designation is appended to the name of the feature set—for example, c2900-universalk9_npe-mz.SPA.154-3.M3.bin.

Memory location: The image runs from RAM, as indicated by the m designation.

Compression format: The image uses ZIP compression, as indicated by the z designation.

Digital signature indicator: The image is digitally signed, as indicated by the SPA designation:

The S (first character) stands for signed, as in digitally signed software.

The P (second character) stands for production. The second character may be a P or an S, where P indicates a production image and S indicates a special (development) image. A production image is Cisco software that is approved for general release. A special image is development software that is for limited use and provided only under special conditions.

The A (third character) indicates the key version that was used to digitally sign the image. A key version is identified by an alphabetical character―for example, A, B, C, and so on.

File format: The file is a binary format file, as indicated by the .bin filename extension. Some images use the TAR (.tar) file format.

To determine which Cisco IOS Software image and release is running on a device, administrators can log in to the device, issue the show version command in the CLI, and then review the output of the command. The following example shows the output of the command for a Cisco 2921 Integrated Services Router (ISR). The output indicates which Cisco IOS Software release is running on the device (15.4(3)M3), the name of the Cisco IOS Software image file that is installed on the device (c2900-universalk9-mz.SPA.154-3.M3.bin), and the underlying hardware (Cisco CISCO2921), as indicated in bold.

Cisco IOS XE Software

As is the case with Cisco IOS Software images, the name of each Cisco IOS XE Software image indicates the applicable hardware, feature set, software release and release type, and other information about the image. There are currently two sets of image-naming conventions, one for the Cisco IOS XE Software Release 16 trains and another for the 3E, 3S, 3SE, 3SG, and 3SP trains. Figure 14 outlines the components of software image names for the Cisco IOS XE Software Release 16 trains, using the software image on a Cisco ASR 1002-X Router as an example.

Feature set: The image contains the universal feature set and, as indicated by the presence of the k9 designation, includes support for strong cryptography features. If an image does not include support for these features, the k9 designation is not appended to the name of the feature set—for example, asr1002x-universal.16.09.01.SPA.bin. Note that support for payload encryption is indicated by a different naming component. If an image does not include support for strong encryption of payloads, the npe (no payload encryption) designation is appended to the name of the feature set, after the k9 designation—for example, asr1002x-universalk9_npe.16.09.01.SPA.bin.

Digital signature indicator: The image is digitally signed, as indicated by the SPA designation:

The S (first character) stands for signed, as in digitally signed software.

The P (second character) stands for production. The second character may be a P or an S, where P indicates a production image and S indicates a special (development) image. A production image is Cisco software that is approved for general release. A special image is development software that is for limited use and provided only under special conditions.

The A (third character) indicates the key version that was used to digitally sign the image. A key version is identified by an alphabetical character―for example, A, B, C, and so on.

File format: The file is a binary format file, as indicated by the .bin filename extension. Some images may use the TAR (.tar) file format.

Figure 15 outlines the components of Cisco IOS XE Software image names for the 3E, 3S, 3SE, 3SG, and 3SP trains, using the software image on a Cisco ASR 1002-X Router as an example.

Feature set: The image contains the universal feature set and, as indicated by the absence of the k9 designation, does not include support for strong cryptography features. If an image includes support for these features, the k9 designation is appended to the name of the feature set—for example, asr1002x-universalk9.03.10.00.S.153-3.S-ext.SPA.bin. Note that support for payload encryption is indicated by a different naming component. If an image does not include support for strong encryption of payloads, the npe (no payload encryption) designation is appended to the name of the feature set, after the k9 designation—for example, asr1002x-universalk9_npe.03.10.00.S.153-3.S-ext.SPA.bin.

Digital signature indicator: The image is digitally signed, as indicated by the SPA designation:

The S (first character) stands for signed, as in digitally signed software.

The P (second character) stands for production. The second character may be a P or an S, where P indicates a production image and S indicates a special (development) image. A production image is Cisco software that is approved for general release. A special image is development software that is for limited use and provided only under special conditions.

The A (third character) indicates the key version that was used to digitally sign the image. A key version is identified by an alphabetical character—for example, A, B, C, and so on.

File format: The file is a binary format file, as indicated by the .bin filename extension. Some images may use the TAR (.tar) file format.

To determine which Cisco IOS XE Software image and release is running on a device, administrators can log in to the device, issue the show version command in the CLI, and then review the output of the command. The following example shows the output of the show version command for a Cisco ASR 1002-X Router that is running Cisco IOS XE Software Release Fuji 16.9.1. The output indicates the name and type of the software release that is running on the device (16.09.01), the name of the Cisco IOS XE Software image file that is installed on the device (asr1002x-universalk9.16.09.01.SPA.bin), and the underlying hardware (Cisco ASR1002-X), as indicated in bold.

ASRRouter16# show versionCisco IOS XE Software, Version 16.09.01
Cisco IOS Software [Fuji], ASR1000 Software (X86_64_LINUX_IOSD-UNIVERSALK9-M), Version 16.9.1, RELEASE SOFTWARE (fc2)
Technical Support: http://www.cisco.com/techsupport
Copyright (c) 1986-2018 by Cisco Systems, Inc.
Compiled Tue 17-Jul-18 17:02 by mcpre
Cisco IOS-XE software, Copyright (c) 2005-2018 by Cisco Systems, Inc.
All rights reserved. Certain components of Cisco IOS-XE software are
licensed under the GNU General Public License ("GPL") Version 2.0. The
software code licensed under GPL Version 2.0 is free software that comes
with ABSOLUTELY NO WARRANTY. You can redistribute and/or modify such
GPL code under the terms of GPL Version 2.0. For more details, see the
documentation or "License Notice" file accompanying the IOS-XE software,
or the applicable URL provided on the flyer accompanying the IOS-XE
software.
ROM: IOS-XE ROMMON
ASRRouter16 uptime is 11 minutes
Uptime for this control processor is 13 minutes
System returned to ROM by Reload Command
System image file is "bootflash:asr1002x-universalk9.16.09.01.SPA.bin"
Last reload reason: Reload Command
This product contains cryptographic features and is subject to United
States and local country laws governing import, export, transfer and
use. Delivery of Cisco cryptographic products does not imply
third-party authority to import, export, distribute or use encryption.
Importers, exporters, distributors and users are responsible for
compliance with U.S. and local country laws. By using this product you
agree to comply with applicable laws and regulations. If you are unable
to comply with U.S. and local laws, return this product immediately.
A summary of U.S. laws governing Cisco cryptographic products may be found at:
http://www.cisco.com/wwl/export/crypto/tool/stqrg.html
If you require further assistance please contact us by sending email to
export@cisco.com.
License Type: RightToUse
License Level: adventerprise
Next reload license Level: adventerprise
The current throughput level is 50 kbps
cisco ASR1002-X (2RU-X) processor (revision 2KP) with 6926415K/6147K bytes of memory.
Processor board ID FOX2114P77Y
6 Gigabit Ethernet interfaces
32768K bytes of non-volatile configuration memory.
16777216K bytes of physical memory.
6594559K bytes of eUSB flash at bootflash:.
0K bytes of WebUI ODM Files at webui:.
Configuration register is 0x2102
ASRRouter16#

The following example shows the output of the command for a Cisco ASR 1002-X Router that is running Cisco IOS XE Software Release 3.10.00.S. The output indicates the name and type of the software release that is running on the device (03.10.00.S - Extended Support Release), which version of the Cisco IOSd is running on the device (15.3(3)S), the name of the Cisco IOS XE Software image file that is installed on the device (asr1002x-universal.03.10.00.S.153-3.S-ext.SPA.bin), and the underlying hardware (Cisco ASR1002-X), as indicated in bold.

Administrators can additionally determine which subpackages and subpackage versions are running on the active route processor (RP) by issuing the show version rp active running command in the CLI and referring to the value in the Package field of the command output. The following example shows the output of the command for the Cisco ASR 1002-X Router that is used in the preceding example:

Cisco IOS XR Software

The name of each Cisco IOS XR Software image indicates much of the same information as the names of software images for Cisco IOS Software and Cisco IOS XE Software. However, because the software packaging and deployment model is different for Cisco IOS XR Software, the names of Cisco IOS XR Software images contain fewer components and the file formats are different. Figure 16 outlines the components of a Cisco IOS XR Software image name, using the software image on a Cisco Carrier Routing System (CRS-X) as an example.

Figure 16. Components of Software Image Names—Cisco IOS XR Software

In the example, the software image has the following characteristics:

Hardware: The image was built for a Cisco CRS Router.

Software type: The image contains Cisco IOS XR Software.

Image type: The image is compatible with hardware that uses the x86 architecture, as indicated by the px designation. Another valid designation for the image type is p, but this designation was retired after Cisco IOS XR Software Release 4.3.0. The p designation was used with the original Route Switch Processors that were based on dual-core PPCs.

Encryption support: The image includes support for strong cryptography features, including payload encryption, as indicated by the k9designation. If an image does not include support for these features, the k9 designation is omitted from the image name—for example, CRS-iosxr-px-6.1.4.tar.

File format: The file is a TAR format file, as indicated by the .tar filename extension. Some images may use the package installation envelope (.pie) file format, the TEXT (.txt) file format, or another file format.

To determine which release of Cisco IOS XR Software is running on a device, administrators can log in to the device, issue the show version command in the CLI, and then review the output of the command. The following example shows the output of the command for a Cisco CSR-1 16-Slot Line Card Chassis. The output indicates which Cisco IOS XR Software release is running on the device (6.1.4) and the name of the Cisco IOS XR Software image file that is installed on the device (hfr-os-mbi-6.1.4/0x100008/mbihfr-rp-x86e.vm), where hfr was an early name for the Cisco CRS-1 Carrier Routing System and x86 indicates compatibility with the x86 architecture, as indicated in bold.

To determine which Cisco IOS XR Software packages are active on a device, administrators can issue the show install active command in the CLI and refer to the values in the Active Packages field of the command output. Continuing with the preceding example, the output of the command is as follows for the chassis. Note that the output also indicates where the node stores the active package (Boot Device) and the location of the minimum boot image (MBI) that is used to boot the node (Boot Image).

Cisco NX-OS Software

The name of each Cisco NX-OS Software image indicates the applicable hardware, feature set, software release, and other information about the image. Figure 17 outlines the components of an image name, using the Cisco NX-OS Software image on a Cisco Nexus 7000 9-Slot Switch (C7009) Supervisor 2 Module as an example.

Figure 17. Components of Software Image Names—Cisco NX-OS Software

In the example, the software image has the following characteristics:

Hardware: The image was built for a Cisco Nexus 7000 Series Switch Supervisor Module 2.

Product class: The image contains a data-center-class product, as indicated by the d designation. Other valid designations for the product class are e for an enterprise class product, u for a data-center-class product that supports unified I/O, and b for a blade product.

Encryption support: The image includes support for strong cryptography features, as indicated by the k9 designation. If an image does not include support for these features, the k9 designation is omitted from the image name—for example, n7000-s2-d.6.2.18.bin. Note that support for payload encryption is indicated by a different naming component. If an image does not include support for strong encryption of payloads, the npe (no payload encryption) designation is prepended to the software release value in the name—for example, n7000-s2-dk9-npe.6.2.18.bin.

File format: The file is a binary format file, as indicated by the .bin filename extension. Some images use the TAR (.tar) file format.

To determine which release of Cisco NX-OS Software is running on a device, administrators can log in to the device, issue the show version command in the CLI, and then review the output of the command. The following example shows the output of the command for a Cisco Nexus 7000 9-Slot Switch (C7009) Supervisor 2 Module. Note that the output indicates which Cisco NX-OS Software release is running on the device (6.2(18)), the name of the Cisco NX-OS Software image file that is installed on the device (n7000-s2-dk9.6.2.18.bin), and the underlying hardware (Cisco Nexus7000 C7009 (9 Slot) Chassis ("Supervisor Module-2")), as indicated in bold.

Software Lifecycle

The lifecycle of Cisco IOS Software and Cisco NX-OS Software releases adheres to release policies that define key phases and milestones in the lifecycle of each release―from first customer shipment (FCS) through the last date of support―and factor migration planning for software releases. Figure 18 shows the typical phases and milestones in the lifecycle of a software release.

First customer shipment (FCS): The first day when the release is available to customers.

End-of-sale announcement: A public notification of the upcoming end-of-sale date for the release. Cisco typically publishes this announcement six months before the actual end-of-sale date. Cisco recommends that administrators begin evaluating other releases and developing migration plans when Cisco publishes this announcement for a release that is currently deployed in an environment.

End of sale: The last day when customers can order the release through Cisco point-of-sale mechanisms and the last day when manufacturing shipments of Cisco hardware include the release.

Software maintenance: The time period when Cisco Engineering may release any software maintenance releases or bug fixes for the release.

End of software maintenance (EoSW): The last day when Cisco Engineering may release any final software maintenance releases or bug fixes for the release. After this date, Cisco Engineering stops developing, repairing, maintaining, and testing the release; support for the release is provided via supported successor releases.

End of security vulnerability support (EoSV): The last day when Cisco Engineering may release fixes that address security vulnerabilities and issues. This date depends on the software release train and release. In some cases, for a brief time after the end-of of-software maintenance period, Cisco Engineering may provide rebuilds that include fixes for security vulnerabilities and issues.

Last date of support: The last day when the Cisco Technical Assistance Center (TAC) provides service and support for the release. After this date, all support services for the release are unavailable and the release becomes obsolete.

After the last date of support, the release has reached the end-of-life milestone and is obsolete, which means the release is not sold, manufactured, improved, repaired, maintained, or supported. For detailed information about end-of-sale and end-of-life milestones, see the End-of-Life Policy. For information about which Cisco IOS Software and Cisco NX-OS Software releases have reached these milestones, see Cisco IOS and NX-OS End-of-Sale and End-of-Life Products.

Although software retirement is not a formal milestone in the software-release lifecycle, software releases that are published to the Software Center on Cisco.com typically remain available for customer download for 18 months and then become eligible for retirement and removal from the Software Center. For applicable platforms that have not reached the end-of-software-maintenance milestone, software releases are not retired and removed from the Software Center unless a viable migration path exists. A viable migration path does not cross critical memory boundaries for supported hardware and, if applicable, has a similar internal or external certification. In addition, retirement and removal of a software release from the Software Center is subject to deferral at any time in the event that a widespread, catastrophic software defect is discovered.

Regardless of whether a release is available from or is eligible for retirement and removal from the Software Center, Cisco recommends that administrators maintain copies of all software releases that are running on a network. Cisco also recommends that administrators implement only current releases of software; Cisco does not recommend new deployments of retired software releases. However, software releases are retired primarily based on age. If Cisco retires a software release that is running on a network, it does not mean that the software should automatically be replaced on that network. In other words, if the software meets customer needs, the customer can continue to use it. In addition, the Cisco TAC will continue to provide service and support for a retired software release until the release reaches the published, last date of support.

Notes:

The durations of phases in the lifecycle of a Cisco IOS Software release depends on the software release family, train, and release. For detailed information about the lifecycle of a specific release, see the release notes and support timeline bulletins that are associated with the release.

The lifecycle of a Cisco IOS XR Software release typically has a duration of 18 months from the FCS date to the end-of-sale date, followed by a sustaining support lifetime of five years from the end-of-sale date to the end-of-life date. For more information about the support models and timelines for Cisco IOS XR Software release, see Guidelines for Cisco IOS XR Software.

The lifecycle of a Cisco NX-OS Software release depends primarily on whether the release is a long-lived release or a short-lived release. Although the lifecycles of long-lived and short-lived releases have the same phases and milestones, the durations of phases in these lifecycles vary. For detailed information about the lifecycles of Cisco NX-OS Software releases, see Cisco NX-OS Software Release Strategy.

Software Migration Examples

The code selection process involves a number of different variables. Cisco recommends minimizing the number of software releases that are deployed in any network environment and establishing a software strategy that indicates which releases and images will be used by different devices that are deployed throughout the environment. To maximize operational efficiency, it is ideal to use the same software release on devices that have similar hardware and feature deployments. For professional advice on which software releases to deploy in specific environments, contact Cisco Services.

If there is no need to change the Cisco IOS Software or Cisco NX-OS Software release train that is used by a device, the general migration path for the device is to migrate to the latest software release from that train. The latest release will include the most current software fixes, software features, and hardware support for the train. If the train has an end-of-sale announcement, the announcement will indicate recommended trains or releases to migrate to.

The following sections provide high-level examples of common migration paths for some commonly deployed releases of Cisco IOS, Cisco IOS XE, Cisco IOS XR, and Cisco NX-OS Software. The examples include general guidelines; software selection must include analysis of outstanding caveats that apply to the environment where the software will be deployed. For minimum due diligence, administrators should review the open and fixed caveats section of the release notes for any software release under evaluation.

Note: Software migration is an ongoing process that requires detailed planning. Customers should work closely with their account managers when they inventory their software deployments and create a plan to migrate to more current releases.

The administrator sees the end-of-life announcement for the 15.0M train and needs to upgrade to a comparable new release.

Migrate to the latest release from a Cisco IOS Software 15M (or M&T) train, such as the 15.2M&T train.

When the administrator evaluated the end-of-life milestone for Release 15.0(1)M, they noted that the latest M train release at the time was Release 15.7.3M2(ED). However, Release 15.7.3M2(ED) is an early deployment release. Considering the choices available, the administrator chose to migrate to Cisco IOS Software Release 15.5(3)M7, which is a maintenance release that has a gold-star rating and is a Cisco Suggested release based on software quality, stability, and longevity.

Cisco IOS Software Release 15.4(3)M1

The administrator sees a new Cisco Security Advisory for a security vulnerability in the release. The administrator needs to deploy the fix for the vulnerability.

Migrate to the latest release from a Cisco IOS Software 15M (or M&T) train, such as the 15.4M&T train.

When the administrator assessed the risk of the vulnerability, they noted that the 15.4M train had not reached the end-of-life milestone and was still under extended maintenance. Therefore, the administrator decided to migrate to the latest release at the time for the 15.4M train, which was Release 15.4(3)M8, to obtain the latest security and bug fixes.

The administrator needs the latest security and bug fixes, new features, and new hardware support.

Migrate to the latest rebuild of the latest release from the Cisco IOS XE Software Release 3.6.0E train.

When the administrator assessed the status and features of the release train, they decided to migrate to the latest release at the time for the train, which was Release 3.6.6E. In addition, the administrator chose the latest rebuild of that release to ensure maximum coverage of available fixes for security vulnerabilities and bugs.

Cisco IOS XE Software Release 3.7.0E

The administrator needs the latest security and bug fixes, and new features and hardware support provided only by the Cisco IOS XE Software Release 16 trains.

Migrate to a recent, appropriate maintenance release that is from a Release 16 train and has the highest stability rating, such as Denali 16.3.5b.

When the administrator assessed the status and features of the Cisco IOS XE Software Release 16 trains and considered that these trains are the result of merging the 3E and 3S trains, they determined that the Denali 16.3 train was most compatible with the current and projected hardware requirements for the environment.

Cisco IOS XE Software Release S train (any release)

The administrator needs the latest security and bug fixes, new features, and new hardware support.

Depending on the software release and hardware platform to be upgraded:

After Release 3.16S and for Cisco 4000 Series Integrated Services Routers, Cisco ASR 1000 Series Aggregation Services Routers, and Cisco Cloud Services Router 1000V Series, migrate to the next train, such as the Denali 16.3 train.

After Release 3.18S (and 3.18SP) and for Cisco ASR 900 and 920 Series Aggregation Services Routers and Cisco Network Convergence System 4200 Series Routers, migrate to the next train, such as the Everest 16.5 train.

The administrator sees a new Cisco Security Advisory for a security vulnerability in the release. The administrator needs to deploy the fix for the vulnerability.

Depending on fixed release availability for the vulnerability and the scope of additional fixes that the administrator is willing to deploy:

If a software maintenance upgrade (SMU) is available for the vulnerability, apply the SMU. Do not migrate to a different release.

If a service pack (SP) is available and includes the fix for the vulnerability, apply the SP for the currently deployed release. Do not migrate to a different release.

Migrate to the latest release that includes the fix for the vulnerability, without requiring application of an SMU.

Cisco NX-OS Software

The following table (Table 9) provides examples of common migration paths for specific Cisco NX-OS Software releases. To minimize downtime during a software upgrade, administrators should review the in-service software upgrade (ISSU) instructions in the release notes for a release before they migrate to the release.

Table 9. Example Migration Paths for Cisco NX-OS Software

Currently Deployed Release

Migration Strategy

Example Migration Path

Cisco NX-OS Software Release 7.3(1)D1(1)

The administrator needs the latest security and bug fixes, new features, and additional hardware support.

Migrate to the latest release from the Cisco NX-OS Software Release 7.3 train.

Cisco NX-OS Software Release 7.3(1)D1(1)

The administrator needs the fix for a specific bug.

Depending on fixed release availability for the bug and the scope of additional fixes that the administrator is willing to deploy:

If an SMU is available and includes the fix for the bug, apply the SMU for the currently deployed release. Do not migrate to a different release. For example, if the device is affected by Cisco bug CSCve79599, apply the umbrella SMU fix (n7700-s2-dk9.7.3.1.D1.1.CSCve79599.bin) to current deployments.

Migrate to Release 7.3(2)D1(1), which contains the fix for the bug and is the next maintenance release from the same train.

Important Communications

Throughout the lifecycle of a software release, Cisco publishes software advisories for informational purposes. These advisories often describe problems that are hardware-specific or occur under unusual circumstances and therefore do not affect most customers. Often, no customer action is required.

However, the following communications do require customers to evaluate the potential impact of the underlying problem on their networks and take appropriate action:

Security advisory: The Cisco Product Security Incident Response Team (PSIRT) publishes a security advisory to alert customers to a security issue that directly impacts one or more Cisco products and to help customers address the issue in their deployments of any affected products. This type of advisory provides detailed information about a security issue that affects Cisco products directly and may require an upgrade, fix, or other customer action to address the issue. To help customers assess security risk, each advisory includes a Security Impact Rating (SIR), which provides a way to categorize the severity of an issue. For more information about Cisco Security Advisories, see the Cisco Security Vulnerability Policy.

Deferral advisory: Cisco publishes a deferral advisory to announce the removal of a Cisco IOS or Cisco NX-OS Software image from Cisco offerings, typically because a critical defect was found in the image, and to introduce a replacement image. When the deferral of a software image is announced, customers are strongly encouraged to migrate from the affected image to the replacement image.

Software advisory: Cisco publishes a software advisory to announce the introduction of a solution to a defect. Cisco typically publishes this type of advisory when Cisco has confirmed that a defect does not affect general use of a Cisco IOS Software release. Although the original software image remains available for download, customers who could be impacted by the defect should upgrade to a replacement image.

Additional Resources and Tools

The following table (Table 10) summarizes some of the most useful Cisco resources and tools for evaluating, migrating to, and maintaining Cisco IOS Software and Cisco NX-OS Software releases:

Find detailed information about security issues that directly involve Cisco products and require an upgrade, fix, or other customer action. The Cisco PSIRT publishes Cisco Security Advisories to disclose vulnerabilities that have a SIR of Critical, High, or Medium.

Access Cisco Security Advisories and other types of publications that provide actionable intelligence for security threats and vulnerabilities in Cisco products and services and in third-party products.

Find suggested software for supported products based on filters such as product or platform, feature support, and software image. The tool provides suggestions based on software quality, stability, and longevity.

This document is part of the Cisco Security portal. Cisco provides the official information contained on the Cisco Security portal in English only.

This document is provided on an “as is” basis and does not imply any kind of guarantee or warranty, including the warranties of merchantability or fitness for a particular use. Your use of the information in the document or materials linked from the document is at your own risk. Cisco reserves the right to change or update this document without notice at any time.