Contents

Introduction

Background Information

Problem: Insufficient to back up chassis key value to run for same configuration on the same node.

Solution

UPDATE  for Ultra-M upgrade procedure

Introduction

This document describes how to back up .chassisidfile (chassis ID) on StarOS releases 20 and higher.

Background Information

The chassis key is used to encrypt and decrypt encrypted passwords in the configuration file. If two or more chassis are configured with the same chassis key value, the encrypted passwords can be decrypted by any of the chassis sharing the same chassis key value. As a corollary to this, a given chassis key value cannot decrypt passwords that were encrypted with a different chassis key value.

The chassis key is used to generate the chassis ID which is stored in a file and is used as the primary key for protecting sensitive data (such as passwords and secrets) in configuration files

For release 15.0 and higher, the chassis ID is an SHA256 hash of the chassis key. The chassis key can be set by users through a CLI command or via the Quick Setup Wizard. If the chassis ID does not exist, a local MAC address is used to generate the chassis ID.

For release 19.2 and higher, the user must explicitly set the chassis key through the Quick Setup Wizard or CLI command. If it is not set, a default chassis ID using the local MAC address is generated. In the absence of a chassis key (and hence the chassis ID), sensitive data does not appear in a saved configuration file.

The chassis ID is the SHA256 hash (encoded in base36 format) of the user entered chassis key plus a 32-byte secure random number. This assures that the chassis key and chassis ID have 32-byte entropy for key security.

If a chassis ID is not available encryption and decryption for sensitive data in configuration files do not work.

Problem: Insufficient to back up chassis key value to run for same configuration on the same node.

Due to the change in behavior starting with release 19.2, it is not sufficient anymore to back up the chassis key value to be able to run the same configuration on the same node.

Moreover, because of the random 32 byte number attached to the configured chassis key, there are always different chassis IDs generated based on same chassis keys.

That is the reason why cli command chassis keycheck is concealed now since it always returns negative even if the same old key is entered.

To be able to recover a StarOS machine from a saved configuration (when, for example, all contents of the /flash drive were lost) it is required to backup the .chassisid (where the StarOS stores the chassis ID)

The chassis ID is stored in /flash/.chassisid file on StarOS hard drive. The easiest method of backing up this file is to transfer it via some file transfer protocol to a backup server:

As you see the .chassisid file is a hidden one and with newer releases it is not possible to do file management operations with hidden files. For example, this error is displayed with release 20.0.1:

[local]sim-lte# copy /flash/.chassisid /flash/backup

Failure: source is not valid.

[local]sim-lte#

Or:

[local]sim-lte# show file url /flash/.chassisid

Failure: file is not valid.

Solution

There is still a way to access this file via this procedure:

Step 1. Ensure the .chassisid file is present in /flash/.chassisid.

[local]sim-lte# dir /flash/.chassisid

-rw-rw-r--    1 root     root           53 Jun 23 10:59 /flash/.chassisid

8       /flash/.chassisid

Filesystem           1k-blocks      Used Available Use% Mounted on

/var/run/storage/flash/part1   523992    192112    331880  37% /mnt/user/.auto/onboard/flash

Step 2. Login into hidden mode.

[local]sim-lte# cli test-commands

Password:

Warning: Test commands enables internal testing and debugging commands

USE OF THIS MODE MAY CAUSE SIGNIFICANT SERVICE INTERRUPTION

[local]sim-lte#

Note: If there is no hidden mode password configured, configure it with this:

[local]sim-lte(config)# tech-support test-commands password <password>

Step 3. Start a debug shell.

[local]sim-lte# debug shell

Trying 127.0.0.1...

Connected to localhost.

Escape character is '^]'.

Cisco Systems QvPC-SI Intelligent Mobile Gateway

[No authentication; running a login shell]

Step 4. Move in the /flash directory. Verify if the file is there.

sim-lte:ssi#

sim-lte:ssi# ls

bin cdrom1 hd-raid param rmm1 tmp usr

boot dev include pcmcia1 sbin usb1 var

boot1 etc lib proc sftp usb2 vr

boot2 flash mnt records sys usb3

sim-lte:ssi#

sim-lte:ssi# cd flash

sim-lte:ssi# ls -a

. ldlinux.sys restart_file_cntr.txt

.. module.sys sftp

.chassisid patch staros.bin

crashlog2 persistdump syslinux.ban

crsh2 rc.local syslinux.cfg

Step 5. Copy the hidden file to a non-hidden one.

sim-lte:ssi# cp .chassisid chassisid.backup

sim-lte:ssi#

sim-lte:ssi#

sim-lte:ssi# ls

chassisid.backup patch staros.bin

crashlog2 persistdump syslinux.ban

crsh2 rc.local syslinux.cfg

ldlinux.sys restart_file_cntr.txt

module.sys sftp

Step 6. Exit the debug shell. You should be able to transfer the backup file created without any issues.

sim-lte:ssi# exit

Connection closed by foreign host.

[local]sim-lte#

[local]sim-lte# copy /flash/chassisid.backup /flash/chasisid.backup2

********************************************************************************

Transferred 53 bytes in 0.003 seconds (17.3 KB/sec)

[local]sim-lte#

[local]sim-lte#

[local]sim-lte# show file url /flash/chassisid.backup

1ke03dqfdb9dw3kds7vdslvuls3jnop8yj41qyh29w7urhno4ya6

UPDATE  for Ultra-M upgrade procedure

Upgrading N5.1 to N5.5  will destroy the vpc instance and OSP. Before initiating the upgrade procedure we should backup vPC configuration file and chassis-id if we are to re-use them.

Step 1. backup the chassisid  and last configuration file :

bash-2.05b# ls -alrt

-rwxrwxr-x 1 root root 53 Jul 11 14:43 .chassisid

-rwxrwxr-x 1 root root 381973 Jul 11 14:41 GGN-2017-07-28.cfg

from copied file :

cpedrode@CPEDRODE-xxxxx:~/Desktop$ more 2017-07-28.chassis-id

1swbwpd8fd8ca3kf33kn6qxb2h33ihfkqu1tu7x1ndf82znag1b5^@

Note:  the configuration file will have a derived key from .chasssisid:

[local]GGN# show configuration url /flash/GGN-2017-07-28.cfg | more

Monday July 11 14:59:34 CEST 2016

#!$$ StarOS V21.1 Chassis c95bf13f030f6f68cae4e370b2d2482e

config

Step 2. Procede with Ultra-M upgrade

Step 3. Once  system has been upgraded and StarOS vpc CF bootup, copy  chassisid (the regular file) and configuration file (make sure the proper O&M ip address is also changed) to /flash/sftp  (StarOS >R20)

Step 4. Backup the hidden default .chassisid  file from /flash  in "test-command" mode and delete it.

Step 5. Copy the chassisid file from /flash/sftp  into /flash in hidden mode as ".chassisid". Copy  the configuration file as well

Note: you can check the derived key issuing cli -  show configuration url /flash/xxxxxx.cfg | more and compare it with the backup config file

Step 6. Add the boot priority pointing to the new configuration file

Note: At this point StarOS will give an error:

[local]GGN(config)# boot system priority 6 image /flash/staros.bin config /flash/GGN-2017-07-28.cfg

Monday July 28 08:45:28 EDT 2017

Warning: Configuration was generated using a different chassis key, some encrypted information may not

be valid

If you have followed the correct steps,  you will have a config file with a Chassis derived key equal to the backup configuration file and a chasssisid equal to the backup chasssisid.

Note that when you  view the chassisid file it will append the  PS1 prompt :

bash-2.05b# cat .chassisid

1swbwpd8fd8ca3kf33kn6qxb2h33ihfkqu1tu7x1ndf82znag1b5bash-2.05b#

Step 7. Reboot vPC

At this point, the system should reboot and you may use the login credentials of the backup configuration file.