Following successful installation of VPC-DI across all VMs, you must configure a set of StarOS parameters via the active Control Function (CF) VM. You then save these settings in a configuration file on the active CF that is accessed whenever a VM in the VPC-DI instance is rebooted. The standby CF and all Service Function (SF) VMs read this configuration file from the active CF.

This chapter provides instructions for connecting to the active CF console port and creating the initial local context management configuration.

The Quick Setup Wizard consists of three parts:

• Configuring a context-level security administrator and hostname

• Configuring the Ethernet interface for out-of-band (OOB) management

• Configuring the system for remote CLI access via Telnet, Secure Shell (SSH), or File Transfer Protocol (FTP)

The following figure and table provides a flow diagram that shows the run logic of the wizard along with additional information and notes.

Figure 1. StarOS Quick Setup Wizard Logic Diagram

Sample Quick Setup Script

This is how the setup script appears if you run the EXEC mode setup command:

[local]host_name# setup
1. Do you wish to continue with the Quick Setup Wizard[yes/no]: yes
2. Enable basic configuration[yes/no]: yes
3. Change chassis key value[yes/no]: yes
4. New chassis key value: chassis_key
5. Create new tech-support password[yes/no]: yes
6. New tech-support password: new_password
7. local context administrator username[admin]: context_admin_username
8. local context administrator password: context_admin_password
9. confirm local context administrator password: context_admin_password
10. hostname[asr5500]: hostname
  

The chassis key can be configured using the Quick Setup Script only if Cisco Elastic Services Controller (ESC) is not used to deploy the system. To configure a custom chassis key where ESC is used for deployment, you must specify the desired chassis key in ESC. For more information, refer to Onboarding the VPC-DI with ESC on OpenStack.

The initial configuration consists of the following:

• Configuring a context-level security administrator and hostname

• Configuring the Ethernet interface on the vNIC

• Configuring the VPC-DI instance for remote CLI access via SSH

This section provides instructions for performing these tasks using the CLI.

This section describes some of the security features that allow security administrators to control user accounts.

Configure the system for remote access. An administrative user may access the instance from a remote location over the management network:

• Telnet

• Secure Shell (SSH)

• File Transfer Protocol (FTP) (secured or unsecured)

• Trivial File Transfer Protocol (TFTP)

Note

If there are two simultaneous telnet sessions, and one administrator deletes the context into which the other administrator is logged, the administrator in the deleted context will not be automatically kicked into the local context. Although the deleted context will still appear in the CLI prompt, context specific commands will generate errors.

Note	For maximum security, use SSH v2.

SSHv2 RSA is the only version of SSH supported under StarOS. Keywords previously supported for SSHv1 RSA and SSHv2 DSA have been removed from or concealed within the StarOS CLI.

Version 1 of the SSH protocol is now obsolete due to security vulnerabilities. The v1-rsa keyword has been removed for the Context Configuration mode ssh command. Running a script or configuration that uses the SSHv1-RSA key returns an error message and generates an event log. The output of the error message is shown below:

CLI print failure Failure: SSH V1 contains multiple structural vulnerabilities and is no longer considered secure. Therefore we don't support v1-rsa SSH key any longer, please generate a new v2-rsa key to replace this old one.

If the system boots from a configuration that contains the v1-rsa key, you can expect a boot failure when logging in through SSH. The workaround is to log in via the Console port, re-generate a new ssh v2-rsa key, and configure server sshd. It will then be possible to log in via ssh.

The v2-dsa keyword is now concealed for the Context Configuration mode ssh command

The v1-rsa keyword has been removed from the Exec mode show ssh key CLI command.

If necessary, you can configure a second IP address on the vNIC management interface.

To prevent resource allocation issues, it is important that all VMs used for in the system have the same size CPU and the same size memory. To balance performance across all interfaces, make sure that the service ports and DI ports have the same throughput capabilities.

To verify the hardware configuration for all cards or a specific card, use the show cloud hardware [card_number} command. Sample output from this command on card 1 (CF) is shown here:

[local]s1# show cloud hardware 1

Card 1:
   CPU Nodes               : 1                               
   CPU Cores/Threads       : 8                               
   Memory                  : 16384M (qvpc-di-medium)          
   Hugepage size           : 2048kB                          
   cpeth0                  :
     Driver                : virtio_net
   loeth0                  :
     Driver                : virtio_net
  

Sample output from this command on card 3 (SF) is shown here:

[local]s1# show cloud hardware 1

Card 3:
   CPU Nodes               : 1                               
   CPU Cores/Threads       : 8                               
   Memory                  : 16384M (qvpc-di-medium)          
   Hugepage size           : 2048kB                          
   cpeth0                  :
     Driver                : vmxnet3
   port3_10                :
     Driver                : vmxnet3
   port3_11                :
     Driver                : vmxnet3
  

To display the optimum configuration of the underlying VM hardware, use the show hardware optimum. To compare your current VM configuration to the optimum configuration, use the show cloud hardware test command. Any parameters not set to the optimum are flagged with an asterisk, as shown in this sample output. In this example, the CPU cores/threads and memory are not configured optimally.

[local]s1# show cloud hardware test 1

Card 1:
   CPU Nodes               : 1                               
*  CPU Cores/Threads       : 8                                Optimum value is 4
*  Memory                  : 8192M (qvpc-di-medium)           Optimum value is 16384
   Hugepage size           : 2048kB                          
   cpeth0                  :
     Driver                : virtio_net
   loeth0                  :
     Driver                : virtio_net
  

To display the configuration file on the config disk or local flash, use the show cloud configuration card_number command. The location parameter file on flash memory is defined during the installation. And the config disk is usually created by the orchestrator and then attached to the card. Sample output from this command is shown here for card 1:

[local]s1# show cloud configuration 1

Card 1:
  Config Disk Params:
-------------------------
    No config disk available

  Local Params:
-------------------------
CARDSLOT=1
CARDTYPE=0x40010100
CPUID=0
  

To display the IFTASK configuration for all cards or a specific card, use the show cloud hardware iftask command. By default, the cores are configured to be used for both PMD and VNPU. Sample output from this command on card 4 is shown here:

[local]mySystem# show cloud hardware iftask 4
Card 4:
  Total number of cores on VM:      24
  Number of cores for PMD only:     0
  Number of cores for VNPU only:    0
  Number of cores for PMD and VNPU: 3
  Number of cores for MCDMA:        4
  Hugepage size:           2048 kB
  Total hugepages:     16480256 kB
  NPUSHM hugepages:           0 kB
  CPU flags: avx sse sse2 ssse3 sse4_1 sse4_2 
  Poll CPU's: 1 2 3 4 5 6 7 
  KNI reschedule interval: 5 us