Showing results for 
Search instead for 
Did you mean: 

IOS XR Release Strategy and Deployment Recommendation



The purpose of this document is to help you understand the IOS XR software release strategy and help you select the optimal IOS XR release for deployment in your production network.

Generic information on IOS XR release is available in the "Guidelines for Cisco IOS XR Software"document.

This documents provides an update and a recommendation for year 2020.


What Is An Extended Maintenance Release (EMR)

For us at Cisco it is very important to deliver the new features and hardware that your network requires, while at the same time maintain the high software quality. We are continuously investing efforts to improve the quality of our software and hardware. We are adjusting our culture, processes and practices to achieve that goal.

One of the key concepts in the software quality plan is the Extended Maintenance Release (EMR) introduced in IOS XR for the first time with the release 4.3.4.

Extended Maintenance Release (EMR) criteria:

  • No new software features
  • No new HW support
  • Incoming bug rate to drop by at least 90% from peak rate for that release.
  • Zero critical bugs.

By choosing the EMR for deployment, you are making the optimal choice. We will be happy to work with you on EMR early field trials or any other way to help synchronise your upgrade/migration plan with the EMR release schedule.


By selecting the EMR you are not only making sure that you are getting the best quality release, you are also selecting a release with the highest deployment rate.


Benefit Of Upgrading To A Most Recent EMR

Software Stability

  • Improved Software Stability:
    • Reduced number of SMU’s and SMU’s that need reboot. 59% Improvement, normalizing by Installed base, in the last 3 years.
    • 42% Improvement on Sev. 1&2 SW defects (2019 Vs. 2017).
  • Improved system debuggability


  • Enhanced Network Availability
  • Reduced Time to Restore
  • Reduced Business Impact and operational costs

Software Quality

  • Improved SW Quality:
    • Reduced Number of SW Incidents 58% Improvement of 6.4.2 Vs. 5.3.3. normalizing SW defects by Installed base (3 Years timeframe)
    • 40% Improvement of 6.4.2 Vs. 5.3.4. (≈ 2 years timeframe)
    • Improved system debuggability


  • Enhanced Operational Excellence
  • Reduced time to Resolution
  • Reduced Operational Cost

Vulnerability Risk:

  • Reduced PSIRT exposure

New functionalities:

  • New Features for new Services



Managing Your IOS XR Install Base

Keeping your IOS XR installation up to date with is very important. We continue providing software patches through Software Maintenance Units (SMUs) and Service Packs (SPs).


Manual SMU and SP install is a thing of the past since the introduction of the CSM Server. CSM Server is a web based server side automation and orchestration framework designed to ease the SW maintenance for all IOS XR platforms. After installing CSM Server 4.0, in-application upgrade is available for keeping your CSM Server application up to date.


To get the glimpse of the CSM Server we highly recommend to watch the _video_. CSM Server distribution comes with a documentation included, but you can also read more about it on _supportforums_.


Another benefit of deploying EMR is that more software patches are available compared to other releases. Number of software patches (SMUs) available per release is directly proportional to the number of our customers running the release. Also, on EMR we try to provide, when technically feasible, SMUs for issues affecting the usability of IOS XR, not only for critical issues directly impacting the services. Service Packs (SPs) are also built more frequently compared to non-EMR releases.


SMU and SP concepts are explained in the "Service Pack Overview for Routers that Run Cisco IOS XR" document.


Service Packs on are built on EMR every 8 weeks. On non-EMR builds are on-demand, but never more frequent than on EMR.


Before the introduction of CSM Server, deriving the optimised SMU list for a given install base was a challenging task. Service Pack (SP) was introduced to deliver on operational simplicity.


On 32-bit IOS XR, SP is a single package that can be installed on the system regardless of the active base packages. For example, if BNG package is not active on the system, all BNG elements in the SP are ignored during SP activation.


On 64-bit IS XR, SP is a tarball containing the optimised set of production SMUs posted to date. User should unpack the tarball and install only the RPMs of interest individually or by re-packaging them into a new tarball. Golden ISO image, comprising base packages and SMUs is also an interesting option on 64-bit IOS XR.


If you are using CSM Server to manage your install base, CSM Server optimises the SMU set for you, allows you to define "software profiles" (set of base packages plus SMUs or SP) and allows you to easily install the same profile on multiple nodes. You can also run conformance reports. With this CSM Server functionality, the choice between SMU and SP is really down to a user preference. CSM Server delivers the same operational simplicity for users who prefer SMU over SP or vice versa.

64-bit vs 32-bit IOS XR

The 64-bit flavour of IOS XR is available for ASR9000 starting from XR release 6.1.2. Up to and including IOS XR major release 6.6.x,  there is no different release number for the 32-bit and 64-bit IOS XR. The 64-bit software packages are designated by the 'x64' in the package name (e.g. ASR9K-x64-iosxr-px-6.1.2.tar). Split between 32-bit and 64-bit release numbering starts with IOS XR major release 7.0.x. As a consequence, the 7.x.x releases are available only for 64-bit capable platforms. Support for 32-bit IOS XR on ASR9000 continues with 6.7.x, 6.8.x, etc.


For more information, including the required minimum hardware for running 64-bit IOS XR on ASR 9000 platform, refer to the "Cisco ASR 9000 Series IOS XR 64 Bit Data Sheet".


CSM Server contains a module that seamlessly performs the migration from 32-bit XR to 64-bit XR. We highly recommend you to watch this short demo video.


New IOS XR platforms NCS500, NCS5000 and NCS5500 only support the 64-bit flavour.


Suggestions For Year 2020

For year 2020 our aim is to continue cutting down on the time between the first feature release (e.g. 6.2.1) and its corresponding EMR. At the same time, we want the EMR to meet our internal quality criteria.

Suggested releases for validation and deployment in calendar year 2020 are:

Platform Release Comment
ASR9000 6.6.3, 7.0.2

64-bit XR: 7.0.2

32-bit XR: 6.6.3; A9K-RSP440 must stay with 6.4.2 (EoS-EoL notice)

CRS 6.4.3 6.4.3 was released only for CRS
NCS540 7.0.2, 7.1.2  
NCS560 7.0.2, 7.1.2  
NCS5000 6.6.3 / 6.5.3, 7.1.2 6.6.3 as satellite, 6.5.3 for all other deployments
NCS5500 7.0.2, 7.1.2  
NCS6000 6.3.3  
XRv9000 7.0.2  


Note that 6.3, 6.4, 6.5 and 6.6 images are not  available for all XR platforms. Refer to below table for guidelines:

Platform support in XR releases 6.3.x, 6.4.x and 6.5.x
  6.3.x 6.4.x 6.5.x 6.6.x 6.7.x
7.0.x 7.1.x
ASR9000 Yes Yes Yes Yes Yes. 32-bit Yes. 64-bit Yes. 64-bit
CRS No Yes No Yes No No No
NCS540 Yes No Yes Yes No Yes Yes
NCS560 No No Yes Yes No Yes Yes
NCS5000 Yes Yes (satellite only) Yes Yes (satellite only) No Yes Yes
NCS5500 Yes No Yes Yes No Yes Yes
NCS6000 Yes Yes No No No Yes Yes
XRv9000 Yes Yes Yes Yes No Yes Yes


The following table shows the IOS XR release schedule planning for year 2020.

IOS XR tentative release schedule

Disclaimer: future release dates and numbers are tentative and may change without notice.

(*) LA == Limited Availability. If you need access to this release please contact your account team at Cisco

Release FCS
6.5.3 EMR March 2019 Posted
6.6.2 April 2019
Posted. LA(*) for some platforms.
6.6.25 May 2019 Posted. Available only for NCS5500 and NCS540 platforms.
7.0.1 Aug 2019 Posted. LA(*) for some platforms. 64-bit IOS XR.
6.6.3 EMR   Posted. 64-bit and 32-bit IOS XR.
7.1.1 Jan 2020 Posted. 64-bit IOS XR.
6.7.1 Jan 2020 Posted. 32-bit equivalent of 7.1.1. Available only for ASR 9000.
6.4.3 Mar 2020 Posted. Released only for CRS.
7.0.2 EMR Q1CY20 Posted. 64-bit only.
7.1.2 EMR Q3CY20 Posted. 64-bit only. EMR for all platforms except ASR9000(!).
6.7.2 Q3CY20 Posted. 32-bit equivalent of 7.1.2. Available only for ASR 9000.
7.2.1 Q3CY20 Posted. All platforms except ASR9000.
7.1.3 Q4CY20/Q1CY21 Planned. Only ASR9000, 64-bit.
6.7.3 Q4CY20/Q1CY21 Planned. Only ASR9000, 32-bit.
7.2.2 Q4CY20/Q1CY21 Planned. All platforms except ASR9000.


We hope you find this document useful. Happy roll-out of IOS XR!


Related Documentation



Hi, Aleksandar:


Is there a document that shows a simple upgrade procedure that goes from 6.6.2 to 6.6.3, for example?





I have found in some thread in the Community a comment by smilstea




We need to remember that 32-bit started in 2008 on ASR9K, and we have gone from 32-bit cXR to 64-bit eXR to XR7 (not the same as 7.0, eXR is still continuing) during that time.

What does especially the part XR7 not the same as 7.0 mean? So what is XR7? I have found a data sheet. From my understanding out of the datasheet XR7 ist what is following 6.x: (see chapter "A simplified architecture for the future"). And what is meant with "newer hardware platforms" where admin plane is not needed any more in this data sheet?

Cisco Employee



cXR is 32-bit based on QNX, with IOS XR running directly on HW.

eXR is 64-bit based on Linux, where IOS XR runs in a VM.

XR7 is also 64-bit based on Linux, but much leaner than eXR. XR7 is available only on Cisco 8000 Series products.


Hi Aleksandar,

I am upgrading my 9906 from 6.6.2 to 7.0.2 and Cisco keeps referring to "ASR9K_Upgrade_Downgrade_Procedure_IOSXR_Rel_702.pdf" but can't find this document anywhere. Is there a simple procedure to follow for manual upgrade?



Cisco Employee



That doc is part of the "ASR9K-x64-docs-7.0.2.tar" which you can also download from




Dear Aleksandar,

Is there any special procedure when upgrading ASR9K from

eXR 6.5.3 to 7.0.2?

So 64bit to 64bit but to release 7.x.

Is there any major difference between release 6 and 7 in 64bit train?

Thanks, Imre

Cisco Employee


hi Imre,

there are no special considerations when upgrading from 6.5.3 64-bit to 7.0.2 64-bit. The major release number 7 doesn't mean that there was any significant change in the IOS XR architecture on ASR9000. The difference between 7.0.2 and 6.6.3 is not greater than the difference between 6.6.3 and 6.5.3. The reason why '7' was introduced has to do with the following:

  1. all 7.x.x releases are 64-bit (32-bit continues with 6.7.x, 6.8.x)
  2. new flavour of 64-bit IOS XR (aka XR7) was introduced with Cisco 8000 Series 

The feature code is the same across all IOS XR flavours. The difference is in the underlying OS and install subsystem. 32-bit XR was using QNX, eXR is using Linux with VMs (ASR9000) or Linux containers (NCS platforms), the XR7 is also using Linux but without any VM/LXC.


Hope this helps,




Thank you for the quick answer.




Thanks for the guidance in this thread.

Actually we are upgrading an ASR9001 from 5.3.3 to 6.7.1 but facing an issue.

Here is an excerpt of the error:

#Error: Cannot proceed with the activation because of the following API incompatibilities:
Error: Checks failed for RP, ASR9001-RP, RP-GIMLI
Error: 3 APIs with consumers but no producers.
Error: platforms__viking__drivers__fc_fpga__api
Error: Required version(s) of platforms__viking__drivers__fc_fpga__api:
Error: Impacted card(s) RP-GIMLI:
Error: /disk0/asr9k-base-6.7.1/0x100000/bin/invmgr requires (V1.1)
Error: /disk0/asr9k-base-6.7.1/0x30207/bin/ds280br810_lib_test requires (V1.1)
Error: /disk0/asr9k-base-6.7.1/0x30207/lib/libds280br810.dll requires (V1.1)


Any idea how to solve this?

Should we go first to an intermediate version? 6.6.3?

I didn't see any upgrade path in the documentation.




Sylvian, that looks like it could be
CSCvj18407 cXR image upgrade may fail with pie installation due to unresolved api's

Current image is lower than 6.3.3, or the current image is 6.4.1
Target image version is higher than 6.6.6

First upgrade to 633/642/651, then upgrade to the target image.
OR, Turboboot upgrade to target image.

I could be wrong, but I believe the 9001 is an RSP 440, which means it can only be taken to 6.4.2.


It is wrong, ASR9001 has nothing to do with RSP440 and can be upgraded to 6.7.1


Thanks @mivens , I didn't catch this bug-id.


Upgrade to 6.4.2 is OK. Upgrade to 6.7.1 is planned for the coming days. If somebody is interested I can post the final result.


@philclemens1835 @dfischer_de I confirm, ASR9001 has nothing to do with RSP440.






@dfischer_de @Sylvain_Che 


Apologies for the misinformation.  I did ping Xander for some education on it, and it is indeed its own, somewhat unique, RP architecture.


Hello @Aleksandar Vidakovic 


First of all, I hope you're all right.


I would like to update my routers from version 5.5.4 / 6.3.3 to 6.6.3.
But I see that the new EMR will be released this year (6.7.2), do you consider that I should wait for the EMR or can I quietly deploy the 6.6.3?

Will there be a version 6.7.3?
My routers are ASR9001 (32-bit)


Thanks in advance,