This guide is meant to provide answers to some of the common install questions and provide a basic overview of the install architecture XR employs.
IOS runs a monolithic kernel and a single .bin file. XR runs a microkernel and uses packaging, similar to Linux, to allow the user to choose which features they want loaded and to enable patching of individual components through SMUs. Upgrading IOS involves putting a new .bin on the device and reloading. Upgrading XR is done through an upgrade process.
This is published in the release notes
From time to time there have been minor differences such as integrating the FPD package into the mini.pie file and taking lawful intercept out of the mini file, but for the most part this list does not change. Note that the mini package is a composite package with multiple packages such as OS, admin, base, and forwarding included.
The mini.vm is used for turboboot. See https://supportforums.cisco.com/docs/DOC-29251 for more information on turboboot.
Upgrades are performed using, at a minimum, the install add, install activate, and install commit commands. It is recommended to check the upgrade guides listed here http://www.cisco.com/web/Cisco_IOS_XR_Software/index.html for any caveats and more detailed steps.
Install add decompresses the packages into memory on the dSC and then concurrently writes to the boot device of all management nodes, typically disk0:.
Examples of management nodes would be RSP0, RSP1, SC0, and SC1. Note that SCs are used in CRS multichassis.
The opposite of this is install remove which also has no impact.
This is a way to prepare the router for upgrade without affecting the running executables, this helps to divide the install process into three basic phases. It is recommended to perform install add before the maintenance window.
While some people may wish to keep multiple install points on the router, other people may prefer to remove anything not currently used.
We can remove all packages which are 'added' but not 'active' via 'admin install remove inactive'
This is where all the magic happens! Install activate changes what executables the router is running. Depending on the type of SMU/upgrade method the effects of the install could be hitless, a process restart, router reload, or ISSU.
Note: The opposite of this is install deactivate and has the same implications, meaning a reload may happen.
This is how we keep the running packages persistent across reloads after performing an install activate/deactivate. This command is much quicker than install add or activate as only metadata has to be updated. There is no impact on the currently running packages. Note that during a maintenance window this can be omitted until the end just in case a rollback might be needed, with this a reload of the router will cause the router to go back to the previous code.
Downgrades are essentially the same process as upgrades but with different caveats for different releases. In some cases we can just reload the router, if install commit has not been used, or even use a rollback.
One thing to remember is that PX code cannot be downgraded to P. This is the case with CRS-3 -> CRS-1 and ASR9K 4.3.0+ -> pre-4.3.0. On CRS any PX component requires the PX image, that being the fabric, LCs, or PRP, or from 4.2.0 onwards. On ASR9K PX pre-4.3.0 is only needed for the RSP440, starting with 4.3.0 both P and PX based systems will use PX.
Patching is done through the concept of SMUs, see https://supportforums.cisco.com/docs/DOC-28812 for more information. To summarize a SMU is a patch which changes a few lines of code in a particular component. C-SMUs, umbrella SMUs, and service packs touch multiple components.
Yes, we recommend this to save time.
The upgrade of an nV Edge System can be through regular install and having both racks reload at the same time, or through the use of the nV Edge Upgrade script which is recommended for many reasons.
See https://supportforums.cisco.com/docs/DOC-34114#13_Cluster_RackByRack_Upgrade_ for more information.
The short answer is no. The longer answer is that we do support release to release ISSU for some releases, and we have been increasing the number of SMUs which are ISSU. NG-XR (NCS6K) will support full ISSU. Support can be found here for ASR9K. http://www.cisco.com/web/Cisco_IOS_XR_Software/pdf/ASR9K_ISSU_Overview.pdf
Recommended SMU packs, C-SMUs, umbrella SMUs, and even service packs should be considered a minimum. Beyond that it is recommended to use the CSM tool to determine what you need.
CSM is Cisco Software Manager and can be used to manage SMUs and be alerted when new SMUs are posted. This tool can be downloaded from the downloads section on cisco.com
A service pack is a collection of every SMU to-date for a particular release rolled up into one package. The advantage of service packs, for some, is that it makes patching easier and less trivial. The downside is that once you go to service packs you have to stay with service packs. More information to come soon.
When starting an install operation (e.g. add, activate, commit) the synchronous keyword can be given and allows the install operation to complete before the CLI prompt is returned. If the synchronous keyword is not given then the CLI prompt is returned and the install happens in the background. If you then want to see the progress of an installation when in asynchronous mode use ‘show install request’ or attach to the install operation with ‘install attach’ which is similar to using the synchronous keyword.
Yes, this really comes down to disk space and dependencies though.
Yes, as long as the current release you are running supports auto-FPD.
This information is in the readme file for the tar but also can be checked via CLI.
Before performing install add this can be checked with 'admin show install pie-info <filename> detail' under 'Restart information'
If the install add has already been performed then 'admin show install package <package> detail' can be used
If the synchronous option was used then hit 'ctrl+c'
If asynchronous mode was used then we can use 'admin install abort'
Note that only activation, deactivation, and rollback operations can be aborted.
If for some reason it is suspected that corruption might have taken place then 'admin install verify' commands can be used to determine this, and can even repair the corruption in some instances. This is typically used by TAC.
No, once an RP is active and the dSC all other RPs in the same or different chassis will look to the dSC for information on booting. The dSC is determined on bootup of the entire system. Once an RP finds that they are not dSC they will sync packages, meta-data, and configuration files as needed.
While install does automatically detect and validate the MD5s this can also be done with ‘show md5 file’ using the absolute path.
An example would be:
RP/0/RSP0/CPU0:ASR9001#show md5 file /harddisk:/asr9k-asr9000v-nV-px.pie-4.3.1
Tue Feb 11 16:46:19.069 EAST
Install operation 120 '(admin) install activate disk0:asr9k-services-p-4.2.3
disk0:asr9k-mini-p-4.2.3 disk0:asr9k-optic-4.2.3 disk0:asr9k-video-p-4.2.3
synchronous test' started by user 'admin' via CLI at 20:40:51 UTC Tue Feb 26 2013.
Warning: No changes will occur due to 'test' option being specified. The following is the
predicted output for this install command.
Error: Cannot proceed with the activation because of the following package
Error: asr9k-mgbl-supp-4.2.1 needs iosxr-fwding-4.2.1, or equivalent, to be active on
the same nodes.
Error: Suggested steps to resolve this: Error: - check the installation instructions. Error: - activate or deactivate the specified packages on the specified nodes. Install operation 120 failed at 20:41:23 UTC Tue Feb 26 2013.
For this check to see what packages are currently active via ‘show install active summary’ and compare this to the v2 packages you are trying to activate.
RP/0/RSP0/CPU0:asr9k#admin show install active Wed Feb 27 15:05:19.796 UTC Secure Domain Router: Owner Node 0/RSP0/CPU0 [RP] [SDR: Owner] Boot Device: disk0: Boot Image: /disk0/asr9k-os-mbi-4.2.1.CSCub42561-1.0.0/0x100000/mbiasr9k-rp.vm Active Packages: disk0:asr9k-p-4.2.1.CSCuc26944-1.0.0 disk0:asr9k-p-4.2.1.CSCub93663-1.0.0 disk0:asr9k-p-4.2.1.CSCub42561-1.0.0 disk0:asr9k-p-4.2.1.CSCua74062-1.0.0 disk0:asr9k-p-4.2.1.CSCua47910-1.0.0 disk0:asr9k-p-4.2.1.CSCua16764-1.0.0 disk0:asr9k-p-4.2.1.CSCua04907-1.0.0 disk0:asr9k-mini-p-4.2.1 disk0:asr9k-optic-4.2.1 disk0:asr9k-doc-p-4.2.1 disk0:asr9k-services-p-4.2.1 disk0:asr9k-k9sec-p-4.2.1 disk0:asr9k-video-p-4.2.1 disk0:asr9k-mpls-p-4.2.1 disk0:asr9k-mgbl-p-4.2.1 disk0:asr9k-mcast-p-4.2.1 disk0:asr9k-p-4.2.1.CSCua14945-1.0.0 disk0:asr9k-p-4.2.1.CSCtz62914-1.0.0 disk0:asr9k-p-4.2.1.CSCub98258-1.0.0 disk0:asr9k-p-4.2.1.CSCub27892-1.0.0 disk0:asr9k-p-4.2.1.CSCtz63248-1.0.0 disk0:asr9k-p-4.2.1.CSCuc06881-1.0.0 disk0:asr9k-p-4.2.1.CSCub96985-1.0.0 disk0:asr9k-p-4.2.1.CSCty18600-1.0.0 disk0:asr9k-p-4.2.1.CSCub09558-1.0.0 disk0:asr9k-p-4.2.1.CSCub68512-1.0.0
The following packages are active: mini, optic, doc, services, k9sec, video, mpls, mgbl, mcast
The v2 activation we tried only had mini, optic, services, video, mpls, and mcast
Here the solution is to include the doc, k9sec, and mgbl packages as well in the activation command.
Mar 07 21:41:03.431 : Install (Node Preparation): Completed sync of all
packages and meta-data.
Insthelper encountered a fatal error condition, and is exiting: Operation
(Failed to set up node), Error value = (2), Error string =
(No such file or directory)
This indicates an error copying either the packages or meta-data to the RSP and means there is some kind of ‘corruption’. One example of where this is seen is when an upgrade was performed and CSCua50217 was not installed.
The corruption can be verified with 'admin install verify'
This is typically caused by a tar file which the filesystem cannot handle. For example QNX4 has a limitation of 2GB-1B for a single file.
More information can be found here