This article covers these different releases and aims to give a single location where network engineers can look to figure out what the different releases mean. Although this is not an exhaustive list of every Cisco version, it does cover the most commonly used versions. One term that is often used is the IOS release type.
With versions of IOS earlier than 15, a specific image could be considered one of the following four different release types:. Early Deployment ED : These releases provide both new features and new platform support in addition to bug fixes. Limited Deployment LD : These releases do not include any new features or platform support but do include bug fixes. General Deployment GD : These releases can be used anywhere in a customer network with the same feature and functionality requirements.
These tend to be stable on almost all platforms. Maintenance Deployment MD : These releases are used to provide additional support for bug fixes and ongoing software maintenance. New releases will be considered either ED or MD. The IOS train paths have also been consolidated. With IOS 15 and later, the code bases will be consolidated. MD releases called M releases, or extended release will be released and have a month support window, whereas ED T releases, or standard release will have a month support window.
A number of different versions exist within each release of IOS. This article takes a look at a few of these and how what they are used for. With IOS Version 12, many different sub-versions of IOS exist, including specialized support for specific platforms; the next few sections cover a couple of the most common. IOS Version 12 has a few different ways to notate version, including those shown in Figure 1. The 12 base versions are also referred to as the mainline release of a version.
These releases tend to be the most stable and include support for most of the available platforms. Other more specialized versions of IOS are rolled into the mainline as an update when they have been sufficiently tested. They go through the release process shown in the previous section. The T train is used to add the newest features and platforms. After the software has been tested thoroughly, it is rolled into the mainline release.
Many different IOS versions provide support for specific platforms. The ones shown in the section name are an incomplete list but do show some of the common examples. As with IOS version 12T, version 15T is focused on new features and platforms and is supported for a shorter amount of time than the maintenance releases.
After 15T releases have been tested thoroughly, they are wrapped into the next 15M release. As with IOS Version 12, IOS Version 15 is going to have a number of different versions that are specific to new equipment that needs to support new features specific to the platform.
The way that Cisco has named their IOS packages has changed over time. With IOS Version Figure 3 shows the eight different packages that are available. If you have the output of a show version command from your Cisco device, you can use the Cisco CLI Analyzer registered customers only in order to display potential issues and fixes.
In order to use this tool, you must be a registered customer, be logged in, and have JavaScript enabled. It is important to check for feature support, especially if you plan to use recent software features. If you want to keep the same features as the version that currently runs on your router, and you are not sure which feature set you use, issue the show version command on your router. The "JS" is the feature set. In this example, J stands for "Enterprise" and S stands for "Plus".
With this knowledge, you can choose a similar feature set. In order to find out which Cisco IOS Software supports all of the features you plan to use, it is best to use the Cisco Software Research registered customers only , which allows you to search by feature s or by release, and it even allows you to compare two releases. Write down the different software versions that meet your requirements and that are compatible with your hardware. All of them are fine as long as they support your hardware, contain the features you want, and are compatible with the memory of your router see Memory Requirements.
Here are some general recommendations and guidelines to make it easier for you:. C is the maintenance version.
A higher maintenance number means more bug fixes. 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.
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 Figure 5. 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. 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 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 week interval after the FCS date for the release. The second two rebuilds are released at week intervals thereafter. Consequently, Release 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. 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. 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.
This modular architecture increases network resiliency by distributing operating responsibility among separate processes.
Figure 7. 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:. 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. 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. This ID is inserted between the release and architecture values in the filename. Cisco NX-OS Software is a data-center-class operating system that provides high availability with a modular design. 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 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:. Figure The following table Table 6 shows valid values for the platform designator in this naming convention. All applicable features, functions, and fixes in the platform-independent code are present in each platform-dependent release.
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 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 packages provide similar functionality and logical feature parity across platforms, while also meeting the unique requirements of each platform. Cisco Show Stacks Command. Processor board ID , with hardware revision Bridging software. TN Emulation software. The following paragraph focuses on the general output of this command: On the first few lines of output, the show version command displays the IOS version number and its internal name.
0コメント