Managing Disk space on RSP-4G/RSP-8G (AKA RSP2)

[Eddie Chami]

Problem statement

==================

RSP-4G/RSP-8G systems have limited boot Disk Space(2G disk), leading to upgrade constrains when moving between Major Releases. Boot disk memory is not field upgradable. This document will discuss the options to ensure an upgrade is successful. The document will also cover options that can be undertaken to have a successful upgrade, the options are:

1. Disk Space Conservation – A best practice and should always be done
2. Flexible Disk Installs – Available from IOS XR release 4.3.4 onwards
3. Rebake an RSP2 in the lab – This option has opex drawbacks, as an RSP needs to be replaced in each location
4. Turboboot – This should be a last resort option.
5. When possible migrate to RSP-880, RSP-440 or RSP-LITE(Upgradable to RSP-440)

1 Disk Space Conservation
======================

The RSP2 diskspace is naturally split into two partitions (1.6G/0.4G). This can be altered and re-partitioning ratio changed to 1.9G/0.1G, hence increasing the available space to the XR installer by 300M. If not partitioned one needs to do so. The re-partitioning tool is available from Release 4.2.0 onwards, for Release 4.2.0-4.2.1, a hitless SMU(CSCub41271) can be installed to use the tool, the tool is integrated in 4.2.3. Executing the re-partitioning is not service impacting. Instructions on running the repartitioning tool: https://tools.cisco.com/bugsearch/bug/CSCub41271

Other methods to conserve disk: memory
===========================================

1. Remove the FPD pie on the running Release, as the FPD pie takes a considerable amount of diskspace, and once the FPDs have been upgraded the pie is no longer required. (Note: Auto FPD will not work if the FPD pie is not installed on upgrade, FPD update will need to be manually run after upgrade in this case). Removal of FPD pie on RSP-2 prior to 4.3.0 is not supported, since its bundled with the mini.pie.
   1. Identify the FPD pie, example: show inst ac sum | in fpd

    disk0:asr9k-fpd-px-4.3.4

2. Deactivate the FPD pie, example: “admin#install deactivate disk0:asr9k-fpd-px-4.3.4”
3. The changes need to be committed before being able to remove them. “admin# install commit”
4. Remove the FPD pie, example: “admin#install remove disk0:asr9k-fpd-px-4.3.4”

2. If the above step is followed, then upgrade to the target release without the FPD pie, once on the target release, install the FPD package, this saves about 500-600M of disk space during the upgrade.
3. Remove the superseded SMUs on the running release(This is advised to be done during a MW, as it maybe traffic impacting for some SMUs).
   1. Identify superseded SMUs using the optimize option of CSM. Partially superseded SMUs can’t be deactivated. CSM User Documentation:  http://www.cisco.com/en/US/docs/routers/asr9000/software/smu/csmuser.html
   2. Deactivate the superseded SMUs with “admin# install deactivate <smu>” or from 4.3.2 onwards can use cli “admin#install deactivate superseded”
   3. The changes need to be committed before being able to remove them. “admin# install commit”
   4. Remove the SMU,  “admin# install remove <smu>”
4. It’s a standard best practice to install SMUs of the target release during an upgrade in a single install operation. To overcome the disk space limitation, the install of the SMUs can be delayed till after the install of the target release is completed. At this point, the removal of the old release can happen and then followed by installing of the SMUs. It’s important to note, this does lead to two reloads. Here is an illustrations:
   1. Activate the target release without SMUs, example: “admin#install activate disk0:asr9k-mini-p-4.2.3”
   2. After bootup : “admin#install commit”
   3. Remove the old release if happy with the upgrade: “admin#install remove inactive”
   4. Install the SMUs of the new release “admin#install add active <New release SMUs/SP>”

2 Flexible disk installs
==================

With flexible disk installs both Disk0 and Disk1 on RSP-4G/RSP-8G(AKA RSP2) can be used as boot media. With that the operator now has 1.9Gx2 at their disposal. At any point in time a single IOS XR image can only be booted from one of the two disks. With this flexibility image A can run from Disk0, the upgrade to image B can be with Disk1 and so on. This option was introduced in 4.3.4.

More information:

http://www.cisco.com/c/en/us/td/docs/routers/asr9000/software/asr9k_r4-3/system_management/configuration/guide/b_sysman_cg43asr9k/b_sysman_cg43asr9k_chapter_0100.html#concept_4AD30BCA80FD484DAFCE08362851CC0D

3 Rebake RSP2 in the lab
====================

Prebake an RSP with target image + SMUs and use it to upgrade, if a rollback (downgrade) is needed use existing RSP, one can see this as an opportunity to buy/insert a newer processor (if scale or performance can justify the CAPEX). See option 5.

   a) If a spare RSP is found, upgrade an RSP in a non-production router with pies + SMUs and then use it to upgrade.
   b) Send the spare RSP to the site, remove old RSP with old image, use new RSP with new image+ SMUs.
   c) If a downgrade is later needed the existing RSP can be reinserted.

4 Turboboot
==========

Detailed version of Turbobooting is available in the Cisco Support Community link: https://supportforums.cisco.com/document/123576/asr9000xr-understanding-turboboot-and-initial-system-bring

1. Clear the ROM Monitor environmental variables on all RSPs:
unset BOOT
unset TFTP_FILE
sync
Repeat for each RSP in the system

2. Clear BOOT_DEV_SEQ_OPER and MIRROR_ENABLE ROM Monitor environment variables to disable disk mirroring.
unset BOOT_DEV_SEQ_OPER
unset MIRROR_ENABLE

3.Change the default behavior of RP in ROMMON to not reset in 30 minutes
Rommon> priv
Rommon> diswd <- Disable the CPU watchdog

4. On the RSP, set the environment variables that configure the Management Ethernet interface for use in ROM Monitor mode. Repeat for each RSP and set it with unique IP address:
IP_ADDRESS=ip_address
IP_SUBNET_MASK=mask
DEFAULT_GATEWAY=ip_address

5. On the RSP, set the TFTP environment variables. Repeat for each RSP:
TFTP_VERBOSE=1
TFTP_RETRY_COUNT=4
TFTP_TIMEOUT=6000
TFTP_CHECKSUM=1
TFTP_SERVER=server_ip_addr

6. Set the Turboboot variables on one RSP ONLY :
TURBOBOOT=on,disk0,format
sync

7. On this RSP, boot the vm image located on the TFTP server: (Works only with the VM image, not the TAR file)
boot tftp://server/directory/filename

8. Now that the system has come up with the desired software, additional optional packages can be 'installed and committed'

5 Migrate to RSP-Lite, RSP-440 or RSP-880
===================================

With the EoS of RSP-4G/RSP-8G(AKA RSP2), migrating to a new RSP is recommended

EOS of RSP2 http://www.cisco.com/c/en/us/products/collateral/routers/asr-9000-series-aggregation-services-routers/eos-eol-notice-c51-734029.html

Possible upgrade options is the new RSP-880, RSP-440 or the LT version with is software upgradable to RSP-440.

http://www.cisco.com/c/en/us/products/collateral/routers/asr-9000-series-aggregation-services-routers/data_sheet_c78-674143.html?cachemode=refresh

[Eddie Chami]

Considering that your on 390 you should verify all your cards have 4G or ram. We did ship cards with 2G ram on the early days, those won't boot 513. You will need to RMA the card if it has 2G.

Turbo booting uses disk0: that's 2G and you'll be ok 513 will fit there. Make sure you repartition after your on 513. A portion of the 2G is reserved and you can get that back with repartition.

[heleon]

Thanks a ton Eddie !!

You are a Master!!

[marpina]

Hi all

I see if the FPD pie is removed support the RMA, but what happend if the customer change the HW

if there is MOD80 then customer replace for a MOD160 when there is not FPD pie. Actually the customer is moving from 4.2.3 to 5.3.4 finally.

is it not necessary to upgrade the FPD ?

best regards

marcelino

[00u1ab28axbOOzhqE5d7]

Is there a way to copy the  mini.vm file or the necessary file to do a turboboot from disk0 on the router to a usb so a clean install can be performed . When i list the files on the drive0 it is mostly directories so im not sure if i am copying the correct .vm file?  Also curious if the mini.vm should be a directory or file when you enter mediaboot usb:/release_mini.vm? So in essence, is there a way to copy the file(s) required from the router to do a clean turbo boot?