Manual Chapter : Tenant Management

Applies To:

Show Versions

F5OS-C

1.8.2, 1.8.1

Tenant Management

Tenants overview

tenant

is a guest system running software in a chassis partition (for example, a

BIG-IP

system).

VELOS

systems support multitenancy, in that you can run several tenants in the same chassis partition, including BIG-IP and BIG-IP Next tenants. The maximum number of lightweight tenants that can be created in a blade is 22. Each blade has 128GB memory, of which 95GB is reserved for tenants. Each lightweight tenant requires a minimum of one vCPU and 4096MB minimum memory.

Information about

BIG-IP Next

is available on my.f5.com, on clouddocs.f5.com, and in the article How to: Configure multi-tenancy for BIG-IP Next on VELOS.

The administrator can connect to the tenant’s webUI, CLI, or REST API and have the same experience as on their existing

platforms. A tenant on the

VELOS

platform is managed similarly to how a vCMP guest is managed today on the VIPRION platform. The tenant is assigned dedicated vCPU and memory resources and is restricted to specific VLANs for network connectivity.

The chassis partition administrator is responsible for configuring tenant deployments within the chassis partition. Once a tenant has been deployed, there is a per-tenant administrator role, whose responsibilities include configuring the services that are available on that tenant.

Tenants inherit certain capabilities, such as the license, VLANs, and management interface speed, from the

chassis partition

. Do not try to install a new license or delete the existing license on the tenants. Tenant admins cannot configure global

partition-wide

parameters. You configure these at the platform layer, and values are propagated to all tenants in the

chassis partition

Also see knowledge article Overview of the BIG-IP tenant image types

Consider the following points while referring to the term slot:

Scenario1: Here, the term slot
refers to the number of boot locations
inside a TMOS image. Images can be either single slot or dual slot. Single slot image has only one boot location and does not support in-place upgrades. Dual slot images will have 2 boot locations and supports in-place upgrades to different TMOS versions.

Scenario 2: When deploying an F5OS tenant on VELOS, you can select the physical slots in the chassis that you want a tenant to run on. Here the term slot
is used instead of the term blade
, because you can pre-configure to run on a slot which does not have a blade installed yet.

Tenant data

This table lists tenant data specifications for

VELOS

systems.

Tenant data for VELOS systems
Tenant Size (vCPUs per tenant)	Physical Cores	Logical Cores (vCPU)	Minimum GB RAM	RAM/vCPU
BX110 blade with 1 vCPU/tenant	0.5	1	4096	4096
BX110 blade with 2 vCPU/tenant	1	2	7680	3840
BX110 blade with 4 vCPU/tenant	2	4	14848	3712
BX110 blade with 6 vCPU/tenant	3	6	22016	3669.3
BX110 blade with 8 vCPU/tenant	4	8	29184	3648
BX110 blade with 10 vCPU/tenant	5	10	36352	3635.2
BX110 blade with 12 vCPU/tenant	6	12	43520	3626.6
BX110 blade with 14 vCPU/tenant	7	14	50688	3620.6
BX110 blade with 16 vCPU/tenant	8	16	57856	3616
BX110 blade with 18 vCPU/tenant	9	18	65024	3612.4
BX110 blade with 20 vCPU/tenant	10	20	72192	3609.6
BX110 blade with 22 vCPU/tenant	11	22	79360	3607.3
BX520 blade with 4 vCPU/tenant	2	4	14,848	3,712
BX520 blade with 8 vCPU tenant	4	8	29,184	3,648
BX520 blade with 12 vCPU tenant	6	12	43,520	3,626
BX520 blade with 16 vCPU tenant	8	46	57,856	3,616
BX520 blade with 20 vCPU tenant	10	20	72,192	3,609
BX520 blade with 24 vCPU tenant	12	24	86,528	3,605
BX520 blade with 28 vCPU tenant	14	28	100,864	3,602
BX520 blade with 32 vCPU tenant	16	32	115,200	3,600
BX520 blade with 36 vCPU tenant	18	36	129,536	3,598
BX520 blade with 40 vCPU tenant	20	40	143,872	3,596
BX520 blade with 44 vCPU tenant	22	44	158,208	3,595
BX520 blade with 48 vCPU tenant	24	48	172,544	3,594
BX520 blade with 52 vCPU tenant	26	52	186,880	3,593
BX520 blade with 56 vCPU tenant	28	56	201,216	3,593
BX520 blade with 60 vCPU tenant	30	60	215,552	3,592
BX520 blade with 64 vCPU tenant	32	64	229,888	3,592
BX520 blade with 68 vCPU tenant	34	68	244,224	3,591
BX520 blade with 72 vCPU tenant	36	72	258,560	3,591
BX520 blade with 76 vCPU tenant	38	76	272,896	3,590
BX520 blade with 80 vCPU tenant	40	80	287,232	3,590
BX520 blade with 84 vCPU tenant	42	84	301,568	3,590
BX520 blade with 88 vCPU tenant	44	88	315,904	3,589
BX520 blade with 92 vCPU tenant	46	92	330,240	3,589
BX520 blade with 96 vCPU tenant	48	96	344,576	3,589

Tenants in a chassis partition example

VELOS CX410 Chassis

In this diagram, a

VELOS

CX410 chassis is divided into three chassis partitions (Red, Green, and Blue). These chassis partitions are completely isolated from each other, and the system controllers ensure that no traffic can jump from one chassis partition to another. After creating a chassis partition, you can deploy individual tenants. These tenants are restricted only to the resources within that chassis partition.

In the figure, the Red and Blue chassis partitions each span two blades and both have four tenants residing on them. The Green chassis partition spans four blades and has one tenant, Tenant 9, on it. Presumably, Tenant 9 is handling a large amount of traffic and requires more bandwidth and more processing power than the other tenants.

VELOS CX1610 chassis

In this diagram, a VELOS CX1610 chassis is divided into two chassis partitions (Red and Green). These chassis partitions are completely isolated from each other, and the system controllers ensure that no traffic can jump from one chassis partition to another. After creating a chassis partition, you can deploy individual tenants. These tenants are restricted only to the resources within that chassis partition.

In the figure, the Red and Green chassis partitions each span eight blades and one has two tenants and the other has four tenants residing on them, respectively. The Red chassis partition spans eight blades and has two tenants, Tenant 1 and 2, on it. Tenants 1 and 2 are handling a large amount of traffic and require more bandwidth and more processing power than the other tenants.

Tenant image overview

BIG-IP tenant images

These

BIG-IP

tenant images are available to deploy on

VELOS

systems:

ALL-F5OS

T4-F5OS

T2-F5OS

T1-F5OS (see note)

T1-F5OS has limitations, so using the other images is recommended. Other images must be downloaded from F5 Downloads.

Each image type has different uses so you need to be sure to use the correct type for your tenant needs. For additional information about BIG-IP tenant image types, see K45191957: Overview of the BIG-IP tenant image types.

F5OS-C v1.8.2 or later releases supports BIG-IP tenant software packages in the .tar.bundle
format only. This file is available from the same location on the MyF5 Downloads site.

BIG-IP Next tenant images

Information about BIG-IP Next tenant image types is available on my.f5.com.

Tenant usage

This table lists general use cases for

BIG-IP

tenant images. Information about

BIG-IP Next

tenant images is available on my.f5.com.

Tenant image	Description of Use
ALL-F5OS	Use case: Need multi-tenancy, multi-module, and service chaining Supports provisioning all VELOS-supported modules * (also called all-instance image) Requires minimum 2 boot locations Live-upgradable * See the VELOS data sheet for all currently-supported features.
T4-F5OS	Use case: Single tenant with multiple modules or Super-VIP scenario (virtual IP that spans multiple blades) Supports provisioning all modules with increased capacity Requires minimum 2 slots Live-upgradable
T2-F5OS	Use case: Need maximum tenant density, maximum tenants per blade Supports provisioning LTM or DNS only Requires 2 slots Live-upgradable
T1-F5OS	Use case: Need maximum tenant density, maximum tenants per blade Supports lightweight LTM or DNS only (also called micro-instance) Requires 1 slot You cannot upgrade or apply a hotfix to the system

Tenant sizing

Each image has different sizing requirements. You will need to understand the size of the chassis partition and the tenant requirements to determine the number and type of tenants you can deploy. The amount of memory and disk space that a tenant actually needs is dependent on the number of modules provisioned and its use. This table provides information about

BIG-IP

tenant sizing. For information about

BIG-IP Next

tenant sizing, see my.f5.com.

Tenant image	Disk size	Minimum memory	Minimum # vCPUs	Max tenants per blade
T1-F5OS	22 GB	4 GB	1	22
T2-F5OS	45 GB	8 GB	2	11
ALL-F5OS	77/82 GB²	8 GB	2	9
T4-F5OS	142 GB	8 GB	2	4

Tenant resource allocation considerations

These are recommended resource considerations for determining the amount of memory (RAM) to allocate when planning tenant deployments on

VELOS

systems:

Each

VELOS

blade has up to 95GB of memory that can be allocated to tenants.

The minimum memory allocation for a tenant depends on the number of vCPUs requested.

This formula is used for default memory allocation

min-memory = (3.5 * 1024 * vcpu-cores-per-node) + 512

You can specify more than the minimum amount of memory when configuring a tenant, if needed.

These are some of the resource considerations for disk space when planning tenant deployments on

VELOS

systems:

Each

VELOS

blade has approximately 600GB of disk storage available for tenants.

The amount of disk space that a tenant actually needs is dependent on the number of modules provisioned and its use.

As the aggregate disk usage within deployed tenants increases, the host disk can start to reach capacity on systems with many large tenants. The chassis partition administrator will need to monitor disk usage to make sure there is sufficient space for the tenants.

Tenant management from the webUI

Manage tenant images from the webUI

You can add or delete tenant images within a chassis partition from the chassis partition webUI. You must use HTTPS image import or export. Note that tenant images are specific to the

VELOS

system, and the software version must be compatible with it.

On the left, click

TENANT MANAGEMENT

Tenant Images

To upload an image, click

Upload

and browse to the image location.

To import an image:

Click

Import

A popup opens.

For

URL

, enter the URL of the remote image server.

F5 recommends that the remote host be an HTTPS server with PUT/POST enabled and have a valid CA-signed certificate. You can opt to select the

Ignore Certificate Warnings

check box if you want to skip the certificate check.

For

Username

, type the user name for an account on the remote image server, if required.

For

Password

, type the password for the account, if required.

Select

Ignore Certificate Warnings

to skip the certificate check.

Click

Import Image

Depending on the image file size and network availability, the import might take a few minutes. If you want to cancel the in-progress file transfer operation, click

Cancel

. When the import is successful, the software image is listed in the webUI.

To delete a tenant image, select the image and click

Delete

. It is recommended that you wait 5-10 minutes after deleting a tenant before deploying another tenant.

After you have added the tenant images that you want to use to the chassis partition, you can create and deploy tenants that will use that software image. The tenant image must be one that is listed as compatible with the

VELOS

system.

Create and deploy tenants from the webUI

Before you get started, be sure that you have already imported the tenant images that you want to use for the tenant deployments into the chassis partition. You need to know into which slots you want to deploy the tenant. You must also have previously created any required VLANs in the chassis partition. Before you can create and deploy tenants, you also need to estimate resource requirements so you know how many vCPUs, memory, and other options to assign to the tenant.

The chassis partition administrator can deploy tenants from the chassis partition webUI.

On the left, click

TENANT MANAGEMENT

Tenant Deployments

The Tenant Deployment screen displays showing the existing tenant deployments and associated details.

To add a tenant deployment, click

Add

The Add Tenant Deployment screen displays.

For

Name

, enter a name for the tenant deployment (up to 49 characters).

The first character in the name cannot be a number. After that, only lowercase alphanumeric characters and hyphens are allowed.

For

Type

, select the tenant type:

BIG-IP

BIG-IP Next

If you select

BIG-IP Next

, the

Deployment File

field displays. Select the deployment file.

For

Image

, select the software image that was previously imported onto the system.

Ensure that the image you selected meets your tenant deployment needs.

For

Allowed Slots

, first select the appropriate option, and then select the slots (or blades) that you want the tenant to span from the list:

Option	Description
Partition Member Slots	Lists only slots included in the chassis partition you are logged into.
Any Slots	Lists any slot on the chassis even if not associated with the chassis partition, and even if no blade is installed in that slot. You have the option of selecting slots 1-8 whether or not they are associated with the chassis partition. This enables you to preconfigure tenant deployments before the hardware is installed and before the chassis partition is configured to include it.

For

IP Address

, enter the IPv4 address, IPv6 address, or Fully Qualified Domain Name (FQDN) for the tenant.

For

Prefix Length

, enter a number for the length of the prefix.

The maximum prefix length is 32 for IPv4 and 128 for IPv6.

For

Gateway

, enter the IPv4 address or IPv6 address of the gateway.

For

VLANs

, select one or more VLANs that are available to the tenant.

You can assign VLANs to more than one tenant in the same partition.

For

MAC Data/MAC Block Size

, select one of these options:

One	Represents a block with one MAC. This is used when l2-inline-device functionality is not needed. This is the default value.
Small	Represents a block of 8 MACs. When this value is used, the l2-inline-device is enabled, and the tenant gets a block of 8 contiguous MACs.
Medium	Represents a block of 16 MACs. When this value is used, the l2-inline-device is enabled, and the tenant gets a block of 16 contiguous MACs.
Large	Represents a block of 32 MACs. When this value is used, the l2-inline-device is enabled, and the tenant gets a block of 32 contiguous MACs.

For

DAG IPv6 Prefix Length

, enter the prefix length used by disaggregator algorithms.

The range is from 1 to 128, with a default value of 128.

For more information about the prefix length, see Configure DAG IPv6 prefix length from the CLI.

For

Resource Provisioning

, select one of these options:

Option	Description
Recommended	Recommended values for vCPUs and memory for the tenant.
Advanced	Enables you to configure custom values for vCPUs and memory on the tenant. For example, if you want to configure a single vCPU tenant, or a tenant that uses more than the recommended amount of memory per slot.

For

vCPUs Per Slot

, select the number of vCPUs to provide to the tenant.

The minimum recommended number of vCPUs per typical tenant is two (one vCPU is sufficient only for lightweight tenants that cannot be updated). Each blade has up to 22 vCPUs. The number of vCPUs needed depends on the amount of traffic the tenant will be handling. More vCPUs provide faster throughput.

For

Memory Per Slot

, specify the amount of RAM, in MB, to allocate to the tenant.

The amount of memory needed depends on the number of vCPUs assigned. The minimum amount of memory needed is determined by the formula

[(3.5 * 1024 * #ofvCPUs) + 512]

, so a two vCPU tenant needs a minimum of 7680 MB, and a four vCPU tenant needs a minimum of 14,848MB.

If you do not allocate sufficient memory, you receive a warning message.

For

Virtual Disk Size

, specify the storage quota, in GB, for the tenant virtual disk.

The default size is 82 GB.

For

State

, select one of these options:

Options	Description
Configured	The tenant configuration exists on the chassis partition, but the tenant is not running, and no hardware resources (CPU, memory) are allocated to it. This is the initial state and the default.
Provisioned	Moves the tenant into the Provisioned state, which causes the system to install the software, assign the tenant to nodes, and create virtual disks for the tenant on those nodes. If you choose this option, it takes a few minutes to complete the provisioning. The tenant does not run while in this state.
Deployed	Changes the tenant to the Deployed state. The tenant is set up, resources are allocated to the tenant, the image is moved onto the blade, the software is installed, and after those tasks are complete, the tenant is fully deployed and running. If you choose this option, it takes a few minutes to complete the deployment and bring up the system. Once a tenant is Deployed (and is up and running), changing its state back to Configured or Provisioned stops the tenant. You will receive a warning message before this occurs.

For

Crypto/Compression Acceleration

, select

Enabled

if the tenant requires high-performance crypto processing and compression.

When this option is enabled, the tenant receives dedicated crypto devices proportional to number of vCPU cores. Crypto processing and compression are off-loaded to the hardware. When the option is disabled, the tenant receives no crypto devices. This is not supported on BIG-IP Next.

To restrict usage of the Bash shell for tenant administrators, set

Appliance Mode

Enabled

(this is

Disabled

by default.)

Click

Save & Close

The tenant is now configured and in the Deployed state. When the status says Running, the tenant administrator can log in to the tenant webUI or CLI using the management IP address (with HTTPS or SSH) and continue configuring the tenant system.

If the Status says Pending instead of Running, this may mean that there are not enough resources (vCPUs, memory, or other resources) for the tenant to be deployed. See the Tenant Details screen in the chassis partition webUI for more information about the specific tenant.

Modify tenant deployments from the webUI

Depending on the state that the tenant is in, you can change certain tenant settings from the chassis partition webUI. The settings which cannot be modified will be grayed out.

Deployed

: You can add or remove

Allowed Slots

or change the

State

only while tenants are active and running.

Once a tenant is Deployed (and is up and running), changing its state back to Provisioned or Configured stops the tenant. You will receive a warning message before this occurs.

Provisioned

: You can change all settings except

Image

Configured

: You cannot change any settings once the tenant has been configured.

On the left, click

TENANT MANAGEMENT

Tenant Deployments

The Tenant Deployment screen displays showing the existing tenant deployments and associated details.

Click the name of the tenant deployment you want to modify.

The Tenant Deployment screen displays.

For

Image

, select a different software image to use for the tenant.

Only BIG-IP Next Tenant image can be modifed when the tenant is in deployed state, which essentially upgrades the tenant

To update

Allowed Slots

, select the slots (or blades) that you want the tenant to span from the list.

You can change the

IP Address

Prefix Length

(1-32), and

Gateway

for the tenant, if in Configured or Provisioned state. Enter an IPv4 address or IPv6 address.

For

VLANs

, you can select different VLANs for the tenant, if in Configured or Provisioned state.

For

Resource Provisioning

, if changing resources, select either:

Recommended

(to use recommended values) or

Advanced

(to customize values), if in Configured or Provisioned state.

For

vCPUs Per Slot

, select the number of vCPUs for the tenant, if in Configured or Provisioned state.

For

Memory Per Slot

, specify the amount of RAM in MB to allocate to the tenant, if in Configured or Provisioned state.

The amount of memory needed depends on the number of vCPUs assigned. The minimum amount of memory needed is determined by the formula

[(3.5 * 1024 * #ofvCPUs) + 512]

, so a two vCPU tenant needs a minimum of 7680 MB, and a four vCPU tenant needs a minimum of 14,848MB.

Change

State

(with caution!):

Option	Description
Configured	If tenant has been Provisioned or Deployed, the virtual disk is deleted.
Provisioned	If Deployed, this option stops the tenant from running, but maintains the configuration. If Configured, causes the system to install the software, assign the tenant to nodes, and create virtual disks for the tenant on those nodes. The tenant does not run, consume resources, or pass traffic.
Deployed	Directly deploy the tenant. This sets up the tenant, allocates resources, moves the image onto the blade, and installs the software. When these tasks are complete, the tenant is fully deployed and running.

Change

Crypto/Compression Acceleration

only if the tenant is in either the Configured or Provisioned state.

To restrict usage of the Bash shell for tenant administrators, set

Appliance Mode

Enabled

(this is

Disabled

by default.)

Click

Save & Close

The tenant is reconfigured according to the changes made.

Enable appliance mode on tenants

You can enable appliance mode for deployed tenants from the chassis partition webUI.

For greater security, consider configuring tenants to run in appliance mode.

On the left, click

TENANT MANAGEMENT

Tenant Deployments

The Tenant Deployment screen displays showing the existing tenant deployments and associated details.

Click the name of a tenant deployment.

Set

Appliance Mode

Enabled

Click

Save

Root or Bash access is disabled on the tenant. Users can still access the tenant from the webUI or the CLI.

Display tenant status and statistics from the webUI

You can monitor data and metrics related to the usage, performance, and behavior of the tenant from the webUI. These statistics are crucial for monitoring, managing, and optimizing the tenant. You can monitor the following tenant details:

Tenant CPU Usage

: Shows the measurement of CPU utilization by the tenant.

Tenant Memory Usage

: Shows the measurement of memory utilization by the tenant.

Tenant Disk Usage

: Shows the measurement of disk utilization by the tenant.

On the left, click

TENANT MANAGEMENT

Tenant Details

Select a tenant from the

Tenant Name

dropdown to see the tenant status and statistics.

You can now see the following statistics and status of the tenant.

Tenant CPU Usage

: Displays the tenant’s vCPU’s current utilization by default. However, if multiple vCPUs are available, you can select a vCPU and change the time series to view the historical data and analyze the vCPU utilization.

Tenant Memory Usage

: Displays the tenant’s current memory utilization by default. However, you can change the time series to view ‌historical data and analyze ‌memory utilization.

Tenant Disk Usage

: Displays the overall tenant disk current utilization by default. However, if you need the utilization stats of a specific disk, select the disk, data type, and change the time series to view the historical data and analyze the disk utilization.

Tenant Status

: Shows the overall status of the tenant image such as Node, Instance ID, Phase, Pod name, Creation time, Ready time, Status, and Management MAC details.

Select the interval from the

Auto Refresh

dropdown to refresh the data displayed or click the refresh icon to update the tenant data immediately.

The utilization data does not depend on the refresh interval. It will continue to collect utilization statistics for the tenant regardless of the selected reload interval.

Tenant management from the CLI

Import a tenant image from the CLI

Before you get started, you might want to upload the tenant image you want to use to a local Linux server that uses HTTPS, so you can more easily import it to the

VELOS

system.

You can import a tenant image into a chassis partition from the CLI.

When you log in to the system, you are in user (operational) mode.

Import a tenant image to the chassis partition.

file import remote-port <port-number> username <user> password <password> remote-host <ip-address-or-fqdn> remote-file <remote-file-path> remote-url <full-remote-url> local-file images

This example imports a

BIG-IP

tenant image from server.company.com:

default-1(config)# file import username admin password remote-url 
  https://server.company.com/images/BIGIP-1x.x.x-x.x.x.ALL-F5OS.qcow2.zip.bundle 
  local-file images

Create and deploy tenants from the CLI

You can create and deploy tenants in a chassis partition from the CLI.

When you log in to the system, you are in user (operational) mode.

Change to config mode.

config

The CLI prompt changes to include

(config)

Create and deploy the tenant.

tenants tenant <tenant-name> config <options>

For more information about CLI options, see Tenant CLI command syntax.

This example creates a

BIG-IP

tenant named

velos-bigip

that spans two nodes and is in the Configured running state, by default:

default-1(config)# tenants tenant velos-bigip config type BIG-IP image  
  BIGIP-1x.x.x-x.x.x.ALL-F5OS.qcow2.zip.bundle mgmt-ip 192.0.2.200
  prefix-length 24 gateway 192.0.2.254 nodes [ 1 2 ]

This example creates a

BIG-IP

tenant named

velos-bigip

that spans 16 nodes and is in the Configured running state, by default:

default-1(config)# tenants tenant velos-bigip config type BIG-IP image BIGIP-1x.x.x-x.x.x.ALL-F5OS.tar.bundle mgmt-ip 192.0.2.200 prefix-length 24 gateway 192.0.2.254 max-nodes 16

Once the tenant has been deployed, you cannot ‌set the configuration back to eight blades. Set the configuration to 16 blades only if the tenant is planned to consume more than eight blades.

For more information about DAG IPv6 prefix length, see Configure DAG IPv6 prefix length from the CLI.

Commit the configuration changes.

commit

Monitor the operational state of the tenant and move the tenant into the provisioned state.

tenants tenant <tenant-name> config running-state provisioned

This example moves the tenant into the provisioned state, which causes the system to start and maintain VMs on each node to which the tenant is assigned.

default-1# tenants tenant velos-bigip config running-state provisioned

This causes the system to assign the tenant to nodes and create virtual disks for the tenant on those nodes.

Show the current status for the tenant:

show tenants tenant <tenant-name>

When the system is creating the virtual disk and installing the image on a disk, the operational state of the tenant shows this information:

PHASE – Allocating resources to the tenant is in progress

status – Provisioning

A summary similar to this example displays:

default-1# show tenants tenant velos-bigip
tenants tenant velos-bigip
 state unit-key-hash oa9gv8VYHcSoApv1234GQMn2uM9UzNKiDz78cIbqKv26LVjlIo9TCdp56z5UnXcVvr3hj0/ym2kbdWyBhPbkLA==
 state type          BIG-IP
 state image         BIGIP-bigip15.1.x-europa-15.1.5-0.0.222.ALL-F5OS.qcow2.zip.bundle
 state nodes         [ 1 2 ]
 state mgmt-ip       192.0.2.59
 state prefix-length 24
 state gateway       192.0.2.254
 state cryptos       enabled
 state vcpu-cores-per-node 2
 state memory        7680
 state storage size 76
 state running-state deployed
 state mac-data base-mac 00:94:a1:8e:70:0a
 state mac-data mac-pool-size 1
 state appliance-mode disabled
 state status        Provisioning
 state image-version "BIG-IP 15.1.5 0.0.222"
 state instances instance 1
  instance-id   1
  phase         Running
  image-name    BIGIP-bigip15.1.x-europa-15.1.5-0.0.222.ALL-F5OS.qcow2.zip.bundle
  creation-time 2022-12-01T19:56:49Z
  ready-time    2022-12-01T19:56:49Z
  status        "Allocating resources to tenant is in progress"
  mgmt-mac      f2:48:a7:f1:aa:ab
 state instances instance 2
  instance-id   2
  phase         Running
  image-name    BIGIP-bigip15.1.x-europa-15.1.5-0.0.222.ALL-F5OS.qcow2.zip.bundle
  creation-time 2022-12-01T19:56:50Z
  ready-time    2022-12-01T19:56:50Z
  status        "Allocating resources to tenant is in progress"
  mgmt-mac      f2:48:a7:f1:aa:ab

When the system completes the virtual disk creation, the operational state shows this information:

PHASE – Ready to deploy

status – Provisioned

A summary similar to this example displays:

default-1# show tenants tenant velos-bigip
tenants tenant velos-bigip
 state unit-key-hash oa9gv8VYHcSoApv1234GQMn2uM9UzNKiDz78cIbqKv26LVjlIo9TCdp56z5UnXcVvr3hj0/ym2kbdWyBhPbkLA==
 state type          BIG-IP
 state image         BIGIP-bigip15.1.x-europa-15.1.5-0.0.222.ALL-F5OS.qcow2.zip.bundle
 state nodes         [ 1 2 ]
 state mgmt-ip       192.0.2.59
 state prefix-length 24
 state gateway       192.0.2.254
 state cryptos       enabled
 state vcpu-cores-per-node 2
 state memory        7680
 state storage size 76
 state running-state deployed
 state mac-data base-mac 00:94:a1:8e:70:0a
 state mac-data mac-pool-size 1
 state appliance-mode disabled
 state status        Provisioned
 state image-version "BIG-IP 15.1.5 0.0.222"
 state instances instance 1
  instance-id   1
  phase         "Ready to deploy"
  image-name    BIGIP-bigip15.1.x-europa-15.1.5-0.0.222.ALL-F5OS.qcow2.zip.bundle
  creation-time ""
  ready-time    ""
  status        " "
 state instances instance 2
  instance-id   2
  phase         "Ready to deploy"
  image-name    BIGIP-bigip15.1.x-europa-15.1.5-0.0.222.ALL-F5OS.qcow2.zip.bundle
  creation-time ""
  ready-time    ""
  status        " "

You can then deploy the tenant.

tenants tenant <tenant-name> config running-state deployed

This example moves the tenant into the deployed state, which causes the system to start and maintain VMs on each node to which the tenant is assigned.

default-1# tenants tenant velos-bigip config running-state deployed

Commit the configuration changes.

commit

You can check the status of the tenant.

show tenants tenant <tenant-name> state instances

A summary similar to this example displays:

default-1# show tenants tenant velos-bigip state instances
      INSTANCE
NODE  ID        PHASE    IMAGE NAME          CREATION TIME     READY TIME        STATUS                  MGMT...
----------------------------------------------------------------------------------------------------------------
1     1         Running  BIGIP-bigip15.1...  2022-12-01T23...  2022-12-01T23...  Started tenant instance ce:1...
2     2         Pending  BIGIP-bigip15.1...  2022-12-01T23...  2022-12-01T23...  Started tenant instance 22 5..

After you configure and deploy the tenant, and the Status is updated to Running, then you can use the management IP address to access the tenant system using SSH, the web-based Configuration utility, or TMOS Shell (

tmsh

Once a tenant is Deployed (and is up and running), changing its state back to Configured or Provisioned stops the tenant. You will receive a warning message before this occurs.

If the Status is Pending instead of Running, this might mean that there are not enough resources (vCPUs, memory, or other resources) for the tenant to be deployed. See the Tenant Details screen in the chassis partition webUI for more information about the specific tenant.

Upgrade Tenant to 16 Blade Configuration

This procedure outlines the steps to upgrade an existing 8-blade tenant to be 16-blade.

When you log in to the system, you are in user (operational) mode.

Show the tenants that are currently configured in a chassis partition.

show tenants

This example displays the operational data for a BIG-IP tenant spanning two blades.

hydra-1# show tenants
        tenants tenant hydra
         state unit-key-hash    iFwYAYMjWByFNtV+A4qWkc5CvrthWHSK61cxjFJ2CuTBYt0dwNyleZv22Z8yA3ZZMDYEKcR09zDw0V3QkJkc+Q==
         state type             BIG-IP
         state image            BIGIP-17.1.2.1-0.0.2.ALL-F5OS.tar.bundle
         state nodes            [ 17 18 19 20 21 22 23 24 ]
         state mgmt-ip          10.255.144.30
         state prefix-length    24
         state gateway          10.255.144.254
         state dag-ipv6-prefix-length 128
         state vlans            [ 3989 ]
         state cryptos          disabled
         state tenant-auth-support disabled
         state vcpu-cores-per-node 22
         state qat-vf-count     0
         state memory           90000
         state storage size 600
         state running-state    deployed
         state appliance-mode disabled
         state feature-flags stats-stream-capable true
         state status           Running
         state primary-slot     17
         state image-version    "BIG-IP 17.5.0 0.0.7"
         state tcp-cop disabled
         state mgmt-vlan        untagged
         state mgmt-vlan-accessible true
         state mac-data base-mac 00:94:a1:cf:90:19
         state mac-data mac-pool-size 1
 
        MAC               
        -------------------
        00:94:a1:cf:90:19 
 
        NODE  CPUS                                                        
        -------------------------------------------------------------------
        17    [ 10 24 2 16 3 17 21 7 23 9 6 20 15 1 19 5 4 18 14 0 22 8 ] 
        18    [ 22 8 4 18 5 19 14 0 16 2 20 6 24 10 3 17 1 15 9 23 21 7 ] 
        19    [ 18 4 23 9 8 22 17 3 15 1 24 10 21 7 0 14 5 19 6 20 16 2 ] 
        20    [ 0 14 1 15 17 3 21 7 5 19 10 24 16 2 23 9 6 20 4 18 22 8 ] 
        21    [ 15 1 20 6 21 7 0 14 17 3 2 16 8 22 18 4 19 5 23 9 10 24 ] 
        22    [ 1 15 24 10 23 9 5 19 0 14 16 2 21 7 8 22 4 18 6 20 17 3 ] 
        23    [ 16 2 24 10 15 1 17 3 18 4 22 8 23 9 7 21 0 14 5 19 20 6 ] 
        24    [ 18 4 2 16 22 8 23 9 5 19 1 15 0 14 10 24 17 3 20 6 7 21 ] 
 
                        INSTANCE  TENANT                                                                                                  
        NODE  POD NAME  ID        SLOT    PHASE    CREATION TIME         READY TIME            STATUS                   MGMT MAC          
        -----------------------------------------------------------------------------------------------------------------------------------
        17    hydra-17  17        1       Running  2025-02-13T16:29:53Z  2025-02-13T16:30:11Z  Started tenant instance  06:53:6f:66:63:22 
        18    hydra-18  18        2       Running  2025-02-13T16:29:54Z  2025-02-13T16:30:22Z  Started tenant instance  1a:25:5f:d2:ad:b6 
        19    hydra-19  19        3       Running  2025-02-13T16:29:56Z  2025-02-13T16:30:35Z  Started tenant instance  9a:c6:56:22:cf:76 
        20    hydra-20  20        4       Running  2025-02-13T16:29:58Z  2025-02-13T16:30:40Z  Started tenant instance  76:03:7a:ab:d5:d9 
        21    hydra-21  21        5       Running  2025-02-13T16:29:57Z  2025-02-13T16:30:27Z  Started tenant instance  1e:f7:09:b9:3d:de 
        22    hydra-22  22        6       Running  2025-02-13T16:30:23Z  2025-02-13T16:30:40Z  Started tenant instance  1a:92:0b:b1:2b:76 
        23    hydra-23  23        7       Running  2025-02-13T16:30:24Z  2025-02-13T16:31:09Z  Started tenant instance  22:7c:2f:f0:79:cb 
        24    hydra-24  24        8       Running  2025-02-13T16:30:26Z  2025-02-13T16:30:52Z  Started tenant instance  ca:21:b4:74:11:67

Exit from the chassis partition CLI.

exit

When you log in to the system, you are in user (operational) mode.

Change to config mode.

config

The CLI prompt changes to include

(config)

Upgrade the chassis controllers to F5OS-C 1.8.1 version.

system image set-version iso-version 1.8.1-23399 proceed yes

A summary of the example displays:

syscon-2-active(config)# system image set-version iso-version 1.8.1-23399 proceed yes

Upgrade the chassis partition to F5OS-C 1.8.1 version.

partitions partition hydra set-version iso-version 1.8.1-23399 proceed yes

A summary of the example displays:

syscon-2-active(config)# partitions partition hydra set-version iso-version 1.8.1-23399 proceed yes

Verify chassis controllers and partitions have been upgraded to the 1.8.1 build and are running.

syscon-2-active# show system image
                            SERVICE     ISO      INSTALL 
        NUMBER  OS VERSION  VERSION     VERSION  STATUS  
        --------------------------------------------------
        1       1.8.1-23399 1.9.0-23399  -        success 
        2       1.9.0-23399 1.9.0-23399  -        success

syscon-2-active# show partitions
                                                               RUNNING             
                         BLADE OS     SERVICE                  PARTITION        SERVICE      STATUS 
        NAME         ID  VERSION      VERSION      CONTROLLER  STATUS           VERSION      AGE    
        ---------------------------------------------------------------------------------------------
        none         -   -            -                                                             
        hydra        2   1.8.1-23399  1.8.1-23399  1           running-standby  1.8.1-23399  2h     
                                                   2           running-active   1.8.1-23399  2h

Exit from the chassis controller CLI.

exit

Log into the BIG-IP Advanced shell (bash) using a utility such as Putty or using the following command syntax on the Command Line Interface of your client system.

If you are at the (tmos) # prompt, type the command run /util bash.

ssh <username>@<IP address of the BIG-IP system

Upload BIG-IP iso image v17.5.0 or later that matches the bundle version you are planning to use into /share/images on the tenant for upgrade.

Enter the TMOS Shell (tmsh) by running the below command.

tmsh

Install the new image on a new disk partition within the tenant.

install sys software image BIGIP-17.5.0-0.0.7.iso volume HD1.2 create-volume

A summary of the example displays:

[root@localhost:/S1-green-P::Active:Standalone] images # tmsh install sys software image BIGIP-17.5.0-0.0.7.iso volume HD1.2 create-volume

Verify the installation is complete on all blades in the tenant.

show sys software

A summary of the example displays:

[root@localhost:/S1-green-P::Active:Standalone] images # tmsh show sys software
 
 
        -------------------------------------------------------------------------
        Sys::Software Status
        Volume  Slot  Product   Version  Build  Active    Status  Allowed Version
        -------------------------------------------------------------------------
        HD1.1      1   BIG-IP  17.1.2.1  0.0.2     yes  complete              yes
        HD1.1      2   BIG-IP  17.1.2.1  0.0.2     yes  complete              yes
        HD1.1      3   BIG-IP  17.1.2.1  0.0.2     yes  complete              yes
        HD1.1      4   BIG-IP  17.1.2.1  0.0.2     yes  complete              yes
        HD1.1      5   BIG-IP  17.1.2.1  0.0.2     yes  complete              yes
        HD1.1      6   BIG-IP  17.1.2.1  0.0.2     yes  complete              yes
        HD1.1      7   BIG-IP  17.1.2.1  0.0.2     yes  complete              yes
        HD1.1      8   BIG-IP  17.1.2.1  0.0.2     yes  complete              yes
        HD1.2      1   BIG-IP    17.5.0  0.0.7      no  complete              yes
        HD1.2      2   BIG-IP    17.5.0  0.0.7      no  complete              yes
        HD1.2      3   BIG-IP    17.5.0  0.0.7      no  complete              yes
        HD1.2      4   BIG-IP    17.5.0  0.0.7      no  complete              yes
        HD1.2      5   BIG-IP    17.5.0  0.0.7      no  complete              yes
        HD1.2      6   BIG-IP    17.5.0  0.0.7      no  complete              yes
        HD1.2      7   BIG-IP    17.5.0  0.0.7      no  complete              yes
        HD1.2      8   BIG-IP    17.5.0  0.0.7      no  complete              yes

Boot the tenant into the new disk partition.

switchboot -b HD1.2

A summary of the example displays:

[root@localhost:/S1-green-P::Active:Standalone] images # switchboot -b HD1.2

Wait for the tenant to boot and run into the new version.

show sys software

A summary of the example displays:

[root@localhost:/S1-green-P::Active:Standalone] images # tmsh show sys software
 
        -------------------------------------------------------------------------
        Sys::Software Status
        Volume  Slot  Product   Version  Build  Active    Status  Allowed Version
        -------------------------------------------------------------------------
        HD1.1      1   BIG-IP  17.1.2.1  0.0.2      no  complete              yes
        HD1.1      2   BIG-IP  17.1.2.1  0.0.2      no  complete              yes
        HD1.1      3   BIG-IP  17.1.2.1  0.0.2      no  complete              yes
        HD1.1      4   BIG-IP  17.1.2.1  0.0.2      no  complete              yes
        HD1.1      5   BIG-IP  17.1.2.1  0.0.2      no  complete              yes
        HD1.1      6   BIG-IP  17.1.2.1  0.0.2      no  complete              yes
        HD1.1      7   BIG-IP  17.1.2.1  0.0.2      no  complete              yes
        HD1.1      8   BIG-IP  17.1.2.1  0.0.2      no  complete              yes
        HD1.2      1   BIG-IP    17.5.0  0.0.7     yes  complete              yes
        HD1.2      2   BIG-IP    17.5.0  0.0.7     yes  complete              yes
        HD1.2      3   BIG-IP    17.5.0  0.0.7     yes  complete              yes
        HD1.2      4   BIG-IP    17.5.0  0.0.7     yes  complete              yes
        HD1.2      5   BIG-IP    17.5.0  0.0.7     yes  complete              yes
        HD1.2      6   BIG-IP    17.5.0  0.0.7     yes  complete              yes
        HD1.2      7   BIG-IP    17.5.0  0.0.7     yes  complete              yes
        HD1.2      8   BIG-IP    17.5.0  0.0.7     yes  complete              yes

Exit from the tenant.

exit

When you log in to the system, you are in user (operational) mode.

Show the tenants that are currently configured in a chassis partition.

show tenants

A summary of the example displays:

hydra-1# show tenants
        tenants tenant hydra
         state unit-key-hash    iFwYAYMjWByFNtV+A4qWkc5CvrthWHSK61cxjFJ2CuTBYt0dwNyleZv22Z8yA3ZZMDYEKcR09zDw0V3QkJkc+Q==
         state type             BIG-IP
         state image            BIGIP-17.1.2.1-0.0.2.ALL-F5OS.tar.bundle
         state nodes            [ 17 18 19 20 21 22 23 24 ]
         state mgmt-ip          10.255.144.30
         state prefix-length    24
         state gateway          10.255.144.254
         state dag-ipv6-prefix-length 128
         state vlans            [ 3989 ]
         state cryptos          disabled
         state tenant-auth-support disabled
         state vcpu-cores-per-node 22
         state qat-vf-count     0
         state memory           90000
         state storage size 600
         state running-state    deployed
         state appliance-mode disabled
         state feature-flags stats-stream-capable true
         state status           Running
         state primary-slot     17
         state image-version    "BIG-IP 17.5.0 0.0.7"
         state tcp-cop disabled
         state mgmt-vlan        untagged
         state mgmt-vlan-accessible true
         state mac-data base-mac 00:94:a1:cf:90:19
         state mac-data mac-pool-size 1
 
        MAC               
        -------------------
        00:94:a1:cf:90:19 
 
        NODE  CPUS                                                        
        -------------------------------------------------------------------
        17    [ 10 24 2 16 3 17 21 7 23 9 6 20 15 1 19 5 4 18 14 0 22 8 ] 
        18    [ 22 8 4 18 5 19 14 0 16 2 20 6 24 10 3 17 1 15 9 23 21 7 ] 
        19    [ 18 4 23 9 8 22 17 3 15 1 24 10 21 7 0 14 5 19 6 20 16 2 ] 
        20    [ 0 14 1 15 17 3 21 7 5 19 10 24 16 2 23 9 6 20 4 18 22 8 ] 
        21    [ 15 1 20 6 21 7 0 14 17 3 2 16 8 22 18 4 19 5 23 9 10 24 ] 
        22    [ 1 15 24 10 23 9 5 19 0 14 16 2 21 7 8 22 4 18 6 20 17 3 ] 
        23    [ 16 2 24 10 15 1 17 3 18 4 22 8 23 9 7 21 0 14 5 19 20 6 ] 
        24    [ 18 4 2 16 22 8 23 9 5 19 1 15 0 14 10 24 17 3 20 6 7 21 ] 
 
                        INSTANCE  TENANT                                                                                                  
        NODE  POD NAME  ID        SLOT    PHASE    CREATION TIME         READY TIME            STATUS                   MGMT MAC          
        -----------------------------------------------------------------------------------------------------------------------------------
        17    hydra-17  17        1       Running  2025-02-13T16:29:53Z  2025-02-13T16:30:11Z  Started tenant instance  06:53:6f:66:63:22 
        18    hydra-18  18        2       Running  2025-02-13T16:29:54Z  2025-02-13T16:30:22Z  Started tenant instance  1a:25:5f:d2:ad:b6 
        19    hydra-19  19        3       Running  2025-02-13T16:29:56Z  2025-02-13T16:30:35Z  Started tenant instance  9a:c6:56:22:cf:76 
        20    hydra-20  20        4       Running  2025-02-13T16:29:58Z  2025-02-13T16:30:40Z  Started tenant instance  76:03:7a:ab:d5:d9 
        21    hydra-21  21        5       Running  2025-02-13T16:29:57Z  2025-02-13T16:30:27Z  Started tenant instance  1e:f7:09:b9:3d:de 
        22    hydra-22  22        6       Running  2025-02-13T16:30:23Z  2025-02-13T16:30:40Z  Started tenant instance  1a:92:0b:b1:2b:76 
        23    hydra-23  23        7       Running  2025-02-13T16:30:24Z  2025-02-13T16:31:09Z  Started tenant instance  22:7c:2f:f0:79:cb 
        24    hydra-24  24        8       Running  2025-02-13T16:30:26Z  2025-02-13T16:30:52Z  Started tenant instance  ca:21:b4:74:11:67

Change to config mode.

config

The CLI prompt changes to include

(config)

Move the tenant into the configured state to stop the tenant instances.

tenants tenant <tenant name> config running-state configured

A summary of the example displays:

hydra-1(config)# tenants tenant hydra config running-state configured

Commit the configuration changes and exit from the tenant.

A summary of the example displays:

hydra-1(config-tenant-hydra)# commit
Commit complete.
hydra-1(config-tenant-hydra)# exit
hydra-1(config)#

Set the maximum number of nodes to 16 and update the configured tenant software bundle to match the upgraded version in the tenant.

tenants tenant <tenant name> config max-nodes 16 image < image name >

A summary of the example displays:

hydra-1(config)# tenants tenant hydra config max-nodes 16 image BIGIP-17.5.0-0.0.7.ALL-F5OS.tar.bundle

Commit the configuration changes.

commit

If the 16 blade support is enabled before upgrading the tenant to BIG-IP 17.5.0, it will result in failure and an error message will be displayed as shown below:

hydra-1(config)# tenants tenant hydra config max-nodes 16
hydra-1(config-tenant-hydra)# commit
Aborted: 'tenants tenant hydra config': Cannot set max-nodes to 16.
Configured bundle image version should be >= V17.5.0.
Incompatible running version 17.1.2.1. Upgrade internally to a version >= v17.5.0.
Running sw version and configured bundle image version should be >= v17.5.0 and match.

Verify the updated configuration.

show tenants

A summary of the example displays:

hydra-1(config)# do show tenants
        tenants tenant hydra
         state unit-key-hash    iFwYAYMjWByFNtV+A4qWkc5CvrthWHSK61cxjFJ2CuTBYt0dwNyleZv22Z8yA3ZZMDYEKcR09zDw0V3QkJkc+Q==
         state type             BIG-IP
         state image            BIGIP-17.5.0-0.0.7.ALL-F5OS.tar.bundle
         state nodes            [ 17 18 19 20 21 22 23 24 ]
         state max-nodes        16
         state mgmt-ip          10.255.144.30
         state prefix-length    24
         state gateway          10.255.144.254
         state dag-ipv6-prefix-length 128
         state vlans            [ 3989 ]
         state cryptos          disabled
         state tenant-auth-support disabled
         state vcpu-cores-per-node 22
         state qat-vf-count     0
         state memory           90000
         state storage size 600
         state running-state    configured
         state appliance-mode disabled
         state feature-flags stats-stream-capable false
         state status           Configured
         state image-version    "BIG-IP 17.5.0 0.0.7"
         state tcp-cop disabled
         state mgmt-vlan        untagged
         state mgmt-vlan-accessible true
         state mac-data base-mac 00:94:a1:cf:90:19
         state mac-data mac-pool-size 1
        MAC               
        -------------------
        00:94:a1:cf:90:19

Re-deploy the tenant with the new max-nodes configuration.

tenants tenant <tenant name> config running-state deployed

A summary of the example displays:

hydra-1(config)# tenants tenant hydra config running-state deployed

Commit the configuration changes.

commit

Exit from the chassis partition CLI.

exit

Log into the BIG-IP Advanced shell (bash) using a utility such as Putty or using the following command syntax on the Command Line Interface of your client system.

If you are at the (tmos) # prompt, type the command run /util bash.

ssh <username>@<IP address of the BIG-IP system

Enter the TMOS Shell (tmsh) by running the below command.

tmsh

Verify that the tenant appears and displays a maximum of 16 slots.

show sys cluster

A summary of the example displays:

[root@localhost:/S1-green-P::Active:Standalone] config # tmsh show sys cluster
 
        -----------------------------------------
        Sys::Cluster: default
        -----------------------------------------
        Address                 10.255.144.30/24
        Alt-Address             ::
        Availability            available
        State                   enabled
        Reason                  Cluster Enabled
        Primary Slot ID         1
        Primary Selection Time  02/13/25 09:13:15
 
          ---------------------------------------------------------------------------------------------------------
          | Sys::Cluster Members
          | ID  Address  Alt-Address  Availability  State    Licensed  HA       Clusterd  Reason
          ---------------------------------------------------------------------------------------------------------
          | 1   ::       ::           available     enabled  true      active   running   Run
          | 2   ::       ::           available     enabled  true      active   running   Run
          | 3   ::       ::           available     enabled  true      active   running   Run
          | 4   ::       ::           available     enabled  true      active   running   Run
          | 5   ::       ::           available     enabled  true      active   running   Run
          | 6   ::       ::           available     enabled  true      active   running   Run
          | 7   ::       ::           available     enabled  true      active   running   Run
          | 8   ::       ::           available     enabled  true      active   running   Run
          | 9   ::       ::           unknown       enabled  false     unknown  shutdown  Slot powered off or empty
          | 10  ::       ::           unknown       enabled  false     unknown  shutdown  Slot powered off or empty
          | 11  ::       ::           unknown       enabled  false     unknown  shutdown  Slot powered off or empty
          | 12  ::       ::           unknown       enabled  false     unknown  shutdown  Slot powered off or empty
          | 13  ::       ::           unknown       enabled  false     unknown  shutdown  Slot powered off or empty
          | 14  ::       ::           unknown       enabled  false     unknown  shutdown  Slot powered off or empty
          | 15  ::       ::           unknown       enabled  false     unknown  shutdown  Slot powered off or empty
          | 16  ::       ::           unknown       enabled  false     unknown  shutdown  Slot powered off or empty

New slots have not been added to the tenant yet.

Exit from the tenant.

exit

When you log in to the system, you are in user (operational) mode.

Change to config mode.

config

The CLI prompt changes to include

(config)

Add new slots to the tenant.

tenants tenant hydra config nodes [ 17 18 19 20 21 22 23 24 25 26 27 28 ]

In the above command, slots 25, 26, 27, and 28 are being added to the existing eight slots in the tenant. A summary of the example displays:

hydra-1(config)# tenants tenant hydra config nodes [ 17 18 19 20 21 22 23 24 25 26 27 28 ]

Commit the configuration changes.

commit

Wait for new tenant instances to come up and verify.

show tenants

In the above command, slots 25, 26, 27, and 28 are being added to the existing eight slots in the tenant. A summary of the example displays:

hydra-1# show tenants
        tenants tenant hydra
         state unit-key-hash    iFwYAYMjWByFNtV+A4qWkc5CvrthWHSK61cxjFJ2CuTBYt0dwNyleZv22Z8yA3ZZMDYEKcR09zDw0V3QkJkc+Q==
         state type             BIG-IP
         state image            BIGIP-17.5.0-0.0.7.ALL-F5OS.tar.bundle
         state nodes            [ 17 18 19 20 21 22 23 24 25 26 27 28 ]
         state max-nodes        16
         state mgmt-ip          10.255.144.30
         state prefix-length    24
         state gateway          10.255.144.254
         state dag-ipv6-prefix-length 128
         state vlans            [ 3989 ]
         state cryptos          disabled
         state tenant-auth-support disabled
         state vcpu-cores-per-node 22
         state qat-vf-count     0
         state memory           90000
         state storage size 600
         state running-state    deployed
         state appliance-mode disabled
         state feature-flags stats-stream-capable true
         state status           Running
         state primary-slot     17
         state image-version    "BIG-IP 17.5.0 0.0.7"
         state tcp-cop disabled
         state mgmt-vlan        untagged
         state mgmt-vlan-accessible true
         state mac-data base-mac 00:94:a1:cf:90:19
         state mac-data mac-pool-size 1
        MAC               
        -------------------
        00:94:a1:cf:90:19 
         
        NODE  CPUS                                                        
        -------------------------------------------------------------------
        17    [ 10 24 2 16 3 17 21 7 23 9 6 20 15 1 19 5 4 18 14 0 22 8 ] 
        18    [ 22 8 4 18 5 19 14 0 16 2 20 6 24 10 3 17 1 15 9 23 21 7 ] 
        19    [ 18 4 23 9 8 22 17 3 15 1 24 10 21 7 0 14 5 19 6 20 16 2 ] 
        20    [ 0 14 1 15 17 3 21 7 5 19 10 24 16 2 23 9 6 20 4 18 22 8 ] 
        21    [ 15 1 20 6 21 7 0 14 17 3 2 16 8 22 18 4 19 5 23 9 10 24 ] 
        22    [ 1 15 24 10 23 9 5 19 0 14 16 2 21 7 8 22 4 18 6 20 17 3 ] 
        23    [ 16 2 24 10 15 1 17 3 18 4 22 8 23 9 7 21 0 14 5 19 20 6 ] 
        24    [ 18 4 2 16 22 8 23 9 5 19 1 15 0 14 10 24 17 3 20 6 7 21 ] 
        25    [ 23 9 3 17 7 21 0 14 16 2 22 8 18 4 19 5 10 24 15 1 20 6 ] 
        26    [ 16 2 1 15 23 9 3 17 19 5 8 22 0 14 21 7 4 18 20 6 10 24 ] 
        27    [ 7 21 9 23 18 4 2 16 3 17 20 6 24 10 19 5 1 15 14 0 8 22 ] 
        28    [ 1 15 19 5 8 22 10 24 14 0 21 7 9 23 16 2 6 20 17 3 18 4 ] 
 
                        INSTANCE  TENANT                                                                                                  
        NODE  POD NAME  ID        SLOT    PHASE    CREATION TIME         READY TIME            STATUS                   MGMT MAC          
        -----------------------------------------------------------------------------------------------------------------------------------
        17    hydra-17  17        1       Running  2025-02-13T17:10:52Z  2025-02-13T17:11:17Z  Started tenant instance  da:5a:3d:7b:dd:5f 
        18    hydra-18  18        2       Running  2025-02-13T17:10:50Z  2025-02-13T17:11:12Z  Started tenant instance  8a:c5:2b:3b:e3:40 
        19    hydra-19  19        3       Running  2025-02-13T17:10:53Z  2025-02-13T17:11:39Z  Started tenant instance  4e:78:d6:15:51:91 
        20    hydra-20  20        4       Running  2025-02-13T17:10:50Z  2025-02-13T17:11:23Z  Started tenant instance  ae:18:02:82:8d:78 
        21    hydra-21  21        5       Running  2025-02-13T17:10:54Z  2025-02-13T17:11:29Z  Started tenant instance  da:25:c9:c6:52:a9 
        22    hydra-22  22        6       Running  2025-02-13T17:11:20Z  2025-02-13T17:11:36Z  Started tenant instance  da:1b:c2:82:ad:ac 
        23    hydra-23  23        7       Running  2025-02-13T17:11:21Z  2025-02-13T17:11:48Z  Started tenant instance  86:e2:08:a0:b1:7f 
        24    hydra-24  24        8       Running  2025-02-13T17:11:22Z  2025-02-13T17:12:08Z  Started tenant instance  66:03:e2:06:4d:63 
        25    hydra-25  25        9       Running  2025-02-13T17:19:23Z  2025-02-13T17:19:46Z  Started tenant instance  5e:da:f1:37:00:de 
        26    hydra-26  26        10      Running  2025-02-13T17:19:23Z  2025-02-13T17:19:43Z  Started tenant instance  02:34:59:9a:7b:02 
        27    hydra-27  27        11      Running  2025-02-13T17:19:26Z  2025-02-13T17:20:01Z  Started tenant instance  fa:33:09:13:e7:38 
        28    hydra-28  28        12      Running  2025-02-13T17:19:28Z  2025-02-13T17:19:53Z  Started tenant instance  f2:84:d6:7f:4d:6b

Exit from the chassis partition CLI.

exit

Log into the BIG-IP Advanced shell (bash) using a utility such as Putty or using the following command syntax on the Command Line Interface of your client system.

If you are at the (tmos) # prompt, type the command run /util bash.

ssh <username>@<IP address of the BIG-IP system

Enter the TMOS Shell (tmsh) by running the below command.

tmsh

Monitor the ‌BIG-IP 17.5.0 image replication.

show sys soft

A summary of the example displays:

[root@localhost:/S1-green-P::Active:Standalone] config # watch tmsh show sys soft
 
        ----------------------------------------------------------------------------------------------------------
        Sys::Software Status
        Volume  Slot  Product   Version  Build  Active                                     Status  Allowed Version
        ----------------------------------------------------------------------------------------------------------
        HD1.1      1   BIG-IP  17.1.2.1  0.0.2      no                                   complete              yes
        HD1.1     10   BIG-IP    17.5.0  0.0.7     yes                             upgrade needed              yes
        HD1.1     11   BIG-IP    17.5.0  0.0.7     yes                             upgrade needed              yes
        HD1.1     12   BIG-IP    17.5.0  0.0.7     yes                             upgrade needed              yes
        HD1.1      2   BIG-IP  17.1.2.1  0.0.2      no                                   complete              yes
        HD1.1      3   BIG-IP  17.1.2.1  0.0.2      no                                   complete              yes
        HD1.1      4   BIG-IP  17.1.2.1  0.0.2      no                                   complete              yes
        HD1.1      5   BIG-IP  17.1.2.1  0.0.2      no                                   complete              yes
        HD1.1      6   BIG-IP  17.1.2.1  0.0.2      no                                   complete              yes
        HD1.1      7   BIG-IP  17.1.2.1  0.0.2      no                                   complete              yes
        HD1.1      8   BIG-IP  17.1.2.1  0.0.2      no                                   complete              yes
        HD1.1      9   BIG-IP    17.5.0  0.0.7     yes                             upgrade needed              yes
        HD1.2      1   BIG-IP    17.5.0  0.0.7     yes                                   complete              yes
        HD1.2     10     none      none   none      no  waiting for product image (BIG-IP 17.5.0)              yes
        HD1.2     11     none      none   none      no  waiting for product image (BIG-IP 17.5.0)              yes
        HD1.2     12     none      none   none      no  waiting for product image (BIG-IP 17.5.0)              yes
        HD1.2      2   BIG-IP    17.5.0  0.0.7     yes                                   complete              yes
        HD1.2      3   BIG-IP    17.5.0  0.0.7     yes                                   complete              yes
        HD1.2      4   BIG-IP    17.5.0  0.0.7     yes                                   complete              yes
        HD1.2      5   BIG-IP    17.5.0  0.0.7     yes                                   complete              yes
        HD1.2      6   BIG-IP    17.5.0  0.0.7     yes                                   complete              yes
        HD1.2      7   BIG-IP    17.5.0  0.0.7     yes                                   complete              yes
        HD1.2      8   BIG-IP    17.5.0  0.0.7     yes                                   complete              yes
        HD1.2      9     none      none   none      no  waiting for product image (BIG-IP 17.5.0)              yes

Wait for the installation of BIG-IP 17.5.0 image into HD1.2 on the new slots.

show sys cluster

A summary of the example displays:

[root@localhost:/S1-green-P::Active:Standalone] config # tmsh show sys cluster
        --------------------------------------------------------------------------------------
        Sys::Software Status
        Volume  Slot  Product   Version  Build  Active                 Status  Allowed Version
        --------------------------------------------------------------------------------------
        HD1.1      1   BIG-IP  17.1.2.1  0.0.2      no               complete              yes
        HD1.1     10   BIG-IP    17.5.0  0.0.7     yes         upgrade needed              yes
        HD1.1     11   BIG-IP    17.5.0  0.0.7     yes         upgrade needed              yes
        HD1.1     12   BIG-IP    17.5.0  0.0.7     yes         upgrade needed              yes
        HD1.1      2   BIG-IP  17.1.2.1  0.0.2      no               complete              yes
        HD1.1      3   BIG-IP  17.1.2.1  0.0.2      no               complete              yes
        HD1.1      4   BIG-IP  17.1.2.1  0.0.2      no               complete              yes
        HD1.1      5   BIG-IP  17.1.2.1  0.0.2      no               complete              yes
        HD1.1      6   BIG-IP  17.1.2.1  0.0.2      no               complete              yes
        HD1.1      7   BIG-IP  17.1.2.1  0.0.2      no               complete              yes
        HD1.1      8   BIG-IP  17.1.2.1  0.0.2      no               complete              yes
        HD1.1      9   BIG-IP    17.5.0  0.0.7     yes         upgrade needed              yes
        HD1.2      1   BIG-IP    17.5.0  0.0.7     yes               complete              yes
        HD1.2     10   BIG-IP    17.5.0  0.0.7      no  installing 10.000 pct              yes
        HD1.2     11   BIG-IP    17.5.0  0.0.7      no  installing 10.000 pct              yes
        HD1.2     12   BIG-IP    17.5.0  0.0.7      no  installing 10.000 pct              yes
        HD1.2      2   BIG-IP    17.5.0  0.0.7     yes               complete              yes
        HD1.2      3   BIG-IP    17.5.0  0.0.7     yes               complete              yes
        HD1.2      4   BIG-IP    17.5.0  0.0.7     yes               complete              yes
        HD1.2      5   BIG-IP    17.5.0  0.0.7     yes               complete              yes
        HD1.2      6   BIG-IP    17.5.0  0.0.7     yes               complete              yes
        HD1.2      7   BIG-IP    17.5.0  0.0.7     yes               complete              yes
        HD1.2      8   BIG-IP    17.5.0  0.0.7     yes               complete              yes
        HD1.2      9   BIG-IP    17.5.0  0.0.7      no  installing 10.000 pct              yes

[root@localhost:/S1-green-P::Active:Standalone] config # tmsh show sys cluster
        --------------------------------------------------------------------------------------
        Sys::Software Status
        Volume  Slot  Product   Version  Build  Active                 Status  Allowed Version
        --------------------------------------------------------------------------------------
        HD1.1      1   BIG-IP  17.1.2.1  0.0.2      no               complete              yes
        HD1.1     10   BIG-IP    17.5.0  0.0.7      no         upgrade needed              yes
        HD1.1     11   BIG-IP    17.5.0  0.0.7      no         upgrade needed              yes
        HD1.1     12   BIG-IP    17.5.0  0.0.7      no         upgrade needed              yes
        HD1.1      2   BIG-IP  17.1.2.1  0.0.2      no               complete              yes
        HD1.1      3   BIG-IP  17.1.2.1  0.0.2      no               complete              yes
        HD1.1      4   BIG-IP  17.1.2.1  0.0.2      no               complete              yes
        HD1.1      5   BIG-IP  17.1.2.1  0.0.2      no               complete              yes
        HD1.1      6   BIG-IP  17.1.2.1  0.0.2      no               complete              yes
        HD1.1      7   BIG-IP  17.1.2.1  0.0.2      no               complete              yes
        HD1.1      8   BIG-IP  17.1.2.1  0.0.2      no               complete              yes
        HD1.1      9   BIG-IP    17.5.0  0.0.7     yes         upgrade needed              yes
        HD1.2      1   BIG-IP    17.5.0  0.0.7     yes               complete              yes
        HD1.2     10   BIG-IP    17.5.0  0.0.7     yes               complete              yes
        HD1.2     11   BIG-IP    17.5.0  0.0.7     yes               complete              yes
        HD1.2     12   BIG-IP    17.5.0  0.0.7     yes               complete              yes
        HD1.2      2   BIG-IP    17.5.0  0.0.7     yes               complete              yes
        HD1.2      3   BIG-IP    17.5.0  0.0.7     yes               complete              yes
        HD1.2      4   BIG-IP    17.5.0  0.0.7     yes               complete              yes
        HD1.2      5   BIG-IP    17.5.0  0.0.7     yes               complete              yes
        HD1.2      6   BIG-IP    17.5.0  0.0.7     yes               complete              yes
        HD1.2      7   BIG-IP    17.5.0  0.0.7     yes               complete              yes
        HD1.2      8   BIG-IP    17.5.0  0.0.7     yes               complete              yes
        HD1.2      9   BIG-IP    17.5.0  0.0.7     yes               complete              yes

Wait for the new slots to join the cluster.

show sys cluster

A summary of the example displays:

[root@localhost:/S1-green-P::Active:Standalone] config # show sys cluster
         
        -----------------------------------------
        Sys::Cluster: default
        -----------------------------------------
        Address                 10.255.144.30/24
        Alt-Address             ::
        Availability            available
        State                   enabled
        Reason                  Cluster Enabled
        Primary Slot ID         1
        Primary Selection Time  02/13/25 09:13:15
 
          ---------------------------------------------------------------------------------------------------------
          | Sys::Cluster Members
          | ID  Address  Alt-Address  Availability  State    Licensed  HA       Clusterd  Reason
          ---------------------------------------------------------------------------------------------------------
          | 1   ::       ::           available     enabled  true      active   running   Run
          | 2   ::       ::           available     enabled  true      active   running   Run
          | 3   ::       ::           available     enabled  true      active   running   Run
          | 4   ::       ::           available     enabled  true      active   running   Run
          | 5   ::       ::           available     enabled  true      active   running   Run
          | 6   ::       ::           available     enabled  true      active   running   Run
          | 7   ::       ::           available     enabled  true      active   running   Run
          | 8   ::       ::           available     enabled  true      active   running   Run
          | 9   ::       ::           available     enabled  true      active   running   Run
          | 10  ::       ::           available     enabled  true      active   running   Run
          | 11  ::       ::           available     enabled  true      active   running   Run
          | 12  ::       ::           available     enabled  true      active   running   Run
          | 13  ::       ::           unknown       enabled  false     unknown  shutdown  Slot powered off or empty
          | 14  ::       ::           unknown       enabled  false     unknown  shutdown  Slot powered off or empty
          | 15  ::       ::           unknown       enabled  false     unknown  shutdown  Slot powered off or empty
          | 16  ::       ::           unknown       enabled  false     unknown  shutdown  Slot powered off or empty

Configure DAG IPv6 prefix length from the CLI

You can configure the DAG IPv6 prefix length from the chassis partition CLI. DAG IPv6 prefix length is a configuration field on each tenant that is used by disaggregator algorithms as a networking mask. The valid configuration value is from 1 to 128. The default value is 128. You can configure the value from either the chassis partition or the tenant.

When you configure the value at the chassis partition level, it is pushed automatically to the tenant. When you configure the prefix length at the tenant level, future configuration at the chassis partition level is disabled and must be re-enabled from the tenant.

When you log in to the system, you are in user (operational) mode.

Change to config mode.

config

The CLI prompt changes to include

(config)

Configure DAG IPv6 prefix length while creating a tenant.

This propagates the value to the tenant. For more information, see Create and deploy tenants from the CLI.

Configure DAG IPv6 prefix length from the system after the tenant is created.

This propagates the value to the tenant.

tenants tenant <tenant-name> config dag-ipv6-prefix-length <value>

This example changes the DAG IPv6 prefix length of a tenant named "velos-bigip" to 120.

default-1(config)# tenants tenant velos-bigip config dag-ipv6-prefix-length 120

Commit the configuration changes.

commit

If you configure the DAG IPv6 prefix length, but the value is not propagated to the tenant, you might have previously configured this value externally (such as from the tenant's webUI, CLI, or REST APIs). This disables configuration at the chassis partition level. On a BIG-IP tenant, run this command sequence to re-enable configuration:

tmsh mod sys db dag.userconfigipv6prefixlen value false

Display tenant information from the CLI

You can display detailed information about tenants configured in a chassis partition from the chassis partition CLI.

When you log in to the system, you are in user (operational) mode.

Show the tenants that are currently configured in a chassis partition.

show tenants

This example displays the operational data for a

BIG-IP

tenant spanning two blades. It uses one VLAN, no cryptos, two vCPU cores, and appliance mode is not enabled. The Instance table in the output displays the live health of the tenant running on the

VELOS

system.

default-1# show tenants tenant bigip
tenants tenant bigip
 state unit-key-hash oa9gv8VYHcSoApv1234GQMn2uM9UzNKiDz78cIbqKv26LVjlIo9TCdp56z5UnXcVvr3hj0/ym2kbdWyBhPbkLA==
 state type          BIG-IP
 state image         BIGIP-bigip15.1.x-europa-15.1.5-0.0.222.ALL-F5OS.qcow2.zip.bundle
 state nodes         [ 1 ]
 state mgmt-ip       192.0.2.59
 state prefix-length 24
 state gateway       192.0.2.254
 state cryptos       enabled
 state vcpu-cores-per-node 2
 state memory        7680
 state storage size 76
 state running-state deployed
 state mac-data base-mac 00:94:a1:8e:70:0a
 state mac-data mac-pool-size 1
 state appliance-mode disabled
 state status        Running
 state primary-slot  1
 state image-version "BIG-IP 15.1.5 0.0.222"
 state instances instance 1
  instance-id   1
  phase         Running
  image-name    BIGIP-bigip15.1.x-europa-15.1.5-0.0.222.ALL-F5OS.qcow2.zip.bundle
  creation-time 2021-12-01T19:56:49Z
  ready-time    2021-12-01T19:56:35Z
  status        "Started tenant instance"
  mgmt-mac      f2:48:a7:f1:aa:ab

Show the running configuration of the tenants.

show running-config tenants tenant

A summary similar to this example displays:

default-1# show running-config tenants tenant
tenants tenant bigip
 config type         BIG-IP
 config image        BIGIP-bigip15.1.x-europa-15.1.5-0.0.222.ALL-F5OS.qcow2.zip.bundle
 config nodes        [ 1 2 ]
 config mgmt-ip      192.0.2.59
 config prefix-length 24
 config gateway      192.0.2.254
 config cryptos      enabled
 config vcpu-cores-per-node 2
 config memory       7680
 config storage size 76
 config running-state deployed
 config appliance-mode disabled

Display tenant status and statistics from the CLI

You can monitor data and metrics related to the usage, performance, and behavior of a tenant from the CLI. These statistics, tenant CPU usage, memory usage, and disk usage, are crucial for monitoring, managing, and optimizing the tenant.

When you log in to the system, you are in user (operational) mode.

Change to config mode.

config

The CLI prompt changes to include

(config)

Show ‌tenants status and statistics.

tenants tenant <tenant name> state <action>

This example displays the tenant status and statistics for a BIG-IP tenant running on the system.

You can get the stats with an average of 10 seconds, 30 seconds, 1 minute, 5 minutes, and 10 minutes.

For CPU stats:

default-1(config)# tenants tenant cbip state cpu-thread-stats average 1m-avg         
averages {
        unix-seconds 1717588320
        cpu-threads {
            cpu-thread {
                thread-index 0
                busy-percent 1
            }
            cpu-thread {
                thread-index 1
                busy-percent 0
            }
            cpu-thread {
                thread-index 2
                busy-percent 0
            }
            cpu-thread {
                thread-index 3
                busy-percent 4
            }
            cpu-thread {
                thread-index 4
                busy-percent 4
            }
            cpu-thread {
                thread-index 5
                busy-percent 4
            }
            cpu-thread {
                thread-index 6
                busy-percent 4
            }
            cpu-thread {
                thread-index 7
                busy-percent 12
            }
            cpu-thread {
                thread-index 8
                busy-percent 4
            }
            cpu-thread {
                thread-index 9
                busy-percent 1
            }
            cpu-thread {
                thread-index 10
                busy-percent 4
            }
            cpu-thread {
                thread-index 11
                busy-percent 4
            }
            cpu-thread {
                thread-index 12
                busy-percent 4
            }
default-1(config)#

For disk stats:

default-1(config)# tenants tenant cbip state disk-stats average 1m-avg
averages {
        unix-seconds 1717588260
        used-percent 88
        disk-list {
            disk {
                disk-name nvme0n1
                total-iops 0
                read-iops 0
                read-bytes 148
                write-iops 154
                write-bytes 1691163
            }
        }
    }
default-1(config)#

For interface stats:

default-1(config)# tenants tenant cbip state interface-stats average 1m-avg
averages {
        unix-seconds 1717588380
        interface-list {
            interface {
                interface-name 1.0
                ifc-bytes-in 1466
                ifc-bytes-out 0
                ifc-packets-in 0
                ifc-packets-out 0
            }
            interface {
                interface-name 2.0
                ifc-bytes-in 135
                ifc-bytes-out 0
                ifc-packets-in 0
                ifc-packets-out 0
            }
        }
    }
default-1(config)#

For memory stats:

default-1(config)# tenants tenant cbip state memory-stats average 1m-avg
averages {
        unix-seconds 1717588440
        available 8493508881
        free 1060426615
        used-percent 93
        platform-total 16107667456
        platform-used 8114811835
    }
default-1(config)#

Modify tenant configuration from the CLI

You can modify a tenant configured in a chassis partition from the chassis partition CLI.

The administrator is able to modify only these fields while the tenant is running:

running-state

vlans

nodes

When you log in to the system, you are in user (operational) mode.

Show configuration information for the tenant you want to update.

show tenants tenant <name>

Change to config mode.

config

The CLI prompt changes to include

(config)

You can modify these options while the tenant is running:

vlans

nodes

, or

running-state

tenants tenant <name> config {

vlans

<vlan-id> |

nodes

{

} |

running-state

{

configured

provisioned

deployed

} ]

To modify any of the other options, first change the running state of the tenant to

provisioned

tenants tenant <name> config running-state provisioned

Make desired changes. For more information, see the

Tenant CLI command syntax

section.

Commit the configuration changes.

commit

Resize tenant virtual disk from the CLI

You can resize the storage quota for a tenant virtual disk from the chassis partition CLI.

When you log in to the system, you are in user (operational) mode.

Display configuration information for the tenant you want to update.

show tenants tenant <name>

Change to config mode.

config

The CLI prompt changes to include

(config)

Change the storage quota, in GB, for the virtual disk for a specified tenant.

The default size is 77 GB.

tenants tenant bigip-vm config storage size 80

You cannot modify the size of the virtual disk when the tenant is in the deployed running-state. The storage size can be modified only when the tenant is in a configured or provisioned running state.

Commit the configuration changes.

commit

Transmission Control Protocol-Connection Overload Protection (TCP-COP) Overview

In certain scenarios, the tenant can get overwhelmed by the number of new TCP connections requests. To address this, TCP-COP is designed to protect the tenant from this overload and helps reduce the high CPU use in the TMM process caused by the high concurrent flows. By enabling TCP-COP, you can drop new connections from being established at the platform level when the queue size exceeds a configured threshold, thus maintaining stable TMM CPU usage.

When the number of concurrent flows increases, the TMM experiences a rise in CPU consumption as a result of flow table expansion. This can lead to transaction failures to the inability of the TMM to handle the packets due to high look up times caused by the huge connection flow table entries. By enabling this feature, you can effectively manage the situation by preventing new connections from being established at the platform level, thereby maintaining stable TMM CPU usage. This approach allows for a boost in overall performance, as only new connections are affected, and any dropped connections can be successfully reattempted in subsequent efforts. As a result, this implementation leads to improved performance and consistent CPU utilization.

This functionality is enabled at the tenant level. Once enabled, a specific threshold must be set, determining the point at which the platform will cease accepting new connections (SYN packets). This allows the TMM to prioritize the handling of existing connections

Configuring TCP-COP from the CLI

You can configure TCP-COP from chassis partition from the CLI.

Connect using SSH to the chassis partition management IP address.

When you log in to the system, you are in user (operational) mode.

Change to config mode.

config

The CLI prompt changes to include

(config)

Enable TCP-COP and provide the threshold value.

tenants tenant <tenant-name> config tcp-cop [ disabled | enabled ] threshold <threshold value>

This example shows enabling TCP-COP and applying the threshold:

default-1(config)# tenants tenant cbip config tcp-cop enabled threshold 10.5

You must set the threshold value if ‌TCP-COP is enabled.

Commit the configuration changes.

commit

Return to user (operation) mode.

end

Verify the TCP-COP configuration.

A summary of the example displays:

default-1# show tenants tenant
tenants tenant cbip1
 state unit-key-hash    bItHjJgS6U90HGRq2Tj64fYJB4cvbcntoqetgRcWbwLdtKWEJerORYatSEP2Ah/W3B7JvdE2O1FLIR3lbw+qvg==
 state type             BIG-IP
 state image            BIGIP-17.1.1.3-0.0.5.ALL-F5OS.qcow2.zip.bundle
 state nodes            [ 1 ]
 state mgmt-ip          10.0.11.53
 state prefix-length    24
 state gateway          10.0.11.1
 state dag-ipv6-prefix-length 128
 state vlans            [ 11 ]
 state cryptos          enabled
 state tenant-auth-support disabled
 state vcpu-cores-per-node 4
 state qat-vf-count     6
 state memory           14848
 state storage size 82
 state running-state    deployed
 state appliance-mode disabled
 state feature-flags stats-stream-capable true
 state status           Running
 state primary-slot     1
 state image-version    "BIG-IP 17.1.1.3 0.0.5"
 state tcp-cop enabled
 state tcp-cop threshold 10.5
 state mgmt-vlan        11
 state mgmt-vlan-accessible true
 state mac-data base-mac 00:94:a1:8e:b8:0a
 state mac-data mac-pool-size 1
MAC              
-------------------
00:94:a1:8e:b8:0a
 
NODE  CPUS         
---------------------
1     [ 21 7 22 8 ]
 
 state instances instance 1 cbip1-1
  instance-id   1
  tenant-slot   1
  phase         Running
  creation-time 2024-09-12T11:38:16Z
  ready-time    2024-09-12T11:38:59Z
  status        "Started tenant instance"
  mgmt-mac      6e:32:c2:23:b8:86

Verify if the TCP-COP is applied when the tenant is running.

A summary of the example displays:

default-1# show tenants tenant tcp-cop tcp-cop
                            TOTAL  TOTAL  
       OPERATING OPERATING  RX     RX SYN  
NAME   STATUS    THRESHOLD  SYN    DROPPED
---------------------------------------------
cbip7  enabled   61.9       4      0      
cbip8  enabled   50.6       4      0

Delete a tenant from the CLI

You can delete tenant configurations in a chassis partition from the chassis partition CLI. It is recommended that you wait 5-10 minutes after deleting a tenant before deploying another tenant.

When you log in to the system, you are in user (operational) mode.

Show the tenants that are currently configured in that chassis partition to check the names of the tenants.

show tenants

Change to config mode.

config

The CLI prompt changes to include

(config)

Remove a tenant configuration from the chassis partition.

no tenants tenant <tenant-name>

Commit the configuration changes.

commit

The tenant deployment is removed from the chassis partition.

Tenant CLI command syntax

Use the

tenants

command from the chassis partition CLI to configure tenants on a chassis partition.

The

tenant

command includes this syntax and these options:

tenants tenant <options>

Option	Value	Description
appliance-mode	enabled or disabled (default)	When enabled, appliance-mode disallows root and Bash access for the tenant.
dag-ipv6-prefix-length	Decimal value	Tenant default value of IPv6 networking mask used by disaggregator algorithms.
cryptos	enabled or disabled (default)	Specifies the crypto device support for the tenant. When enabled, the tenant receives dedicated crypto devices proportional to the number of vCPU cores. When disabled, the tenant receives no crypto device support.
gateway	IP address	Specifies the IPv4 IPv6 address of the default gateway for the management network. This IP address can be changed on the tenant itself. This field is required.
image	Image name for the tenant	Specifies which software image to install on newly created virtual disks for this tenant. This field is required.
mac-data	Available options are: one - Represents a block with one MAC. small - Represents a contiguous block of 8 MACs. medium - Represents a contiguous block of 16 MACs. large - Represents a contiguous block of 32 MACs.	Specifies configuration data for MAC block size per tenant.
memory	Number in MB; 3840 MB is the minimum required per vCPU core or min-memory = (3.5 * 1024 * vcpu-cores-per-node) + 512	Specifies the memory in MBs for the tenant. For the commit to succeed, tenant configuration requires the minimum MBs required depending on the number of cores specified for the tenant. For example, for 2 vCPU cores, the minimum amount of memory is 7680 MB. The administrator must decide the amount of dedicated memory needed to satisfy the requirements of the BIG-IP or BIG-IP Next modules that will be provisioned within the tenant. The maximum amount of memory available per blade is 102400 MB.
mgmt-ip	IP address	Specifies the management IP address to the tenant. This address floats to the primary node of the tenant. The address can be changed on the tenant. This field is required.
nodes	Node numbers in square brackets separated by a space. For example, [1 2]	Lists the nodes that the tenant can be assigned to. This field is required. Specifies the nodes on the chassis partition on which to provision the tenant. Though you can specify nodes that are not part of the chassis partition, the tenant will not be provisioned until the resources are included in the chassis partition.
prefix-length	Decimal value	Specifies the prefix length of the management network. This field is required.
running-state	Configured (default), provisioned, or deployed	Specifies the state of a tenant: configured, provisioned, or deployed. Tenants are put in the configured state by default. Configured means the tenant exists on partition, but the tenant has no hardware resources (CPU or memory) allocated to it and it is not running. When the tenant is provisioned, the system assigns the tenant to nodes and creates virtual disks for the tenant on those nodes. In the deployed state, allocated resources are used to launch the tenant VM. Note that, specifying deployed causes the actions that occur in the configured and provisioned states. To shut down the tenant VM without removing the virtual disk, change the running state from deployed to provisioned. Changing the tenant running-state to configured from provisioned or deployed causes its virtual disk to be deleted.
storage	Storage quota in GB for the tenant	Specifies how much storage quota a tenant is allocated. The default size is 77 GB. You cannot modify the size of the virtual disk when the tenant is in the deployed running-state. You can modify the storage size when the tenant is in configured or provisioned running-states. For information on determining minimum disk size, see Tenant sizing.
type	BIG-IP (default), BIG-IP Next , or other supported tenant type	Specifies the supported tenants on the VELOS system.
vcpu-cores-per-node	Decimal number	Specifies how many cores a tenant is allocated from each node that it is assigned to. Use tab completion to see a list of possible values on the current VELOS system. The default value is 2
virtual-wires	Virtual wire name	User-specified virtual-wires from virtual-wire table for the tenant.
vlans	VLAN ID	Specifies the VLAN ID to be used for tenant traffic. To process the traffic through the tenant, make sure the VLAN is configured on the chassis partition.

Tenant console overview

VELOS chassis partitions include a tenant console user that provides console access to tenants from the chassis partition's management IP address.

Unlock the tenant console user from the CLI

The system creates the tenant console user account by default when you create a tenant, but the account is expired and has no password. Before you can access the tenant console, you must first unlock the tenant console user from the CLI.

When you log in to the system, you are in user (operational) mode.

Show information about configured users.

show system aaa authentication users

A summary similar to this example displays:

default-1# show system aaa authentication users
             LAST    TALLY  EXPIRY
USERNAME     CHANGE  COUNT  DATE    ROLE
----------------------------------------------------
admin        19370   0      -1      admin
big-ip       0       0      1       tenant-console
root         0       0      -1      root

The expiration date for the tenant console user is 1, which indicates that the user account is locked. The admin and root accounts are enabled (-1), and there are no disabled (0) accounts.

Change to config mode.

config

The CLI prompt changes to include

(config)

Set a password for the tenant console user.

system aaa authentication users user <tenant-name> config set-password password

This example sets a password for a specified tenant console user:

default-1(config)# system aaa authentication users user big-ip config set-password password
Value for 'password' (<string>): *********

Set an expiration date for the tenant console user.

system aaa authentication users user <tenant-name> config expiry-date -1

This example enables the specified tenant console user:

default-1(config)# system aaa authentication users user big-ip config expiry-date -1

Commit the configuration changes.

commit

Verify that the tenant console user is enabled and unlocked.

show system aaa authentication users

A summary similar to this example displays:

default-1# show system aaa authentication users
             LAST    TALLY  EXPIRY
USERNAME     CHANGE  COUNT  DATE    ROLE
----------------------------------------------------
admin        19370   0      -1      admin
big-ip       19389   0      -1      tenant-console
root         0       0      -1      root

Connect to a tenant instance console from the CLI

Before you can connect to a tenant console, your user account must have terminal access enabled. On BIG-IP tenants this is disabled by default.

The system creates the tenant-console user account by default when you create a tenant, but the account is expired and has no password. Before you can access the tenant console, you must first unlock the tenant-console user from the CLI.

When you log in to the system, you are in user (operational) mode.

View the instance identifier for a specified tenant on the chassis partition.

show tenants tenant <tenant-name> state instances

A summary similar to this example displays:

default-1# show tenants tenant big-ip state instances
state instances instance 1 big-ip
 instance-id   1
 phase         Running
 creation-time 2023-01-31T12:30:28Z
 ready-time    2023-01-31T12:30:55Z
 status        "Started tenant instance"
 mgmt-mac      ca:c3:7d:64:30:7e

Connect using SSH to the tenant console, using the name of the tenant as the SSH username.

ssh <tenant-name>@<chassis-partition-ip> -p 700<instance-id>

In this example, you connect to a tenant named "big-ip" at a specified chassis partition IP address, where

-p 7001

indicates the instance identifier for the tenant:

ssh big-ip@192.0.2.76 -p 7001

The default login password is default.

jdoe@SEA-00012345:~$ ssh big-ip@192.0.2.76 -p 7001
big-ip@192.0.2.76's password:
Successfully connected to big-ip console. The escape sequence is ^]

BIG-IP 17.1.0 Build 0.0.1599
Kernel 3.10.0-862.14.4.el7.x86_64 on an x86_64
big-ip login:

If you are unable to log in, verify that your user has terminal access enabled. This is disabled by default on BIG-IP tenants.

Tenant high availability (HA) overview

You can configure tenants for high-availability (HA) on an

VELOS

system similar to how it is done on a

BIG-IP

system or for vCMP guests. To implement high-availability, you set up device service clustering or DSC. DSC provides synchronization and failover of

BIG-IP

configuration data and traffic groups on two or more tenants. The tenant administrator sets up DSC on the tenants.

For information on

BIG-IP Next

tenant configuration, see my.f5.com.

While you can set up HA for two tenants

in two different chassis partitions on the same chassis

, it is not recommended. Mirroring is not supported on the same

chassis

. It is recommended that you set up HA for tenants

in chassis partitions on two different chassis

If you plan to set up mirroring, you must use an additional

chassis

. Connection mirroring requires that both

VELOS

systems have identical hardware platforms

(chassis and blades). Also, each chassis within the Sync-Failover device group must contain the same number of blades in the same slot numbers

Tenants must have identical resources to ensure seamless HA failover. F5 does not support HA between tenants on disparate platforms.

For more information, see these guides at K000130285: F5 Product Manuals Index:

vCMP for VIPRION Systems: Administration

BIG-IP Device Service Clustering: Administration

Configure high availability (HA) for
BIG-IP
tenants

Before you begin, you must set up two

VELOS

systems with initial configuration, management IP addresses, gateways, DNS servers, and licensing. For more information, see

VELOS Systems: Software Installation and Upgrade

and other sections in this guide.

For information about configuring high availability (HA) for

BIG-IP Next

tenants, see my.f5.com.

You can set up high availability for two

BIG-IP

tenants in chassis partitions that reside on two separate systems.

BIG-IP

tenant.

Make sure that both tenants are running the same

BIG-IP

software version and that it is compatible with VELOS systems.

On the tenants, set up L2 network connectivity between the two tenants including setting up VLANs and self-IPs for ConfigSync, failover, and mirroring.

For example, create the same VLAN on both tenants with management IP addresses that can communicate with each other.

Establish device trust: On one of the tenants, go to

Device Management

Device Trust

, create a device trust, and add the management IP of the other tenant.

Create a Sync-Failover device group: On the tenants, go to

Device Management

Device Group

and create a device group with the

Group Type

option set to

Sync-Failover

For more information, see the "Working with Device Groups" section in

BIG-IP Device Service Clustering: Administration

at K000130285: F5 Product Manuals Index ).

On the tenants, go to

Device Management

Devices

, select the device and initiate the first ConfigSync manually.

After setting up HA for tenants, you can optionally create traffic groups, enable mirroring on the virtual servers, and sync the configurations.

Understand that there are many ways to configure HA, and this summary explains the general work flow for how to approach tenant HA. Your environment might require additional steps.

Subscriptions

Product Usage

Trials

Registration Keys

Downloads

Applies To:

F5OS-C

Tenant Management

Tenants overview

Tenant data

Tenants in a chassis partition example

VELOS CX410 Chassis

VELOS CX1610 chassis

Tenant image overview

BIG-IP tenant images

BIG-IP Next tenant images

Tenant usage

Tenant sizing

Tenant resource allocation considerations

Tenant management from the webUI

Manage tenant images from the webUI

Create and deploy tenants from the webUI

Modify tenant deployments from the webUI

Enable appliance mode on tenants

Display tenant status and statistics from the webUI

Tenant management from the CLI

Import a tenant image from the CLI

Create and deploy tenants from the CLI

Upgrade Tenant to 16 Blade Configuration

Configure DAG IPv6 prefix length from the CLI

Display tenant information from the CLI

Display tenant status and statistics from the CLI

Modify tenant configuration from the CLI

Resize tenant virtual disk from the CLI

Transmission Control Protocol-Connection Overload Protection (TCP-COP) Overview

Configuring TCP-COP from the CLI

Delete a tenant from the CLI

Tenant CLI command syntax

Tenant console overview

Unlock the tenant console user from the CLI

Connect to a tenant instance console from the CLI

Tenant high availability (HA) overview

Configure high availability (HA) for BIG-IP tenants

Have a Question?

Follow Us

About F5

Education

F5 Sites

Support Tasks

Configure high availability (HA) for
BIG-IP
tenants