Manual Chapter : Additional System Tasks

Applies To:

  • F5OS-C

    1.8.2, 1.8.1

back-action VELOS Systems: Administration and Configuration

Updated Date: 04/22/2026

Additional System Tasks

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

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

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.

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.

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*>

    Note: 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#

    Note: 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.

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.

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 Key migration overview.

For more information, see VELOS Systems: Backup, Restore, and Migration at Documentation - F5OS-C and VELOS.

Important: On v1.8.0 and later versions, configuration restore may fail if the backup configuration file includes tenant-console user entries without an associated tenant. To ensure a successful configuration restore or restore-to-default operation, you must manually remove any user entries with the tenant-console role (without the tenant) from the backup file. For more information, see F5OS-C 1.8.0 Fixes and known Issues Release Note.

It provides the capability to manage the platform services lifecycle, such as service restart and viewing status through the ConfD CLI.

Note: The docker restart commands should only be used for debugging or troubleshooting purposes and not recommended for any other purposes.

To restart the docker services, follow the steps below:

  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. Restart the docker services.

    system diagnostics os-utils docker restart node <*node name*> service <*service name*>

  4. Enter ‘yes’ to proceed.

    This example shows restarting the docker service for platform monitor:

    syscon-1-active(config)# system diagnostics os-utils docker restart node controller-1 service platform-monitor
Restarting container affects configuration and data path. Do you want to proceed? [yes/no] yes
result platform-monitor restarted successfully

    Note: The below list of services are restricted from docker restart.

    • Chassis system controller: controller-identifier
    • Chassis blade: part_*_vers
    • cc-switchd

To view the status of docker services, follow the steps below:

  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. Run the below command to view the docker status.

    show system diagnostics os-utils docker nodes node <*node name*> services service <*service name*>

    This example shows the status of platform monitor:

    syscon-1-active# show system diagnostics os-utils docker nodes node controller-1 services service platform-monitor
                                                           RESTART
  NAME              STATUS   STARTED AT                      COUNT
  --------------------------------------------------------------------
  platform-monitor  running  2024-07-16T11:27:54.736179846Z  0

To restart the docker services, follow the steps below:

  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. Restart the docker services.

    system diagnostics os-utils docker restart node <*node name*> service <*service name*>

  4. Enter ‘yes’ to proceed.

    This example shows restarting the docker service for platform monitor:

    default-1(config)# system diagnostics os-utils docker restart node blade-1 service platform-monitor
Restarting container affects configuration and data path. Do you want to proceed? [yes/no] yes
result platform-monitor restarted successfully

    Note: The below list of services are restricted from docker restart.

    • Partition: part_*_vers
    • dma-agent
    • line-dma-agent
    • firmware-fpga
    • firmware

To view the status of docker services, follow the steps below:

  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. Run the below command to view the docker status.

    show system diagnostics os-utils docker nodes node <*node name*> services service <*service name*>

    This example shows the status of platform monitor:

    default-1# show system diagnostics os-utils docker nodes node blade-1 services service platform-monitor
                                                           RESTART
  NAME              STATUS   STARTED AT                      COUNT
  --------------------------------------------------------------------
  platform-monitor  running  2024-07-16T11:27:54.736179846Z  0

If you want to restore previous version of software and system configuration during and post upgrade, you can log in to the system controller where you want to restore the previous version of software and system configuration from the CLI.

Note: You can restore previous version of the software from F5OS v1.8.0 and later versions.

  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. Initiate system rollback

    system rollback initiate

    This example rollback the software to the previous version and configuration:

    asyscon-1-active(config)# system rollback initiate
Initiating system rollback to the state created with version 1.8.0-7818 on 2024-03-27 04:44:31:00:00
This causes system to reboot and restore rollback version configuration
Proceed? [yes/no]: yes
response System rollback initiated successfully

  4. Commit the configuration changes.

    commit

Zeroization is the process of securely erasing sensitive information. This protects data integrity and prevents unauthorized access in situations where cryptographic modules are decommissioned, tampered with, or compromised.

You can securely erase sensitive data, typically cryptographic keys, in compliance with FIPS 140-3 standards by initiating the zeroization process.

  1. Connect to the system using a management console or console server.

    Note:

    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. Initiate zeroization

    system security fips-mode run-zeroization

    This example shows process of initiating zeroization:

    syscon-1-active(config)# system security fips-mode run-zeroization proceed yes 
Warning: Initiating zeroization will securely erase all cryptographic keys and sensitive data. 
This process is irreversible. Please ensure that you have backed up the controller, partitions and
tenants before proceeding. Are you sure you want to proceed? [Yes/No]: yes
response Zeroization is successful. Rebooting...

    It requires a few minutes for the device to complete the zeroization process.

After the zeroization process completes, all the cryptographic keys and sensitive data will be erased and all partitions will be deleted, followed by a system reboot.

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.

Important: If your system has been breached, consult your security team immediately.

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.

This table lists the available local attestation system integrity states for the Trusted Platform Module (TPM).

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.

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

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

You can display and verify the current local attestation status of the system from the CLI.

  1. Connect using SSH to the management IP address.

  2. Log in to the command line interface (CLI) of the system 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 the appliance.

    show components component state tpm-integrity-status

    A message similar to this example displays:

    appliance-1# show components component state tpm-integrity-status
          TPM
          INTEGRITY
NAME      STATUS
---------------------
platform  Valid