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
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
Improved SW Quality:
Reduced Number of SW Incidents58% 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)
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.
Service Packs on are built on EMR every 8 weeks. On non-EMR builds are on-demand, but never more frequent than on EMR.
SMU vs SP
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.
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:
I need to come up with a baseline syslog script for XR and XE platforms and integrate them both with CoPP but the documentation I search doesn't cover both topics or how to change the port. I see some commands for switches to change the port but the ASR 9...
Hello everyone,We''ve just upgraded an ASR 9001 from version 4.3.4 to 5.3.4, and after "install activate" and reload, "install verify packages" resulted in this:[...] Info: /install/asr9k-base-4.3.4: [ERROR] Detected anomalies.[...]Info: Verification Summ...
I am trying to do a simple shaper with a basic scheduler to prioritize EF traffic across a link. With the policy that I have tried, I get an error upon commit "!!% 'DNX_QOSEA' detected the 'warning' condition 'Invalid egress policy, Cannot have both queui...