F5 Logo MyF5
Search
  1. MyF5 Home
  2. VELOS Systems: Administration and Configuration
  3. Additional System Tasks
Manual Chapter : Additional System Tasks

Applies To:

Show Versions Show Versions

F5OS-C

  • 1.5.1, 1.5.0
Manual Chapter

Additional System Tasks

Service provider features overview

Service Provider Disaggregation (SP-DAG) is supported on
VELOS
 systems.
For information on configuring service provider features for your BIG-IP tenant, see these documents in the BIG-IP LTM Knowledge Center at support.f5.com/csp/knowledge-center/software/BIG-IP?module=BIG-IP%20LTM:
  • BIG-IP Service Provider: Administration
  • BIG-IP Service Provider: Diameter Administration
  • BIG-IP Service Provider: Generic Message Administration
  • BIG-IP Service Provider: Message Routing Administration
  • BIG-IP Service Provider: SIP Administration

Configure the DAG hash function from the CLI

You can enable or disable the DAG hash function from the chassis partition CLI. This enables the use of TEID (tunnel endpoint identifier) instead of the default L4 port mode for DAG hashing. The setting is applied to all tenants running in the chassis partition.
  1. Connect using SSH to the chassis partition management IP address.
  2. Log in to the command line interface (CLI) of the chassis partition using an account with admin access.
    When you log in to the system, you are in user (operational) mode.
  3. Change to config mode.
    config
    The CLI prompt changes to include
    (config)
    .
  4. Configure the DAG hash function.
    system settings dag config gtp-u teid-hash { enabled | disabled }
  5. Commit the configuration changes.
    commit
  6. Return to user (operational) mode.
    end
  7. Verify the DAG hashing configuration.
     
    default-1# show system settings dag
system settings dag state gtp-u teid-hash enabled

Key migration overview

The
VELOS
 system uses an
encryption key
, also called the primary key, to encrypt and decrypt highly sensitive passphrases contained in the configuration database. You follow a
key migration
 process to set the encryption key on the system to a known value so that same key can be can set on another machine using same passphrase and salting. For more information, see the
Migrate system configuration from one system to another
 section.

Reset the primary key

You might consider resetting (or rotating) the encryption key periodically on a system for additional security.
  1. Log in to the command line interface (CLI) of the system controller using an account with admin access.
    When you log in to the system, you are in user (operational) mode.
  2. Change to config mode.
    config
    The CLI prompt changes to include
    (config)
    .
  3. Reset the primary key.
    system aaa primary-key set
  4. Commit the configuration changes.
    commit
The encryption key is reset (or refreshed) on the system.

Migrate system configuration from one system to another from the CLI

Before you can migrate the system configuration onto another
VELOS
 system, you must have completed the initial configuration of management IP addresses on the new system, and it must be in stable running condition. You also must be able to log in to the existing system.
In the case of a Return Material Authorization (RMA) or other situations when aligning multiple systems, you might need to migrate the system controller configuration from one system (the source) to another one (the destination). Such a migration requires that you set the same encryption key on both systems so that the encrypted elements are moved successfully along with the configuration. You can migrate the system configuration from the system controller CLI.
  1. Log in to the command line interface (CLI) of the system controller using an account with admin access.
    When you log in to the system, you are in user (operational) mode.
  2. Change to config mode.
    config
    The CLI prompt changes to include
    (config)
    .
  3. Set the primary key with the same passphrase on both the source and destination systems.
    system aaa primary-key set passphrase <
    known-pass
    > confirm-passphrase <
    known-pass
    > salt <
    known-salt
    > confirm-salt <
    known-salt
    >
    Be sure to make note of the salt and passphrase, as these are needed to restore the configuration on a replacement system.
    The system shows a message confirming that key migration has started: 
    Key migration is initiated. Use 'show system aaa 
primary-key state status' to get status
  4. Return to user (operational) mode.
    end
  5. Check the status of the primary key on both the source and destination systems.
    show system aaa primary-key state status
    A summary similar to this example displays: 
    system aaa primary-key state status 
 "COMPLETE Initiated: Thu Feb 18 01:37:53 2021"
  6. Check the primary key hash on both the source and destination systems.
    show system aaa primary-key state hash
    A summary similar to this example displays:
    system aaa primary-key state hash YTkPNw5nxY/nqgfyNjdHZUZ
WD1tfvxNY30+VAbSstzheCnE6Vy6aADftJKrVWY5W5w3UaQeRnwkT0NeFkb5Svg==
syscon-1-active#
    Be sure to make note of the primary key hash, as it is needed to restore the configuration on a replacement system.
  7. On the source system, save the system controller configuration.
    system database config-backup name <
    file-name
    >.xml
    System controller configuration backup files are located in
    configs/
    .
  8. Export the configuration backup file from the source system to an HTTPS server.
    file export local-file configs/<
    file-name
    >.xml remote-file /<file-path>/<
    filename
    >.xml remote-host <
    ip-address
    > username root
  9. When prompted, enter the password for the remote root account.
  10. Import the configuration backup onto the destination system from the HTTPS server.
    file import local-file configs/backup1.xml remote-file /tmp/backup1.xml remote-host <
    ip-address
    > username root
  11. When prompted, enter the password for the remote root account.
  12. Load the configuration backup onto the destination system.
    system database config-restore name <
    filename
    >.xml
    If the migration fails for any reason, the system automatically restores the previous configuration.
  13. Reset the primary key with a different password on both the source and destination systems (not required but recommended for security).
    system aaa primary-key set passphrase <
    known-pass
    > confirm-passphrase <
    known-pass
    > salt <
    known-salt
    > confirm-salt <
    known-salt
    >
The destination system now has the same system controller configuration as the original source system, including the encryption key. The system controller backup includes general partition management information, software version used on each partition, and which blades are associated with each partition. It does not include partition tenants and users or other partition details. This information is stored in the chassis partition configuration backups. You will still need to log in to each partition and restore its configuration.

Back up system configurations from the webUI

You can back up the configurations of the system controller or chassis partition in which you are working from the webUI.
  1. Log in to the VELOS system controller webUI or the chassis partition webUI using an account with admin access.
  2. On the left, click
    SYSTEM SETTINGS
    Configuration Backup
    .
  3. Click
    Create
    .
    The Create Configuration Backup popup opens.
  4. In the
    Name
     field, enter a name for the backup (for example, system-controller-12-21-21 or partition1-6-14-21).
  5. Click
    Create
    .
    The backup is created and added to the list.
  6. To delete a backup file, select the file and click
    Delete
    .
System controller and chassis partition configuration backups are stored in
configs/
. Backups should be stored off the system.
You can restore configurations from the CLI. For more information on saving and restoring the configuration, see the
Complete backup and restore overview
 section.

Chassis partition migration note

F5
 does not support migrating chassis partition configurations from one system to another. You can migrate an entire system controller configuration and then log in to each chassis partition to restore its configuration. If you attempt to migrate a chassis partition from one system to another independently of the system controllers, the chassis partition configuration will not be complete.

Complete backup and restore overview

Before you can perform a backup and restore, you must disable appliance mode, if it is enabled. There are a number of tasks recommended to perform a complete backup and restore of the
VELOS
 system
controllers, chassis partitions,
 and tenants on that same system.
If you want to move a system configuration from one system to another, you also need to perform a key migration. For more information, see Migrate system configuration from one system to another from the CLI.

Disable appliance mode from the CLI

You can disable appliance mode on the system controllers from the system controller CLI, and on the chassis partitions from the chassis partition CLI. You must have the appropriate permissions. While it is recommended that you enable appliance mode most of the time, some tasks, such as restoring the default configuration or running the Setup wizard, require use of the root account, which is unavailable in appliance mode. You can also disable appliance mode from the webUI or the API. To disable appliance mode from the webUI, see Configure appliance mode from the webUI or see the CLI and API References at Documentation - F5OS-C and VELOS.
  1. Log in to the command line interface (CLI) of the system controller or chassis partition using an account with admin access.
    When you log in to the system, you are in user (operational) mode.
  2. Check whether the system is in appliance mode:
    show system appliance-mode state
    If appliance mode is enabled, proceed to the next step to disable it. Otherwise, skip the rest of these steps.
  3. Change to config mode.
    config
    The CLI prompt changes to include
    (config)
    .
  4. Disable appliance mode:
    system appliance-mode config disabled
  5. Commit the configuration changes.
    commit
  6. Return to user (operational) mode.
    end

Tenant configuration backup

To back up the configuration for your tenants, log in to each tenant and back up the configuration using the method recommended for that tenant.
For
BIG-IP
 tenants
Create and save an archive (or UCS file), and then export the UCS backups to an external location. For more information, see the section titled "About managing archives using the Configuration utility" in
BIG-IP System: Essentials
 at K000130285: F5 Product Manuals Index.
For
BIG-IP Next
 tenants
For information about
BIG-IP Next
 tenant configuration backup, see the
F5
 Beta portal.

Back up chassis partition configuration from the CLI

For all configured chassis partitions, you can log in to the chassis partition CLI for each and back up the configuration.
  1. Connect using SSH to the chassis partition management IP address.
  2. Log in to the command line interface (CLI) of the chassis partition using an account with admin access.
    When you log in to the system, you are in user (operational) mode.
  3. Change to config mode.
    config
    The CLI prompt changes to include
    (config)
    .
  4. Create a backup of the chassis partition configuration.
    system database config-backup name partition-backup1.xml
    Chassis partition configuration backup files are located in
    configs/
    .
  5. Export the chassis partition configuration backup file onto an external system for safe keeping.
    file export local-file configs/partition-backup1.xml remote-file /tmp/partition-backup1.xml remote-host 192.0.2.75 username root
    The system requests the password for the remote root account. 
    Value for 'password' (<string>): *******
result File transfer is initiated.( configs/partition-backup1.xml)
  6. Optional: Check the status of the transfer.
    file transfer-status
You have a backup of the chassis partition configuration that you can restore on the same system where it was created, if needed. The chassis partition configuration backup includes all tenant deployments, users, and all partition information.

Back up system controller configuration from the CLI

When the system is configured for your environment, you can log in to the system controller CLI and back up the configuration.
  1. Connect using SSH to the system controller floating management IP address.
  2. Log in to the command line interface (CLI) of the system controller using an account with admin access.
    When you log in to the system, you are in user (operational) mode.
  3. Change to config mode.
    config
    The CLI prompt changes to include
    (config)
    .
  4. Create a backup of the system controller configuration.
    system database config-backup name backup1.xml
    System controller configuration backup files are located in
    configs/
    .
  5. Export the configuration backup file onto an external system for safe keeping.
    file export local-file configs/backup1.xml remote-file /tmp/backup1.xml remote-host 192.0.2.0 username root
    The system requests the password for the remote root account. 
    Value for 'password' (<string>): *******
result File transfer is initiated.(configs/backup1.xml)
You have a backup of the system configuration on the system controller that you can restore on the system if needed.

Delete chassis partition configuration from the CLI

You can delete existing chassis partition configurations by resetting the database on the chassis partition.
  1. Log in to the command line interface (CLI) of the chassis partition using an account with admin access.
    When you log in to the system, you are in user (operational) mode.
  2. Change to config mode.
    config
    The CLI prompt changes to include
    (config)
    .
  3. Delete the configuration by resetting the database.
    system database reset-to-default proceed yes
The chassis partition now has the default configuration as if it was just created.

Remove slots from chassis partitions from the CLI

You can remove slots from the chassis partitions to which they are assigned from the system controller CLI.
  1. Log in to the command line interface (CLI) of the system controller using an account with admin access.
    When you log in to the system, you are in user (operational) mode.
  2. Change to config mode.
    config
    The CLI prompt changes to include
    (config)
    .
  3. Set slots to none.
    slots slot <
    slot-number
    > partition none
    In this example, you clear slots 1 and 2:
    syscon-1-active(config)# slots slot 1 partition none
syscon-1-active(config-slot-1)#
syscon-1-active(config)# slots slot 2 partition none
  4. Commit the configuration changes.
    commit

Remove chassis partitions from the system controller from the CLI

You can remove chassis partitions from system controllers from the system controller CLI.
  1. Log in to the command line interface (CLI) of the system controller using an account with admin access.
    When you log in to the system, you are in user (operational) mode.
  2. Change to config mode.
    config
    The CLI prompt changes to include
    (config)
    .
  3. Remove chassis partitions from the system controller.
    no partitions partition <partition-name>
    In this example, you remove chassis partitions named part1 and part2:
    syscon-1-active(config)# no partitions partition part1
syscon-1-active(config)# no partitions partition part2
  4. Commit the configuration changes.
    commit

Reset system controller configuration to factory defaults from the CLI

Be sure that you have a backup of the existing configuration of the system controller before you go back to the defaults. You also have to have disabled appliance mode, if it is enabled.
Resetting the configuration to factory defaults from the system controller CLI might be useful if you are testing, performing an RMA, or for any other reason want to restore the system to its initial factory default settings.
Be sure you do this using a console connection because resetting the system to the default values removes the management network.
This procedure clears all existing configuration and regenerates the default configuration.
  1. Connect to the system using a management console or console server.
    The default baud rate and serial port configuration is 19200/8-N-1.
  2. Log in to the command line interface (CLI) of the system controller using an account with admin access.
    When you log in to the system, you are in user (operational) mode.
  3. Change to config mode.
    config
    The CLI prompt changes to include
    (config)
    .
  4. Reset the system to its default configuration.
    system database config reset-default-config true
    This command deletes all configuration on the system controller including IP addresses, passwords, all partition configuration, and tenant images.
  5. Commit the configuration changes.
    commit
  6. Reboot the system controllers if they do not reboot automatically:
    1. Change to config mode.
      config
      The CLI prompt changes to include
      (config)
      .
    2. Reboot a system controller.
      system reboot controllers controller {
      active
       |
      standby
       }
    The specified system controller reboots.
The system controller now has the default configuration. You need to perform initial configuration and can run the Setup wizard for a guided experience of setting management IP addresses, DNS, and other required settings. For more information on initial configuration, see
VELOS Systems: Getting Started
 at techdocs.f5.com.

Restore a system controller configuration from the CLI

If you want to restore a previously-saved system controller configuration, you can log in to the system controller where you want to load the configuration backup file and restore the saved configuration from the system controller CLI.
  1. Log in to the command line interface (CLI) of the system controller using an account with admin access.
    When you log in to the system, you are in user (operational) mode.
  2. Change to config mode.
    config
    The CLI prompt changes to include
    (config)
    .
  3. Import the configuration backup onto the destination system from the external system.
    file import local-file configs/<
    file-name
    >.xml remote-file /<file-path>/<
    filename
    >.xml remote-host <
    ip-address
    > username root
  4. When prompted, enter the password for the remote root account.
  5. Load the configuration backup onto the system controller.
    system database config-restore name <
    filename
    >.xml
    In this example you restore from a backup file named backup1.xml:
    syscon-1-active(config)# system database config-restore name backup1.xml
  response Succeeded.
    If the restore operation fails, the system automatically uses the previous configuration.
  6. Commit the configuration changes.
    commit
After you restore the system controller configuration, reboot all of the blades.

Restore a chassis partition configuration from the CLI

If you want to restore a previously-saved chassis partition configuration, you can log in to the chassis partition where you want to load the configuration backup file.
  1. Log in to the command line interface (CLI) of the chassis partition using an account with admin access.
    When you log in to the system, you are in user (operational) mode.
  2. Change to config mode.
    config
    The CLI prompt changes to include
    (config)
    .
  3. Import the configuration backup from the external system.
    file import local-file configs/<
    file-name
    >.xml remote-file /<file-path>/<
    filename
    >.xml remote-host <
    ip-address
    > username root
  4. When prompted, enter the password for the remote root account.
  5. Load the chassis partition backup onto the chassis partition.
    system database config-restore name <
    filename
    >.xml
    In this example you restore from a backup file named partition-backup1.xml:
    default-1(config)# system database config-restore name partition-backup1.xml
  response Succeeded.
    If the restore operation fails, the system automatically uses the previous configuration.
  6. Commit the configuration changes.
    commit

Restore tenant configuration

To restore the configuration for your tenants, log in to each tenant and restore the configuration using the method recommended for that tenant. You must upload the required tenant images to start the tenant after a restore on another system. The tenant will not start without the proper image on the system.
For
BIG-IP
 tenants
Restore an archive (or UCS file) from an external location. For more information, see the section titled "Restore data from an archive using the Configuration utility" in
BIG-IP System: Essentials
 at K000130285: F5 Product Manuals Index .
For
BIG-IP Next
 tenants
For information about
BIG-IP Next
 tenant configuration restore, see the
F5
 Beta portal.

Trusted Platform Module (TPM) overview

A Trusted Platform Module (TPM) is a hardware device that implements security functions to provide the ability to determine a trusted computing environment, allowing for an increased assurance of trust that a device behaves for its intended purpose. The TPM chain of custody provides assurance that the software loaded on your platform at startup time has the same signature as the software that is loaded by F5 when the system is manufactured.
These measurements include taking hashes of most of the BIOS code, BIOS settings, TPM settings, tboot, Linux Initrd, and Linux kernel (initial
VELOS
 release only validates BIOS) so that alternative versions of the measured modules cannot be easily produced and so that the hashes lead to identical measurements. You can use these measurements to validate against known good values.
Both of the system controllers, as well as all the blades (BX110) have a TPM chipset.
For the initial
VELOS
 release, local attestation is done automatically at boot time and can be displayed in the CLI.
The TPM implements protected capabilities and locations that protect and report integrity measurements using Platform Configuration Registers (PCRs). The TPM also includes additional security functionality, including cryptographic key management, random number generation, and the sealing of data to system state.
Your TPM-equipped
VELOS
 system comes with functionality to aid in local attestation and confirming chain of custody for the device locally without the need for doing it manually.
If your system has been breached, consult your security team immediately.

Local attestation overview

You can perform local attestation on your
VELOS
 system of the Trusted Platform Module (TPM) chain of custody using the Platform Configuration Register (PCR) values to confirm that the firmware is unmodified.

Available local attestation system integrity states

This table lists the available local attestation system integrity states for the Trusted Platform Module (TPM).
State
Description
Not Supported
Indicates that the system does not have the capability to perform System Integrity Measurements.
Pending
Indicates that the system is not yet ready to produce a System Integrity Measurement and evaluate the reference values.
Valid
Indicates that the solicited System Integrity Measurement matches one of the sets of reference values in the local System Integrity Reference Repository (SIRR).
Invalid
Indicates that the System Integrity Measurement has been taken without error, but the values do not match any set of acceptable values in the local System Integrity Reference Repository. This could mean that the SIRR is out of date or that the system has been tampered with.
Unavailable
Indicates that an error has occurred.

Display the local attestation status of a system controller

You can display and verify the current local attestation status of a system controller from the system controller CLI.
  1. Connect using SSH to the system controller floating management IP address.
  2. Log in to the command line interface (CLI) of the system controller or chassis partition using an account with admin access.
    When you log in to the system, you are in user (operational) mode.
  3. Display the current local attestation status of a specified system controller.
    show components component [ controller-1 | controller-2 ] state tpm-integrity-status
    A message similar to this example displays the current status: 
    syscon-1-active# show components component controller-1 state tpm-integrity-status
state tpm-integrity-status Valid

Display the local attestation status of a blade

You can display and verify the current local attestation status of a blade from the chassis partition CLI.
  1. Connect using SSH to the chassis partition management IP address.
  2. Log in to the command line interface (CLI) of the chassis partition using an account with admin access.
    When you log in to the system, you are in user (operational) mode.
  3. Display the current local attestation status of a specified blade.
    show components component [ blade-1 | blade-2 | blade-
    n
     } state tpm-integrity-status
    A message similar to this example displays the current status: 
    default-1# show components component blade-1 state tpm-integrity-status
state tpm-integrity-status Valid
Contact Support Contact Support

Have a Question?

Support and Sales >

About F5

Education

F5 Sites

Support Tasks




©2023 F5, Inc. All rights reserved.


Trademarks Policies Privacy California Privacy Do Not Sell My Personal Information