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.

Important

For complete information on the commands listed below, see the Exec Mode Commands chapter of the Command Line Interface Reference.

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.

Important

Operator and inspector-level users can execute the 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.

Important

The StarOS image filename format "asr5500-image_number.bin".

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 

Important

Before performing this procedure, verify that there are less than 10 entries in the boot.sys file and that a higher priority entry is available (i.e. that minimally there is no priority 1 entry in the boot stack). Refer to Viewing the Current Boot Stack for more information.

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 

Important

Boot stack changes saved to the boot.sys file are not executed until the system is rebooted.

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.

Prior to performing an upgrade of StarOS software containing CF and SF VNFCs, check if the following prerequisites are met:

• You’ll need the login credentials and IP address of AutoDeploy, AutoVNF, ESC, UEM, and CF VMs. You should have administrative rights to the OpenStack setup.

• Verify the OpenStack status. The Ansible output should all pass.

  cd /home/stack/ 
  source stackrc 
  cd /home/stack/ansible/ 
  ansible-playbook -i inventory openstack_verify.yml 

• Check if the health of AutoVNF/ESC/EM/VNF VM is normal through the UltraM health logs on AutoIT. If any of the VM(s) are not normal, then take necessary actions to rcover the health of the corresponding VM(s).

• You should have the new StarOS binary image file (for manual upgrade) or new StarOS CF QCOW2 image (for automated upgrade).

• Ensure that there are no pending transactions between ESC, UEM and CF.

• Be sure to take a backup of the original StarOS bin file.

  Note	Taking backup is not necessary for the automated bin upgrade as this will be automatically taken care through the upgrade RPC.

This section provides instructions that are applicable only to the upgrade of CF and SF VNFCs.

To collect the VIP addresses for AutoVNF, CF, ESC and UEM VMs:

1. Log on to the AutoDeploy VM as the default user, ubuntu.

   ssh ubuntu@<ad_vm_address> 

2. Switch to the root user.

   sudo -i 

3. Enter the ConfD CLI.

   confd_cli -u admin -C 

4. Enter the admin user credentials when prompted.

5. Collect the VIP address of AutoVNF, ESC, UEM and CF VMs.

   show vnfr 

   Example output:

   
   vnfr autoit-f-autovnf
   
    vnfd     f-autovnf
   
    vnf-type usp-uas
   
    state    deployed
   
    external-connection-point avf
   
     virtual-link-ref    management
   
     ip-address          192.168.100.26
   
     floating-ip-address 10.225.202.94
   
   vnfr sj-autovnf-esc
   
    vnfd     esc
   
    vnf-type esc
   
    state    deployed
   
    external-connection-point esc
   
     virtual-link-ref management
   
     ip-address       192.168.100.22
   
   vnfr sj-autovnf-vpc
   
    vnfd     vpc
   
    vnf-type ugp
   
    state    alive
   
    external-connection-point cf
   
     virtual-link-ref management
   
     ip-address       192.168.100.38
   
    external-connection-point em
   
     virtual-link-ref management
   
     ip-address       192.168.100.21 

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

The operating system software is delivered as a single binary file (.bin file extension) and is loaded as a single instance for the entire system.

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".

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.

To identify the StarOS software version and build information:

1. Log on to the VNF to be upgraded.

2. Enter the following Exec mode command in the StarOS command line interface:

   show version 

   Example output:

   Active Software:
   
     Image Version:             21.9.0.69918
   
     Image Build Number:        69918
   
     Image Description:         Deployment_Build
   
     Image Date:                Sun Jul 22 12:08:55 EDT 2018
   
     Boot Image:                /flash/staros.bin
   
     Source Commit ID:          94797337b6c1691541ea0dd86f2f29b0f2c3630c 

3. Execute the following Exec mode command to display additional information about the StarOS build release.

   show build 

This section provides instructions that are applicable only to the upgrade of CF and SF VNFCs.

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.

For UGP-based VNF, perform the following steps to download the new bin file to AutoVNF or OSPD VM.

1. Log on to the AutoVNF of the corresponding VNF.

   ssh ubuntu@<ad_vm_address> 

   Command example:

   ssh ubuntu@10.225.202.94 

2. Create a directory to download the new StarOS qvpc-di binary file to AutoVNF/OSPD.

   cd /home/ubuntu/ 

   mkdir StarOSBinUpgrade 

3. Download the new StarOS qvpc-di binary file from the Cisco support site and copy the file to the StarOSBinUpgrade directory.

   cd StarOSBinUpgrade 

   Then, use the following command to verify if the directory contains the new bin file.

   ls -lrt /home/ubuntu/StarOSBinUpgrade 

   Example output:

   total 172560
   
   -r--r--r-- 1 ubuntu ubuntu 176698880 Jul 24 23:29 qvpc-di-21.9.0.69932.bin 

This section provides instructions that are applicable only to the upgrade of CF and SF VNFCs.

To verify the zookeeper database:

1. Log on to the AutoVNF using the floating IP.

   ssh ubuntu@<ad_vm_address> 

   Command example:

   ssh ubuntu@10.225.202.94 

2. Log on to the UEM VM using the VIP address fetched in the Obtain VIP Addresses for AutoVNF, CF, ESC and UEM.

   ssh ubuntu@<vip-addr>

   Command example:

   ssh ubuntu@192.168.100.21 

3. Become the root user.

   sudo -i 

4. Collect the UEM orchestration IP address for Zookeeper database connection.

   #ifconfig 

   
   eth0      Link encap:Ethernet  HWaddr fa:16:3e:71:1d:08 
   
                inet addr:209.165.200.240  Bcast: 209.165.200.255  Mask: 255.255.255.224 

5. Navigate to the /opt/cisco/usp/packages/zookeeper/<current>/bin directory.

6. Execute the following script from the command line to access the UEM Zookeeper database.

   zkCli.sh -server ip_addr:port_num 

   For example:

   zkCli.sh -server 209.165.200.240:2181 

7. Check the zookeeper database and ensure that there are no pending requests between UEM and CF VMs.

   ls /request 

   Example output:

   []
   
   <Ctrl+D to exit Zookeeper shell> 

This section provides instructions that are applicable only to the upgrade of CF and SF VNFCs.

To verify the ESC database:

1. Log on to the AutoVNF using the floating IP.

   ssh ubuntu@<ad_vm_address> 

   Command example:

   ssh ubuntu@10.225.202.94 

2. Log on to the ESC VM using the VIP address fetched in the Obtain VIP Addresses for AutoVNF, CF, ESC and UEM.

   ssh admin@<vip-addr>

   Command example:

   ssh admin@192.168.100.22 

3. Check the ESC database to ensure there are no pending transactions.

   sudo /opt/cisco/esc/pgsql/bin/psql -U esc -p 7878 -h localhost -c 'select * from esc_schema.workitem'; 

   
   config_id | request_id | mo_type | config_action | config_state 
   -----------+------------+---------+---------------+--------------
   (0 rows) 

4. Execute the following command to check the transaction details.

   escadm ip_trans 

   Example output:

   Number of in-progress transaction events = 0 

Verify that there is enough free space on the /flash device to accommodate the new StarOS image file.

To verify the available space on flash directory:

1. Log on to the CF VM using the previously fetched VIP address in the Obtain VIP Addresses for AutoVNF, CF, ESC and UEM.

   ssh ubuntu@<vip-addr>

   Command example:

   ssh ubuntu@192.168.100.38 

2. Enter the following Exec mode command:

   [local]host_name# directory /flash 

   The following is an example of the type of directory information displayed:

   -rwxrwxr-x    1  root     root         7334 May    5 17:29 asr-config.cfg 
   -rwxrwxr-x    1  root     root         399 Jun    7 18:32 system.cfg 
   -rwxrwxr-x    1  root     root         10667 May 14 16:24 testconfig.cfg 
   -rwxrwxr-x    1  root     root         10667 Jun    1 11:21 testconfig_4.cfg 
   -rwxrwxr-x    1  root     root         5926 Apr    7 16:27  tworpcontext.cfg 
   -rwxrwxr-x    1  root     root         15534 Aug    4 13:31 test_vlan.cfg 
   -rwxrwxr-x    1  root     root         2482 Nov 18 11:09 gateway2.cfg 
   -rwxrwxr-x    1  root     root         159106048 Dec 31  2011 image_filename 
   1136352  /flash 
   Filesystem           1k-blocks      Used Available Use% Mounted on 
   /var/run/storage/flash/part1 3115468   1136352  30018336   4% /mnt/user/.auto/onboard/flash 

   Note the "Available" blocks in the last line of the display. After displaying the directory information, the CLI returns to root and the following prompt appears:

   [local]host_name# 

For StarOS-based VNF, transfer the new operating system image file to the /flash directory on the MIO/UMIO/MIO2 VPC-DI active CF or VPC-SI using one of the following methods:

• Transfer the file to the /flash device using an FTP client with access to the system.

  Important

  Whenever transferring a operating system software image file using the file transfer protocol (FTP), the FTP client must be configured to transfer the file using binary mode. Failure to use binary transfer mode will make the transferred operating system image file unusable. FTP is not supported.

• Transfer the file to the /flash device using an SFTP client with access to the system.

For UGP-based VNF, copy the new StarOS bin to the active CF by following these steps.

1. Log on to the AutoVNF or OSPD VM where the new bin file is downloaded.

   ssh ubuntu@<ad_vm_address> 

   Command example:

   ssh ubuntu@10.225.202.94 

2. Navigate to the directory where the new bin file is downloaded from the Cisco support site.

   cd /home/ubuntu/StarOSBinUpgrade/ && ls -lrt 

   Example output:

   total 172560
   
   -r--r--r-- 1 ubuntu ubuntu 176698880 Jul 24 23:29 qvpc-di-21.9.0.69932.bin 

3. SFTP to the CF VM.

   For example:

   sftp ubuntu@192.168.100.38 

4. Navigate to the sftp directory.

   #sftp>pwd 

   Remote working directory: / 

   #sftp>ls 

   hd-raid sftp 

   #sftp>cd sftp 

5. Upload the new binary file to the sftp directory.

   #sftp>put image_filename.bin 

   Example output:

   #sftp>put qvpc-di-21.9.0.69932.bin 

   Uploading qvpc-di-21.9.0.69932.bin to /.auto/onboard/flash/sftp/qvpc-di-21.9.0.69932.bin
   qvpc-di-21.9.0.69932.bin                             100%  169MB 168.5MB/s   00:01 

6. Log on to the CF VM using the VIP address fetched in the Obtain VIP Addresses for AutoVNF, CF, ESC and UEM.

   ssh ubuntu@<vip-addr>

   Command example:

   ssh ubuntu@192.168.100.38 

7. Copy the new bin from sftp to flash directory.

   copy /flash/sftp/image_filename.bin /flash/updated.bin 

   Example output:

   #copy /flash/sftp/qvpc-di-21.9.0.69932.bin /flash/updated.bin
   
   **************************************************************
   
   Transferred 176698880 bytes in 2.718 seconds (63486.9 KB/sec) 

8. Delete the new bin from sftp directory.

   delete /flash/sftp/image_filename.bin 

   Example output:

   delete /flash/sftp/qvpc-di-21.9.0.69932.bin 
   Are you sure? [Yes|No]: yes
   File /flash/sftp/qvpc-di-21.9.0.69932.bin removed 

9. Verify that the image file was successfully transferred to the /flash device by running the following Exec mode command:

   [local]host_name# directory /flash 

   The image filename should appear in the displayed output.

10. Execute the following command to verify the build information.

    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.

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# 

To perform offline software upgrade:

1. Configure a Newcall Policy

2. Configure a Message of the Day Banner

3. Back up the Current CLI Configuration File

4. Save the Running Configuration

5. Create a New Boot Stack Entry

6. Synchronize File Systems

7. Reboot the System

Save the currently running, upgraded configuration prior to rebooting the chassis.

Important

For the automated upgrade of StarOS binary image, perform only the Steps from 1 through 3 in the following procedure.

To save the boot configuration:

1. Log on to the VNF using the previously fetched VIP address in the Obtain VIP Addresses for AutoVNF, CF, ESC and UEM .

   ssh ubuntu@<vip-addr> 

   Command example:

   ssh ubuntu@192.168.100.38 

2. Optional. Execute the following command in the Exec mode.

   chassis key value 1234 

   Save config before reload chassis, EVEN IF the same old key value is used.
   Old config scripts will become invalid after reload. 

   Important

   This step is optional, and needed only if the chassis key is not set.

3. Save the boot configuration in the flash directory.

   save configuration /flash/system.cfg 

   Warning: About to overwrite boot configuration file
   Are you sure? [Yes|No]: yes 

   This will update the boot configuration to use the new bin image.

   Use the following command to check the boot configuration.

   # show boot 
    
   Monday May 21 20:39:57 UTC 2018
   
   boot system priority 8 \
       image /flash/sftp/production.YYYYY.qvpc-di.bin \
       config /flash/sftp/tb5_vnf1_dayN.cfg
   
   boot system priority 9 \
       image /flash/staros.bin \
       config /flash/sftp/tb5_vnf1_dayN.cfg
   
   boot system priority 10 \
       image /flash/staros.bin \
       config /flash/system.cfg
    

4. Enter the configuration mode to change the boot priority of new StarOS bin file.

   #config 

   #boot system priority 1 image /flash/updated.bin config /flash/system.cfg 

   #end 

5. Verify the new boot priority.

   #show boot 

   
   boot system priority 1 \
   
       image /flash/updated.bin \
   
       config /flash/system.cfg
   
   boot system priority 10 \
   
       image /flash/staros.bin \
   
       config /flash/system.cfg 

6. Verify whether the flash directory contains the boot configuration and new bin.

   dir /flash 

   total 320376
   -rw-rw-r-- 1 root root 134 May 3 10:11 boot.sys
   -rw-rw-r-- 1 root root 3920672 May 11 19:49 crashlog2
   drwxrwxr-x 2 root root 4096 May 11 19:49 crsh2
   -rw-rw-r-- 1 root root 156 May 11 19:49 module.sys
   drwxrwxr-x 3 root root 4096 May 11 19:49 patch
   drwxrwxr-x 2 root root 4096 May 11 19:49 persistdump
   -rw-rw-r-- 1 root root 79 May 11 19:49 restart_file_cntr.txt
   drwxrwxr-x 3 root root 4096 May 11 20:07 sftp
   -rw-rw-r-- 1 root root 160871936 May 3 10:11 staros.bin
   -rw-rw-r-- 1 root root 5199 May 11 19:57 system.cfg
   -rw-rw-r-- 1 root root 163227136 May 11 20:07 updated.bin
   320476 /flash
   Filesystem 1K-blocks Used Available Use% Mounted on
   /var/run/storage/boot1/part2
   4112620 320476 3792144 8% /mnt/user/.auto/onboard/flash 

To synchronize the file systems:

1. Log on to the VNF using the previously fetched VIP address in the Obtain VIP Addresses for AutoVNF, CF, ESC and UEM.

2. Synchronize the local file systems on the management cards by entering the following command:

   [local]host_name# filesystem synchronize all 

   Example output:

   Updating /flash/system.cfg
   
   ********************************************************************************
   
   Updating /flash/updated.bin
   
   ********************************************************************************
   
   Updating /flash/sftp/yang/cisco-staros-bulkstats-config.yang
   
   ********************************************************************************
   
   Updating /flash/sftp/yang/cisco-staros-bulkstats-schema-types.yang
   
   ********************************************************************************
   
   Updating /flash/sftp/yang/cisco-staros-bulkstats.yang
   
   ********************************************************************************
   
   Updating /flash/sftp/yang/cisco-staros-cli-config.yang
   
   ********************************************************************************
   
   Updating /flash/sftp/yang/cisco-staros-confd-config.yang
   
   ********************************************************************************
   
   Updating /flash/sftp/yang/cisco-staros-config.yang
   
   ********************************************************************************
   
   Updating /flash/sftp/yang/cisco-staros-exec.yang
   
   ********************************************************************************
   
   Updating /flash/sftp/yang/cisco-staros-kpi.yang
   
   ********************************************************************************
   
   Updating /flash/sftp/yang/cisco-staros-notif.yang
   
   ********************************************************************************
   
   Updating /flash/boot.sys
   
   ********************************************************************************
   
   12 updated on card 2
   
              /flash/system.cfg
   
              /flash/updated.bin
   
              /flash/sftp/yang/cisco-staros-bulkstats-config.yang
   
              /flash/sftp/yang/cisco-staros-bulkstats-schema-types.yang
   
              /flash/sftp/yang/cisco-staros-bulkstats.yang
   
              /flash/sftp/yang/cisco-staros-cli-config.yang
   
              /flash/sftp/yang/cisco-staros-confd-config.yang
   
              /flash/sftp/yang/cisco-staros-config.yang
   
              /flash/sftp/yang/cisco-staros-exec.yang
   
              /flash/sftp/yang/cisco-staros-kpi.yang
   
              /flash/sftp/yang/cisco-staros-notif.yang
   
              /flash/boot.sys 

To reboot the system (VNF):

1. Log on to the VNF using the previously fetched VIP address in the Obtain VIP Addresses for AutoVNF, CF, ESC and UEM .

   ssh ubuntu@<vip-addr> 

   Command example:

   ssh ubuntu@192.168.100.38 

2. Enter the following Exec mode command:

   [local]host_name# reload [-noconfirm] 

   As the system reboots, it loads the new operating system software image and its corresponding CLI configuration file using the new boot stack entry configured earlier.

3. Optional for PDSN: If you are using the IP Pool Sharing Protocol during your upgrade, refer to Configuring IPSP Before the Software Upgrade in the PDSN Administration Guide.

4. After the reload is complete, log on to the VNF and make sure it is loaded with the intended StarOS version and all the cards have booted up and are in active or stand-by state as expected.

   show version 

   Example output:

   Active Software:
     Image Version:                  21.9.0.69977
     Image Build Number:             69977
     Image Description:              Build
     Image Date:                     Mon Jul 30 06:48:34 EDT 2018
     Boot Image:                     /flash/updated.bin
     Source Commit ID:               abde005a31c93734c89444b8aec2b6bb2d2e794d
    

   show card table 

   Example output:

   
   Slot         Card Type                               Oper State     SPOF  Attach
   -----------  --------------------------------------  -------------  ----  ------
    1: CFC      Control Function Virtual Card           Active         No
    2: CFC      Control Function Virtual Card           Standby        -
    3: FC       4-Port Service Function Virtual Card    Standby        -
    4: FC       4-Port Service Function Virtual Card    Standby        -
    5: FC       4-Port Service Function Virtual Card    Standby        -
    6: FC       4-Port Service Function Virtual Card    Standby        -
    7: FC       4-Port Service Function Virtual Card    Standby        -
    8: FC       4-Port Service Function Virtual Card    Standby        -
    9: FC       4-Port Service Function Virtual Card    Standby        -
   10: FC       4-Port Service Function Virtual Card    Standby        -
    

5. Run the following Exec mode command to display additional information about the running StarOS build release.

   show build 

6. Optional. Verify the operational state of CF and SF VNFCs.

   Note	This step is relevant only for the upgrade of CF and SF VNFCs.

   1. Repeat the steps in Verify Zookeeper Database and Verify ESC Database sections.

   2. Log on to the UEM using either the floating IP or from the AutoVNF using the UEM VIP.

      ssh ubuntu@<vip-addr>  

      Command example:

      ssh ubuntu@192.168.100.21 

   3. Become the root user.

      sudo -i 

   4. Collect the UEM orchestration IP address for Zookeeper database connection.

      #ifconfig
      
      eth0      Link encap:Ethernet  HWaddr fa:16:3e:71:1d:08 
      
                inet addr:209.165.200.225  Bcast:209.165.200.255  Mask:255.255.255.224 

   5. Navigate to the /opt/cisco/usp/packages/zookeeper/<current>/bin directory.

   6. Run Zookeeper tool to access the UEM Zookeeper database.

      zkCli.sh -server <vip-addr>:port_num 

      Command example:

      zkCli.sh -server 209.165.200.225:2181 

      Make sure there are no outstanding requests between UEM and CF.

   7. Verify the “state”: “alive” for each of the CFs and SFs using the following commands:

      get /oper/vnfs/vnf_name/vdus/vdu_name/cf1 

      get /oper/vnfs/vnf_name/vdus/vdu_name/cf2 

      get /oper/vnfs/vnf_name/vdus/vdu_name/sf1 

      get /oper/vnfs/vnf_name/vdus/vdu_name/sf2 

      Command examples:

      get /oper/vnfs/tb1-autovnf1_vpc-vpc-core/vdus/vdu-cf1/cf1 

      get /oper/vnfs/tb1-autovnf1_vpc-vpc-core/vdus/vdu-cf1/cf2 

      get /oper/vnfs/tb1-autovnf1_vpc-vpc-core/vdus/vdu-sf1/sf1 

      get /oper/vnfs/tb1-autovnf1_vpc-vpc-core/vdus/vdu-sf1/sf2 

   8. Look for the state Alive in the console output.

      
      zk: localhost:2181(CONNECTED) 2] get /oper/vdus/control-function/BOOT_generic_di-chassis_CF1_1
      {"id":"BOOT_generic_di-chassis_CF1_1","state":"alive","vnfcId":"cf-vnfc-di-chassis","uuid":"c4",
      "host":"tb5-ultram-osd-compute-2.localdomain","vimId":"523b921c-7266-4fd5-90bb-5157cffc6951",
      "cpts":[{"cpid":"di_intf1","state":"alive","subnet":"6102e9b5-8555-41f5-8cdc-0b47d30a6f7a",
      "netmask":"255.255.255.0","dhcp":true,"vl":"vl-vnf1-DI-INTERNAL1-CAT","vnfc":"cf-vnfc-di-chassis",
      "port_id":"19539aea-edbf-4acf-a57c-af5627d859ea","ip_address":"192.168.10.3",
      "mac_address":"fa:16:3e:19:80:ed","network":"0d72f553-5a9c-4904-b3ea-83371a806e23"},
      {"cpid":"di_intf2","state":"alive","nicid":1,"subnet":"30002d02-761d-4ccb-8a9e-d6188cdf54a3",
      "netmask":"255.255.255.0","dhcp":true,"vl":"vl-vnf1-DI-INTERNAL2-CAT","vnfc":"cf-vnfc-di-chassis",
      "port_id":"ff1da1e1-ecf3-477d-98b7-398c3c77fc8d","ip_address":"192.168.11.13",
      "mac_address":"fa:16:3e:89:88:23","network":"9f109c0a-b1e7-4d90-a746-5de4ab8ef536"},
      {"cpid":"orch","state":"alive","nicid":2,"subnet":"729e9dd2-3c75-43eb-988a-769016f2f44c",
      "netmask":"255.255.255.0","dhcp":true,"vl":"vl-vnf1-UAS-ORCH-CAT","vnfc":"cf-vnfc-di-chassis",
      "port_id":"81370948-f686-4812-820c-20ec5d3d3cdd","ip_address":"172.168.11.17","mac_address":"fa:16:3e:1d:0b:56",
      "network":"9a286170-e393-4ba5-abce-147a45fb337a"},{"cpid":"mgmt","state":"alive","nicid":3,
      "subnet":"9778a11b-1714-4e84-bbc2-86c84b111e8e","netmask":"255.255.255.0","dhcp":true,"vl":"vl-vnf1-UAS-MGMT-CAT",
      "vnfc":"cf-vnfc-di-chassis","port_id":"6130cbb4-3dd8-4822-af90-50dac98f2f0d",
      "ip_address":"172.168.10.17","mac_address":"fa:16:3e:42:92:47","network":"e278b524-e9a9-48c1-a45b-956a8c3ea583"}],
      "monitor":true,"vduId":"control-function"}
      cZxid = 0x100000051
      ctime = Fri May 18 19:04:40 UTC 2018
      mZxid = 0x10000024a
      mtime = Mon May 21 17:48:19 UTC 2018
      pZxid = 0x100000051
      cversion = 0
      dataVersion = 12
      aclVersion = 0
      ephemeralOwner = 0x0
      dataLength = 1625
      numChildren = 0
       

      Note	You can use use CTRL+D to exit the zookeeper CLI.

   9. From the UEM VM as a root user, log on to the ncs_cli and check for devices live status.

      ~$ sudo -i 

      ncs_cli -C -u admin 

      # show devices device device_name live-status 

      Verify that the command output reflects the correct 'state' and 'card-state' of each card.

      Example output:

      # show devices device tb1-autovnf1_vpc-vpc-core-cf-nc live-status 

      <snip> 

      VNFC REF	CURRENT STATE	VNFC INSTANCE ID	VDU REF	CARD TYPE	CARD SLOT ID	NUMBER OF CORES	CPU UTILIZATION	DISK SPACE	START TIME	UPTIME	NOVA LAUNCH CMD	ID	DATE AND TIME	FROM STATE	TO STATE
      cf1	-	cf1	cf	control-function	1	-	-	-	-	-	-
      cf2	-	cf2	cf	control-function	2	-	-	-	-	-	-
      sf1	-	sf1	sf	session-function	3	-	-	-	-	-	-
      sf2	-	sf2	sf	session-function	4	-	-	-	-	-	-

      
      live-status vnfd sj-autovnf-vpc-abc
      
       version            6.0
      
       vnfm vim-tenant-name abc
      
       vnfm tenant-name abc
      
       vnfm ipaddr     192.168.100.22
      
       vnfm port       830
      
       vnfm username   ubuntu
      
       vnfm password   "$4$+HLzhFFzHq66nqtTsc00CfiODYHqlUSVmkn1tRe1f84byNakWEa9sJ8sY/
      cwfFME3aG0UaBC\nvvNNAMkuXQI9Ksfu5IiQQ9ViWbbHwl6IEFQ="
      
       virtual-link vl-di-internal1
      
        auto-vnf-connection-ref di-internal1
      
       virtual-link vl-management
      
        auto-vnf-connection-ref management
      
       virtual-link vl-orchestration
      
        auto-vnf-connection-ref orchestration
      
       virtual-link vl-abc-vpc-svc
      
        auto-vnf-connection-ref sj-autovnf-abc-vpc-svc
      
       vdu cf
      
        ssh-keygen         false
      
        vm-image           076c887a-a12c-4a0b-b4d6-b2d213f64b9e
      
        lifecycle-event-initialization staros_config.txt
      
         source-url http://192.168.100.9:5000/config/sj-autovnf-vpc-abc/cf/staros_config.txt
      
        lifecycle-event-initialization staros_param.cfg
      
         source-url http://192.168.100.9:5000/config/sj-autovnf-vpc-abc/cf/staros_param.cfg
      
        ned cisco-staros-nc
      
         user        "$4$+HLzsE1kLJOeuoFWyOsmBWY2LHjOi2WtJdKy/OIux7YHhsNY/
      O8hnA9/WwWuFD5trHrW3ZHs\nLo4TfiAKqYwxdNKqFYyoTxH2hrLJV5DgwmE="
      
         password    "$4$+HLzsXtCHJ2vsYZD5s0RGtBRY/dHDU1mgHJX7wCt3o1DMtQZqpBLDcNSJumC7n5rnkVxwI1s\
      ncJYeCOFLrqpLHXm3xtXyMdtT7WVzvRMtdao="
      
         netconf
      
         port-number 830
      
        card-type          control-function
      
        usp-auto-vnf-id    sj-autovnf-vpc-abc-cf
      
        vnfc cf-vnfc-ugp
      
      <snip> 

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

• Specify the locations of the upgrade software image and configuration files.

then

• Specify the locations of the original software image and configuration files.

Prior to performing an upgrade of StarOS software containing CF and SF VNFCs, check if the following prerequisites are met:

• You’ll need the login credentials and IP address of AutoDeploy, AutoVNF, ESC, UEM, and CF VMs. You should have administrative rights to the OpenStack setup.

• Verify the OpenStack status. The Ansible output should all pass.

  cd /home/stack/ 
  source stackrc 
  cd /home/stack/ansible/ 
  ansible-playbook -i inventory openstack_verify.yml 

• Check if the health of AutoVNF/ESC/EM/VNF VM is normal through the UltraM health logs on AutoIT. If any of the VM(s) are not normal, then take necessary actions to rcover the health of the corresponding VM(s).

• You should have the new StarOS binary image file (for manual upgrade) or new StarOS CF QCOW2 image (for automated upgrade).

• Ensure that there are no pending transactions between ESC, UEM and CF.

• Be sure to take a backup of the original StarOS bin file.

  Note	Taking backup is not necessary for the automated bin upgrade as this will be automatically taken care through the upgrade RPC.

This section provides instructions that are applicable only to the upgrade of CF VNFCs.

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.

The image files required to deploy the UGP are distributed as part of an RPM bundle. The bundle is called usp-ugp-bundle-<version>.x86_64.rpm and it is distributed as part of the USP ISO image.

For UGP-based VNF, perform the following steps to download the new StarOS binary image file to AutoVNF or OSPD VM.

1. Download the USP ISO bundle for the required release from the Cisco support site.

2. Extract the UGP image files from the USP ISO. The UGP RPM bundle contains qvpc-di-<version>.qcow2.tgz.

   rpm2cpio /var/usp-iso/repo/usp-ugp-bundle-<version>-1.x86_64.rpm | cpio –idmv ./opt/cisco/usp/bundles/ugp-bundle/qvpc-di-<version>.qcow2.tgz 

3. Ensure that the images have been extracted.

   ls -l ./opt/cisco/usp/bundles/ugp-bundle/qvpc-di-<version>.qcow2.tgz 

4. Extract the CF qcow2 image.

   tar –zxvf qvpc-di-<version>.qcow2.tgz qvpc-di-cf-<version>.qcow2 

This section provides instructions that are applicable only to the upgrade of CF and SF VNFCs.

To verify the zookeeper database:

1. Log on to the AutoVNF using the floating IP.

   ssh ubuntu@<ad_vm_address> 

   Command example:

   ssh ubuntu@10.225.202.94 

2. Log on to the UEM VM using the VIP address fetched in the Obtain VIP Addresses for AutoVNF, CF, ESC and UEM.

   ssh ubuntu@<vip-addr>

   Command example:

   ssh ubuntu@192.168.100.21 

3. Become the root user.

   sudo -i 

4. Collect the UEM orchestration IP address for Zookeeper database connection.

   #ifconfig 

   
   eth0      Link encap:Ethernet  HWaddr fa:16:3e:71:1d:08 
   
                inet addr:209.165.200.240  Bcast: 209.165.200.255  Mask: 255.255.255.224 

5. Navigate to the /opt/cisco/usp/packages/zookeeper/<current>/bin directory.

6. Execute the following script from the command line to access the UEM Zookeeper database.

   zkCli.sh -server ip_addr:port_num 

   For example:

   zkCli.sh -server 209.165.200.240:2181 

7. Check the zookeeper database and ensure that there are no pending requests between UEM and CF VMs.

   ls /request 

   Example output:

   []
   
   <Ctrl+D to exit Zookeeper shell> 

This section provides instructions that are applicable only to the upgrade of CF and SF VNFCs.

To verify the ESC database:

1. Log on to the AutoVNF using the floating IP.

   ssh ubuntu@<ad_vm_address> 

   Command example:

   ssh ubuntu@10.225.202.94 

2. Log on to the ESC VM using the VIP address fetched in the Obtain VIP Addresses for AutoVNF, CF, ESC and UEM.

   ssh admin@<vip-addr>

   Command example:

   ssh admin@192.168.100.22 

3. Check the ESC database to ensure there are no pending transactions.

   sudo /opt/cisco/esc/pgsql/bin/psql -U esc -p 7878 -h localhost -c 'select * from esc_schema.workitem'; 

   
   config_id | request_id | mo_type | config_action | config_state 
   -----------+------------+---------+---------------+--------------
   (0 rows) 

4. Execute the following command to check the transaction details.

   escadm ip_trans 

   Example output:

   Number of in-progress transaction events = 0 

Verify that there is enough free space on the /flash device to accommodate the new StarOS image file.

To verify the available space on flash directory:

1. Log on to the CF VM using the previously fetched VIP address in the Obtain VIP Addresses for AutoVNF, CF, ESC and UEM.

   ssh ubuntu@<vip-addr>

   Command example:

   ssh ubuntu@192.168.100.38 

2. Enter the following Exec mode command:

   [local]host_name# directory /flash 

   The following is an example of the type of directory information displayed:

   -rwxrwxr-x    1  root     root         7334 May    5 17:29 asr-config.cfg 
   -rwxrwxr-x    1  root     root         399 Jun    7 18:32 system.cfg 
   -rwxrwxr-x    1  root     root         10667 May 14 16:24 testconfig.cfg 
   -rwxrwxr-x    1  root     root         10667 Jun    1 11:21 testconfig_4.cfg 
   -rwxrwxr-x    1  root     root         5926 Apr    7 16:27  tworpcontext.cfg 
   -rwxrwxr-x    1  root     root         15534 Aug    4 13:31 test_vlan.cfg 
   -rwxrwxr-x    1  root     root         2482 Nov 18 11:09 gateway2.cfg 
   -rwxrwxr-x    1  root     root         159106048 Dec 31  2011 image_filename 
   1136352  /flash 
   Filesystem           1k-blocks      Used Available Use% Mounted on 
   /var/run/storage/flash/part1 3115468   1136352  30018336   4% /mnt/user/.auto/onboard/flash 

   Note the "Available" blocks in the last line of the display. After displaying the directory information, the CLI returns to root and the following prompt appears:

   [local]host_name# 

Save the currently running, upgraded configuration prior to rebooting the chassis.

Important

For the automated upgrade of StarOS binary image, perform only the Steps from 1 through 3 in the following procedure.

To save the boot configuration:

1. Log on to the VNF using the previously fetched VIP address in the Obtain VIP Addresses for AutoVNF, CF, ESC and UEM .

   ssh ubuntu@<vip-addr> 

   Command example:

   ssh ubuntu@192.168.100.38 

2. Optional. Execute the following command in the Exec mode.

   chassis key value 1234 

   Save config before reload chassis, EVEN IF the same old key value is used.
   Old config scripts will become invalid after reload. 

   Important

   This step is optional, and needed only if the chassis key is not set.

3. Save the boot configuration in the flash directory.

   save configuration /flash/system.cfg 

   Warning: About to overwrite boot configuration file
   Are you sure? [Yes|No]: yes 

   This will update the boot configuration to use the new bin image.

   Use the following command to check the boot configuration.

   # show boot 
    
   Monday May 21 20:39:57 UTC 2018
   
   boot system priority 8 \
       image /flash/sftp/production.YYYYY.qvpc-di.bin \
       config /flash/sftp/tb5_vnf1_dayN.cfg
   
   boot system priority 9 \
       image /flash/staros.bin \
       config /flash/sftp/tb5_vnf1_dayN.cfg
   
   boot system priority 10 \
       image /flash/staros.bin \
       config /flash/system.cfg
    

4. Enter the configuration mode to change the boot priority of new StarOS bin file.

   #config 

   #boot system priority 1 image /flash/updated.bin config /flash/system.cfg 

   #end 

5. Verify the new boot priority.

   #show boot 

   
   boot system priority 1 \
   
       image /flash/updated.bin \
   
       config /flash/system.cfg
   
   boot system priority 10 \
   
       image /flash/staros.bin \
   
       config /flash/system.cfg 

6. Verify whether the flash directory contains the boot configuration and new bin.

   dir /flash 

   total 320376
   -rw-rw-r-- 1 root root 134 May 3 10:11 boot.sys
   -rw-rw-r-- 1 root root 3920672 May 11 19:49 crashlog2
   drwxrwxr-x 2 root root 4096 May 11 19:49 crsh2
   -rw-rw-r-- 1 root root 156 May 11 19:49 module.sys
   drwxrwxr-x 3 root root 4096 May 11 19:49 patch
   drwxrwxr-x 2 root root 4096 May 11 19:49 persistdump
   -rw-rw-r-- 1 root root 79 May 11 19:49 restart_file_cntr.txt
   drwxrwxr-x 3 root root 4096 May 11 20:07 sftp
   -rw-rw-r-- 1 root root 160871936 May 3 10:11 staros.bin
   -rw-rw-r-- 1 root root 5199 May 11 19:57 system.cfg
   -rw-rw-r-- 1 root root 163227136 May 11 20:07 updated.bin
   320476 /flash
   Filesystem 1K-blocks Used Available Use% Mounted on
   /var/run/storage/boot1/part2
   4112620 320476 3792144 8% /mnt/user/.auto/onboard/flash 

StarOS upgrades are automated through the RPC executed from the ConfD CLI or a NETCONF API.

StarOS allows the runtime loading of plugins. All StarOS builds include a "default" baseline plugin.

This feature is currently used to dynamically update the detection logic used to filter P2P applications.

Patching is the process used to install a plugin as an incremental update to a StarOS release. One plugin can be provided to multiple, compatible, concurrent product releases. A plugin is distributed in the form of a compressed distribution kit via the internet or by other means (USB stick, CD, etc.).

A plugin is a functional software entity that provides incremental updates to a pre-existing StarOS software component. Plugins have the characteristic of being dynamically loadable at runtime and do not require a system restart. A plugin has a name and one or more versions. All plugin names are known to the system at product release.

A plugin module is a specific instance of a plugin version consisting of at least one file that can be added to a running, in-service system. The module contains the information or instructions for a specific component's incremental update. Typically this would be a single file.

The Version Priority List (VPL) is a linked list of module versions associated with a specific plugin. Each plugin has one VPL. The list is sorted in ascending order by the priority number that is assigned by the administrator. When updating, the lowest priority number is tried first. If that version is not successful, the version in the VPL with the next sequentially greater priority number is tried. This list is iterated until a successful version is found. The VPL also supports manual rollback to a previous version (higher priority number) via a CLI command.

The Exec mode patch plugin command copies a patch intended for a specific plugin onto the running system.

patch plugin name [ http | ftp | sftp ]://host/directory/file certificate  [ http | ftp | sftp ]://host/directory/file 

[local]asr5k# patch plugin p2p http://192.168.1.2/tmp/patch_libp2p-1.17.4343.tgz certificate http://192.168.1.2/tmp/patch_libp2p-1.17.4343.cert 
New patch for plugin p2p available for installation 

The patch kit is copied to the /flash/patch/module-name directory on the system.

The Exec mode install patch command unpacks a patch kit and validates its contents. This command does not actually distribute the contents to the packet processing card /var/opt directories

install plugin plugin-name patch-file-name 

[local]host_name# install patch plugin p2p patch_libp2p-1.17.4343.tgz 
  Install patch file patch_libp2p-1.17.4343.tgz [Yes/No]? 
  Install module p2p version 1.17.4343 successful 

When a new plugin module is installed, the patch file is checked against the certificate which is provided with the patch file for authenticity of contents. If the certificate matches the patch file, the contents are extracted to the /flash/install/plugin-name/contents directory.

Once the contents are extracted, the Plugin Manager looks for the file patch.bom which contains a list of files which are considered a complete set for the patch. In addition, for each file listed, the.bom file contains an intended final destination directory where the content file should reside at the end of the installation.

For each file listed in the.bom file, the installation procedure copies the specified file to the destination directory. Once this has completed, the installation procedure is finished. The primary MIO/UMIO/MIO2 is responsible for ensuring that the /flash partitions on the standby MIO/UMIO/MIO2 are up-to-date.

The Global Configuration mode plugin command specifies a plugin to be configured and enters the Plugin Configuration mode. The plugin name must match the name of a plugin which has been copied to and unpacked on the system or an error message is displayed.

plugin plugin-name 
  module priority number version module_version 

[local]host_name# configure 
[local]host_name(config)# plugin p2p 
[local]host_name(plugin-p2p)# module priority 1 version 1.17.4343  

If a module priority number (1 through 100) was specified in an earlier configuration, that number is preserved. If the user does not explicitly replace or remove a module priority number, that number and the version associated with it will remain configured.

The Plugin Configuration mode also allows a user to enter values for any attribute value pairs (AVPs) associated with the plugin, as well as set the priority for this version of the plugin in the VPL.

The Exec mode update module command loads the specified module with the lowest priority number from the VPL.

update module plugin-name 

[local]host_name# update module p2p 
Update to module p2p version 1.17.4343 successful 

The update module command takes the configured VPL (/flash/module.sys) and copies it into the internal data structures within the Plugin Manager. The VPL determines the sequence of module versions to try to load for each of the cards.

Current subscriber sessions will not be updated to the latest plugin version. New subscriber sessions will be affected by the newly updated plugin version.

The Exec mode rollback module command loads a module with the next higher priority number from the VPL.

rollback module plugin-name 

[local]host_name# rollback module p2p 
Rollback to module p2p version 1.17.4340 successful 

Current subscriber sessions will continue to be affected by the previous plugin version. New subscriber sessions will be affected by the newly downgraded plugin version.

There are two show commands associated with the dynamic software update process – show module and show plugin.

show module [plugin-name] 

[local]asr5# show module p2p 
Module p2p 
Priority version    loaded location                   time         status 
    1    1.17.4343      no  /var/opt/lib    07/04/2012:05:06:59  success 
    2    1.17.4340      yes  /var/opt/lib    03/06/2012:04:05:53  success 
    3    1.17.4335      no  /var/opt/lib    03/05/2012:03:04:35  success 
    4     1.17.4328     no  /var/opt/lib    03/04/2012:02:03:42  failed 
    X    1.17.4289      no  /var/opt/lib    01/12/2012:05:44:22  success 

Important

Priority "X" identifies the "default" module that shipped with the StarOS build.

show plugin [plugin-name] 

[local]host_name# show plugin p2p 
  plugin p2p 
    module priority 1 version 1.17.4343  
    module priority 2 version 1.17.4340  
    module priority 3 version 1.17.4328  
    module priority 4 version 1.17.4340  
    module priority X version 1.17.4289  

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 

Important

With no license key installed, the session use licenses for PDSN, HA, GGSN, and L2TP LNS are limited to 10,000 sessions.

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 ".

Local-user account password properties are configured globally and apply to all local-user accounts. The system supports the configuration of the following password properties:

• Complexity: Password complexity can be forced to be compliant with ANSI T1.276-2003.

• History length: How many previous password versions should be tracked by the system.

• Maximum age: How long a user can use the same password.

• Minimum number of characters to change: How many characters must be changed in the password during a reset.

• Minimum change interval: How often a user can change their password.

• Minimum length: The minimum number of characters a valid password must contain.

• Expiry warning: Password expiry warning interval in days.

• Auto-generate: Automatically generates password with option to specify length of password.

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.