When a system is started for the first time, the boot.sys file is configured to use the normal boot mode and load the operating system software image from the /flash directory.

There is no CLI configuration file contained on the local file system. This causes the system to automatically start its CLI-based Quick Setup Wizard upon the first successful boot. Refer to Getting Started for more information on using the Quick Setup Wizard.

Use the commands in this section to manage and organize the local file system.

A pre-existing CLI configuration file is any .cfg file created to provide utility functions (such as clearing all statistics during testing) or created off-line using a text editor. There may be pre-existing configuration files stored on the local file system that can be applied to a running system at any time.

Caution

If a configuration file is applied to a system currently running another CLI configuration, any like contexts, services, logical interfaces, physical ports, IP address pools, or other configured items will be overwritten if the same command exists in the configuration file being applied. Take caution to ensure that you are knowledgeable of the contents of the file being applied and understand what the service ramifications are if a currently running command is overwritten. Also note that changes will not be saved automatically.

A CLI configuration file, or script containing CLI commands, can be applied to a running system by entering the following command at the Exec mode prompt:

[local]host_name# configure url [ verbose ]

url specifies the location of the CLI configuration file to be applied. It may refer to a local or a remote file.

The following command applies a pre-existing CLI configuration file named clearcmds.cfg in the /flash directory.

[local]host_name# configure /flash/clearcmds.cfg

This section describes how to view a variety of files.

The local-boot method uses software image and configuration files stored locally on the system. On system startup or reboot, the system looks on one of its local devices or /hd-raid for the specific software image and accompanying configuration text file. When using the local-booting method, you only need to configure boot stack parameters.

To view the boot stack entries contained in the boot.sys file run the Exec mode show boot command.

The examples below shows the command output for a local booting configuration. Notice that in these examples both the image file (operating system software) and configuration file (CLI commands) are located on the /flash device.

boot system priority 18 \
    image /flash/15-0-builds/production.45666.bin \
    config /flash/general_config.cfg
 
boot system priority 19 \ 
    image /flash/15-0-builds/production.45717.bin \
    config /flash/general_config_3819.cfg
 
boot system priority 20 \
    image /flash/15-0-builds/production.45069.bin \
    config /flash/general_config_3665.cfg

boot system priority 18 \
    image /flash/16-1-builds/asr5500-16.1.3.bin \
    config /flash/general_config.cfg
 
boot system priority 19 \ 
    image /flash/16-1-builds/asr5500-16.1.1.bin \
    config /flash/general_config_3819.cfg
 
boot system priority 20 \
    image /flash/16-1-builds/asr5500-16.1.0.bin \
    config /flash/general_config_3665.cfg

The example below shows the output for a combination network booting and local booting configuration. Notice in this example that the first two boot stack entries (Priorities 18 and 19) load the image file (operating system software) from an external network server using the Trivial File Transfer Protocol (TFTP), while all configuration files are located on the /flash device.

boot networkconfig static ip address mio1 192.168.1.150 netmask 255.255.255.0
boot delay 15
boot system priority 18 image tftp://192.168.1.161/tftpboot/image_version.bin \config /flash/general_config.cfg
boot system priority 19 image tftp://192.168.1.161/tftpboot/image_version.bin \config /flash/general_config.cfg
boot system priority 20 image /flash/image_version.bin \config /flash/general_config.cfg

show boot initial-config

[local]host_name# show boot initial-config
Initial (boot time) configuration:
      image tftp://192.168.1.161/tftpboot/image_version.bin \
       config /flash/config_name.cfg
      priority 1

If priority 1 is in use, then you must renumber the existing entry(ies) to ensure that at least that priority is available. The maximum number of boot stack entries that can be contained in the boot.sys file is 10. If there are already 10 entries in the boot stack, you must delete at least one of these entries (typically, the lowest priority) and, if necessary, renumber some or all of the other entries before proceeding. Refer to Deleting a Boot Stack Entry for more information.

configure
 boot system priority number image image_url config cfg_url

Synchronize the local file systems on the CF VMs with the following command:

filesystem synchronize all

This procedure details how to remove an individual boot stack entry from the boot.sys file. Make sure you are at the Exec mode prompt and enter the following commands:

configure
   no boot system priority number

Where number specifies the boot priority used for the boot stack entry. This command removes that specific entry from the boot stack, causing the boot.sys file to be overwritten.

The operating system can be configured to provide services and perform pre-defined functions through commands issued from the CLI.

For StarOS releases 20.0 and higher, a starfile image must be signed with an REL key before being released. A deployable image will be signed with an REL key having a ".bin.SPA" extension, where "A" identifies the revision level of the signing key. For example, asr5500-20.0.0.bin.SPA. If a signing key becomes compromised, a new key is created and the revision level increments to "B".

For StarOS releases 20.0 and higher Trusted images have been introduced. The difference between a Trusted build and a Normal build is the absence of unsecure programs ftpd, telnet and tcpdump, as well as the addition of a staros.conf file for security options. Trusted images are identifiable by the presence of "_T" in the platform name. For example, asr5500_T-20.0.0.bin.SPA.

The software version information can be viewed from the CLI in the Exec mode by entering the show version command.

[local]host_name# show version

You can run the Exec mode show build command to display additional information about the StarOS build release.

Access to the Cisco support site and download facility is username and password controlled. You must have an active customer account to access the site and download the StarOS image.

Download the software image to a network location or physical device (USB stick) from which it can be uploaded to the /flash device.

Contact your Cisco representative or Cisco TAC for additional information.

[local]host_name# directory /flash

The image filename should appear in the displayed output.

[local]host_name# show version /flash/image_filename.bin

Prior to upgrading to a new software release, you should copy and rename the current configuration file to the /flash device and to an off-chassis location (external memory device or network URL). This renamed copy assures that you will have a fallback, loadable configuration file should a problem be encountered during the upgrade.

Release 14 and Release 15 chassis IDs use different encryption formats. Release 15 will recognize a Release 14 chassis ID and consider it as valid. Upgrading from 14.x to 15.0 will not require changing the chassis ID or configuration file.

However, if the chassis key is reset in Release 15 through the setup wizard or chassis-key CLI command, a new chassis ID will be generated in Release 15 format (44 instead of 16 characters). Release 14 builds will not recognize the 44-character chassis ID. If the chassis is subsequently downgraded to Release 14, a new 16-character chassis ID will be generated. To accommodate the old key format, you must save the configuration file in pre-v12.2 format before the downgrade. If you attempt to load a v15 configuration file on the downgraded chassis, StarOS will not be able to decrypt the password/secrets stored in the configuration file.

Prior to release 20.0, local-user passwords were hashed with the MD5 message digest-algorithm and saved in the database. In release 20. 0, PBKDF2 (Password Based Key Derivation Function - Version 2) is now used to derive a key of given length, based on entered data, salt and number of iterations. Local-user account passwords are hashed using the PBKDF2 method with a randomly generated salt coupled with a large number of iterations to make password storage more secure.

Since hash functions are one-way, it is not possible to convert PBKDF2 hashed passwords to the MD5 format. The local-user database must be downgraded prior to reverting to StarOS releases prior to 20.0.

To downgrade the local-user database to use the MD5 hash algorithm, a Security Administrator must run the Exec mode downgrade local-user database command. StarOS prompts for confirmation and requests the Security Administrator to reenter a password. The entered password re-authenticates the user prior to executing the downgrade command. After verification, the password is hashed using the appropriate old/weak encryption algorithm and saved in the database to allow earlier versions of StarOS to authenticate the Security Administrator.

The downgrade process does not convert PBKDF2 hashed passwords to MD5 format. The downgrade process re-reads the database (from the /flash directory), reconstructs the database in the older format, and writes it back to the disk. Since the PBKDF2 hashed passwords cannot be converted to the MD5 hash algorithm, and earlier StarOS releases cannot parse the PBKDF2 encryption algorithm, StarOS suspends all those users encrypted via the PBKDF2 algorithm. Users encrypted via the MD5 algorithm ("Weak Hash" flag) can continue to login with their credentials. After the system comes up with the earlier StarOS release, suspended users can be identified in the output of the show local-user [verbose]command.

An off-line software upgrade can be performed for any system, upgrading from any version of operating system software to any version, regardless of version number. This process is considered off-line because while many of the steps can be performed while the system is currently supporting sessions, the last step of this process requires a reboot to actually apply the software upgrade.

[local]host_name#

After the system has successfully booted, verify that the new StarOS version is running by executing the Exec mode show version command.

[localhost_name# show version

You can run the Exec mode show build command to display additional information about the running StarOS build release.

If for some reason you need to undo the upgrade, perform the upgrade again except:

New systems are delivered with no license keys installed. In most cases, you receive the license key in electronic format (usually through e-mail).

[local]host_name# show license information

Use the instructions below to install a new license key.

When a license expires, there is a built-in grace period of 30 days that allows normal use of the licensed session use and feature use licenses. This allows you to obtain a new license without any interruption of service.

show license information  

License keys for the system can be obtained through your Cisco account representative. Specific information is required before a license key may be generated:

To see the license detail, enter the following command from the Exec mode:

[local]host_name# show license information [ full | key [ full ] ] 

To activate new license keys, you must reboot the active CF by exciting the Exec mode reload command.

Note	All SFs are rebooted when the reload command is executed on the active CF.

Use the procedure below to delete the session and feature use license key from a configuration. You must be a security administrator or administrator.

configure
   no license key
   exit
show license key

The output of this command should display: "No license key installed".

Refer to the local-user password command in the Global Configuration Mode Commands chapter of the Command Line Interface Reference for details on each of the above parameters.

Local-user account management includes configuring account lockouts and user suspensions.

Local-user administrative users can change their passwords using the password change command in the Exec mode. Users are prompted to enter their current and new passwords.

[local]host_name# password change username name

name is the name of the local-user account for which the password is to be changed. When a security administrator resets a local-user's password, the system prompts the user to change their password the next time they login.

All new passwords must adhere to the password properties configured for the system.

You can create a KVM script that runs a series of commands to reset, stop, start, or delete specified VMs.

The actual script will contain command sequences appropriate to the installation requirements of the VPC-DI instance as deployed in your site.