Cisco ios and linux

IOL or IOS On Linux, also called IOU or IOS On Unix. IOL, is a simulator available for Cisco internal use only. IOL refers to the Linux version, compiled for i386 architecture. IOU refers to the Unix (Solaris) version compiled for Sparc architecture. The term IOU usually refers to IOL too.

Because IOL is an internal IOS version, IOL can be used by Cisco employees or by authorized customers only.

Upload the downloaded image to the EVE using for example FileZilla or WinSCP to: /opt/unetlab/addons/iol/bin/ .

Type following command to fix permissions:

IOL images must end with the “.bin” extension and must be executable. License must be stored under the same path.

IOU/IOL license is bound to the hostname and domain name of the server. A test should be made to check if IOU/IOL images can run properly.

Google for how to create iourc license file. Bellow is an EXAMPLE how it should look like:

Источник

Cisco IOS and Cisco NX-OS Software Release Reference Guide

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.

For Cisco Nexus 9000 and Cisco Nexus 3000 Series Software releases, see the Cisco NX-OS Software Strategy and Lifecycle Guide.

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.

The following table (Table 1) identifies and describes the primary software release families and trains for Cisco IOS Software and Cisco NX-OS Software. For the latest information about releases and hardware, see the Cisco Networking Software product page.

Table 1. Current Primary Software Release Families and Trains for Cisco IOS Software and Cisco NX-OS Software

Common Hardware Families and Platforms and Recommended Network Operating System Software

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. 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 also publishes Recommended Releases, which are updated as new releases mature. These documents can be located on Cisco.com by doing an Internet search for «recommended releases» site:cisco.com.

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.

Figure 1. Relationship Between Maintenance 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.

Figure 2. Code-Based Relationship Between Releases from the Cisco IOS Software Release 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.

Figure 4. Release Name Components—Cisco IOS Software Release 15M&T Train

The components are:

• Major release number: Indicates the applicable software release family.
• 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.
• Release type identifier: Indicates whether the release is an extended maintenance (M) or standard maintenance (T) 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.

Figure 5. Release Name Components—Other Cisco IOS Software Release 15 Trains

The components are:

• Main release number: Indicates the applicable software release family.
• 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.

Figure 6. Release Name Components—Cisco IOS XE Software Release 16 Trains

The components are:

• Train identifier: Also referred to as brand name, indicates the applicable software train—for example, Denali, Everest, or Fuji.
• 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:

Figure 7. Release Name Components—Cisco IOS XE Software Release 3E, 3S, 3SE, 3SG, and 3SP Trains

The components are:

• 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 the 3E train, select the appropriate release notes from the list of supported products on the Cisco IOS XE 3E Release Notes page.
• For the 3S train, see the Cisco IOS XE 3S–to–Cisco IOS Release Number Mapping table in Cisco IOS XE Release 3S Release Notes for Cisco ASR 1000 Series Aggregation Services Routers.
• For the 3SG train, see the Cisco IOS XE to Cisco IOS Version Number Mapping table in Cisco IOS XE 3.10.xE Release Notes for Cisco Catalyst 4500-X Series Switches.

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.

For more information about Cisco IOS XR Software packaging and package names, see Guidelines for Cisco IOS XR Software.

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.

Note: For Cisco Nexus 9000 and Cisco Nexus 3000 Series Software Release and Image-naming Convention information, see the Cisco NX-OS Software Strategy and Lifecycle Guide.

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:

1. 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.
2. 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.

The following figure (Figure 10) outlines the components of Cisco NX-OS Software release names for Cisco Nexus 7000 Series Switches and Cisco MDS 9000 Series Multilayer Switches prior to Release 7.3:

Figure 10. Release Name Components—Cisco NX-OS Software for Cisco Nexus 7000 Series, Cisco MDS 9000 Series Switches

The following table (Table 6) shows valid values for the platform designator in this naming convention.

Table 6. Cisco NX-OS Software Release Platform Designators

All applicable features, functions, and fixes in the platform-independent code are present in each platform-dependent release.

For more information about the release model and release-naming conventions for Cisco NX-OS Software, see Cisco NX-OS Software Life Cycle Policy.

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: Images with the universalk9 designation in the image name offer all Cisco IOS Software features, including strong payload cryptography features, such as IPsec VPN, Secure Sockets Layer (SSL) VPN, and Secure Unified Communications.
• 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.

Within each universal software image, features are grouped into feature sets. Administrators activate specific feature sets by using technology package licenses via Cisco Software Activation licensing keys. The feature sets are:

• 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)
• SEC: Provides support for security and VPN services and technologies, such as Cisco IOS Firewall, Dynamic Multipoint Virtual Private Network (DMVPN), Group Encrypted Transport VPN (GET VPN), intrusion prevention system (IPS), IPsec, and Secure Sockets Layer (SSL) VPN
• UC: Provides support for Unified Communications services and technologies, such as Cisco Unified Border Element, Cisco Unified Communications Manager Express, SRST, digital signal processor (DSP), voice gateway, and Voice Extensible Markup Language (VXML)
• DATA: Provides support for data services and technologies, such as Bidirectional Forwarding Detection (BFD), IP service-level agreement (IP SLA), Multiprotocol Label Switching (MPLS), Layer 2 VPN (L2VPN), Layer 2 Tunneling Protocol (L2TP) Version 3, and Resource Reservation Protocol (RSVP)

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)
• IP Base: Includes all the features in the LAN Base package plus support for edge IP routing (static, Routing Information Protocol [RIP], Enhanced Interior Gateway Routing Protocol [EIGRP] stub, and basic Protocol Independent Multicast [PIM]), Hot Standby Router Protocol (HSRP), Virtual Router Redundancy Protocol (VRRP), and Generic Routing Encapsulation (GRE) Tunneling
• IP Services: Includes all the features in the IP Base package plus support for full IP routing (EIGRP, Open Shortest Path First [OSPF], and PIM), Border Gateway Protocol (BGP), policy-based routing, Gateway Load Balancing Protocol (GLBP), high availability, Multi-VRF, WAN protocols, enhanced QoS functionality (Network-Based Application Recognition [NBAR]), and the Cisco Catalyst 6500 Virtual Switching System
• 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.

Figure 12. Cisco IOS XE Software Packaging for the Cisco ASR 1000 Series Route Processor (RP1)

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.

For more information about Cisco IOS XR Software packaging, see the Cisco IOS XR Release Naming section of this guide and Guidelines for Cisco IOS XR Software. For information about which features and components are included in a specific Cisco IOS XR Software package, see the release notes for the package.

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.

Note: For Cisco Nexus 9000 and Cisco Nexus 3000 Series Software Release and Image-naming Convention information, see the Cisco NX-OS Software Strategy and Lifecycle Guide.

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.
• Software release: The image contains Cisco IOS Software Release 15.4(3)M3.
• 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.

Figure 14. Components of Software Image Names—Cisco IOS XE Software Release 16 Trains

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

• Hardware: The image was built for a Cisco ASR 1002-X Router.
• 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.
• Software release: The image contains Cisco IOS XE Software Release Fuji 16.9.1.
• 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.

Figure 15. Components of Software Image Names—Cisco IOS XE Software Release 3E, 3S, 3SE, 3SG, and 3SP Trains

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

• Hardware: The image was built for a Cisco ASR 1002-X Router.
• 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.
• Software release: The image contains Cisco IOS XE Software Release 3.10.00.S.
• Cisco IOSd version: The image contains Release 15.3(3)S of the Cisco IOS daemon (IOSd).
• Release type: The image contains an extended maintenance release of Cisco IOS XE Software Release 3.10.00.S, as indicated by the ext 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 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.

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.
• Software release: The image contains Cisco IOS XR Software Release 6.1.4.
• 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.
• Software release: The image contains Cisco NX-OS Software Release 6.2(18).
• 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.

Figure 18. Lifecycle of Cisco IOS Software and Cisco NX-OS Software Releases

1. First customer shipment (FCS): The first day when the release is available to customers.
2. 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.
3. 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.
4. Software maintenance: The time period when Cisco Engineering may release any software maintenance releases or bug fixes for the release.
5. 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.
6. 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.
7. 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 XE Software release depends on the release type. As discussed in the Cisco IOS XE Software Release Naming section of this guide, each Cisco IOS XE Software release is classified as either a standard maintenance release, also referred to as a standard-support release, or an extended maintenance release, also referred to as an extended-support release. A standard maintenance release typically has a sustaining support lifetime of one year from the FCS date. An extended maintenance release typically has a sustaining support lifetime of two years from the FCS date. For more information about the support models and timelines for releases that derive from Cisco IOS XE Software 3E, 3S, 3SE, 3SG, and 3SP trains, see Cisco IOS XE Software Support Timeline to Cisco IOS XE Software Release 3.9S and Cisco IOS XE Software Support Timeline Starting with Cisco IOS XE Software Release 3.10S. For more information about the support models and timelines for releases that derive from Cisco IOS XE Software Release 16 trains, see the Cisco Community post, All you need to know about Cisco IOS XE Software 16.x Releases.
• 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 Life Cycle Policy.

Note: For Cisco Nexus 9000 and Cisco Nexus 3000 Series Software Release and Image-naming Convention information, see the Cisco NX-OS Software Strategy and Lifecycle Guide.

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.

Cisco IOS Software

The following table (Table 7) provides examples of common migration paths for specific Cisco IOS Software releases:

Table 7. Example Migration Paths for Cisco IOS Software

Cisco IOS XE Software

The following table (Table 8) provides examples of common migration paths for specific Cisco IOS XE Software releases:

Table 8. Example Migration Paths for Cisco IOS XE Software

Cisco IOS XR Software

The following table (Table 9) provides examples of common migration paths for specific Cisco IOS XR Software releases:

Table 9. Example Migration Paths for Cisco IOS XR Software

Cisco NX-OS Software

The following table (Table 10) provides examples of common migration paths for specific Cisco NX-OS 7000 Series 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 10. Example Migration Paths for Cisco NX-OS 7000 Series Software

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 11) 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:

Table 11. Resources and Tools

Last updated: October 6, 2021

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.

Источник

Вам также может понравиться

Windows или Linux: Что лучше выбрать?

Есть много причин выбирать между Windows и Linux, но

Файл владелец изменить linux

Команда Chown в Linux Chown Command in Linux (File

Установка шлюза по умолчанию linux

Настройка сети вручную Содержание Краткое описание

Чем разбить диск для linux

ИТ База знаний Курс по Asterisk Полезно — Узнать IP —