Manual Chapter : System Overview

Applies To:

Show Versions Show Versions


  • 1.6.1
Manual Chapter

System Overview

Introducing the

platforms are a modular (chassis and blade) form factor, designed to meet the needs of large enterprise networking environments that require the ability to scale and process a large volume of increasing application workloads.
systems include a platform layer that runs F5OS-C software, which is a combination of software for the system controllers and chassis partitions. Chassis partitions are a kind of virtual system or subset of the chassis that handles the management and separation of disjoint sets of blades within the chassis. You can divide a chassis into multiple chassis partitions, and a chassis partition can have multiple tenants. A tenant is a guest system running software (for example, a
This illustration shows a simplified
deployment with a single CX410 chassis. The
system shown here has been divided into four separate chassis partitions. Chassis Partition 1 has two blades, Partitions 2 and 3 each have one blade, and Partition 4 has four blades. Each blade fits into one slot and can be configured to have either two interfaces (40Gb or 100Gb), or they can be broken out into multiple (25Gb or 10Gb) interfaces. Link aggregation provides redundancy in case network failures occur, and by spreading link aggregation groups (LAGs) across blades, you can protect against individual blade failures, assuming adequate resources are available.
Example VELOS system
You manage the chassis through two system controllers, which are deployed in a redundant configuration providing high availability and added performance. The system controllers connect to out-of-band management networks, and their management interfaces can be bonded together within a single LAG for added redundancy. Each system controller also has a dedicated console connection for direct console access.
For more information about
hardware components, see
Platform Guide: VELOS CX Series


This table lists some of the terms you will encounter when configuring VELOS systems.
appliance mode
Restricts user access to root and Bash at the system controller, chassis partition, and tenant levels. When enabled, the root user cannot log in to the system by any means, including from the serial console. Disabled by default.
The primary hardware component that handles traffic management including disaggregation, packet classification, and traffic-steering for the VELOS system. The CX410 chassis has eight available blade slots, and the CX1610 chassis has 32 available blade slots. Runs chassis partition software, on which tenants are deployed.
The main component of the unit that houses the blades, system controllers, and other components. The chassis can be divided into multiple chassis partitions.
chassis partition
A chassis partition is a grouping of blades that can be isolated from other blades within the same chassis. Each chassis partition is a separate managed system, unlike the tenant system’s administrative partitions within a single managed system. Chassis partitions are commonly use to allow for further isolation than just tenancy between different environments and can include one or more blades. You can manage a chassis partition using a REST API, CLI, and webUI.
chassis terminal service
Built into the system controller software, the chassis terminal service provides a way to access the console for the system controllers and all blades.
Platform operating system software that runs on VELOS system controllers and chassis partitions.
Link aggregation group. A way to group interfaces on the system so they function as a single interface. The LAG (like a trunk on BIG-IP systems) distributes traffic across multiple links, increasing the bandwidth by adding the bandwidth of multiple links together.
port group
A configuration object that is used to control the mode of the physical ports, whether they are bundled or unbundled, and adjust their speed.
A guest system (a virtualized BIG-IP instance similar to a vCMP guest) running software within a chassis partition. You can deploy multiple tenants in one chassis partition. BIG-IP is the F5 TMOS-based tenant, and BIG-IP Next is the next generation, modularized version of the BIG-IP tenant.
system controllers
Components of the chassis that provide a unified point for external management and connectivity to the platform and applications running in the chassis. The chassis contains a redundant pair of system controllers that provides a high bandwidth interconnect between blades and high availability. The system controllers also provide REST APIs, a system controller CLI, and a webUI.
Browser-based user interfaces for configuring the VELOS platform at the system controller (or chassis) level and at the chassis partition level.
  • System controller webUI: Used to create chassis partitions, manage users, and adjust system network settings and overall system settings such as licensing.
  • Chassis partition webUI: Used to deploy tenants, manage partition users, and adjust network settings, port groups, interfaces, and VLANs.
F5OS webUIs fully support the latest versions of Chrome and Firefox browsers at the time of each F5OS release.

system licensing overview

Before you can configure and use the
system, you must activate a valid license. The license service coordinates the license installation on the system controllers and configures the same license on the chassis partitions and the tenants. Because the system controller license applies to the whole system, the chassis partitions and tenants all inherit licenses from the system controllers.
For information about BIG-IP Next tenant licensing, see
A base registration key, generated by
, identifies a set of entitlements and is used to obtain the license for an F5 product. The base registration key with associated add-on keys are pre-installed on a new
system. If you do not have a base registration key, contact F5 Technical Support ( You can obtain add-on keys to enable additional features and functionality.
For more information about licensing your
system, see F5 VELOS system licensing overview.

Licensing terminology

Features and functionality of an
product that a customer can enable by purchasing a license.
base registration key
A 27-character string that informs the license server about which
products are included in the license.
add-on key
A 7-character string that enables features on a device, in addition to the entitlements associated with the device base registration key.
A digital fingerprint of an
product instance. The dossier uniquely identifies the device.

VELOS system administration user/role overview

You can configure and manage the
system at three different levels: the system controller or chassis level, the chassis partitions, and the individual tenants. Each has their own webUI, CLI, and REST API access.
The users at the system controller, chassis partition, and tenant levels are independent from each other, and the roles and what users can do are different depending on where the account was created. Even if one person is performing more than one role, separate accounts are needed at each level.
These administration and operator roles are available on
System controller administrator
Manages the whole chassis configuration with read-write access to all blades, terminal consoles, system controllers, system settings, and creates chassis partitions and users at the chassis level. Able to change the chassis root and admin passwords.
Chassis operator
Has read access to the chassis configuration and the ability to change operator password.
Chassis partition administrator
Manages the chassis partition, creates users in the chassis partition, has access to all tenant consoles in that chassis partition. Able to change the chassis partition root and admin passwords.
Chassis partition operator
Has read access to the chassis partition configuration and the ability to change operator password.
Tenant administrator
Has access to the tenant only. Performs user management on the deployed tenant(s). No management of the

VELOS administration tasks overview

There are many different tasks involved in administering
systems. Though a configured and fully functioning system might have several different system administrators for the system controllers, chassis partitions, and tenants, it is useful to have a general idea of all of the tasks involved and the order in which you might perform them. This is generally the order in which things happen, and it is just an overview of the many tasks involved:

Before using this guide

  • Complete hardware installation. For information about the hardware, see
    Platform Guide: VELOS CX Series
  • Complete initial configuration. This includes configuring management IP addresses, gateway address, and creation of a chassis partition. For information about initial configuration, see
    VELOS Systems: Getting Started
  • Make sure the
    system is made accessible. Configure network settings, DHCP, DNS, NTP. Initially, the system controller and chassis partition software will be installed. For information about software installation, see
    VELOS Systems: Software Installation and Upgrade

Plan the configuration

  • Depending on the number of blades installed and your business needs, determine how many chassis partitions to create.
  • What is the network configuration at the system controller level including management interfaces?
  • What is the network configuration for the chassis partitions including port groups, interfaces, and VLANs. Will you use link aggregation or spanning tree protocol?
  • How many administrators and operators will need accounts on the system at the system controller level? On the chassis partition level?
  • How will system users be authenticated? RADIUS or LDAP?
  • Within each partition, how many tenants do you plan to deploy?
  • What will the tenants be used for? For example, which application delivery modules will you be configuring? Multiple modules?
  • The configuration can be modified later if needs change.

Configure the system from the system controller

  • Log in to the system controller.
  • License the system, if it wasn't done already. See the
    System Settings
  • Adjust network settings such as management interfaces if needed. See the
    Network Settings
  • Create chassis partitions dividing up the blades. See the
    Chassis Partitions
  • Optionally, create accounts for system controller administrators or operators. See the
    Authentication & Access

Configure the system from the chassis partitions

  • Log in to the chassis partition. See the
    Chassis Partitions
  • Configure or adjust port groups, interfaces, VLANs, and LAGs. See the
    Network Settings
  • Optionally, create accounts for chassis partition administrators and operators. See the
    Authentication & Access

Deploy tenants in the chassis partitions

  • Log in to the chassis partition. See
    Chassis Partitions
  • Consider tenant resources needed with regard to the different tenant images of different sizes that are available. Understand the size of the chassis partition and plan what hardware resources will be configured for this partition. See the
    Tenant Management
  • Deploy one or more tenants in the chassis partition. See the
    Tenant Management
  • Log in to each tenant and configure the system as needed.
    • BIG-IP
      is the F5 TMOS-based tenant. For
      tenant information, see the
      system documentation at
    • BIG-IP Next
      is the next generation, modularized version of the BIG-IP tenant. For
      BIG-IP Next
      tenant information, see the documentation on and

High availability overview

There are three levels of high availability in the
system: system controller, chassis partition, and tenant.

System controller high availability

The system controllers are designed to work together as a redundant, high availability pair.
One of the system controllers is designated as active (or the primary node) and the other as standby. The default mode for system controller high availability (HA) is Auto, which lets the system select the system controller that is best suited at the time to be the active system controller. This is the recommended setting.
For more information about system controller high availability, see System controller high availability overview.

Chassis partition high availability

Chassis partitions are designed so that all of the chassis partition configuration data is stored on both the active and standby controllers. It is configured automatically for high availability.
For more information about chassis partition high availability, see Chassis partition high availability (HA) overview.

Tenant high availability

You can configure tenants for high-availability (HA) on a
For more information about tenant high availability, see Tenant high availability (HA) overview.

System management IP address overview

platforms are composed of a chassis that includes two system controllers and one or more blades. The system controllers provide a high bandwidth interconnect between blades and external management connectivity to the system. The system controllers set and maintain the configuration for the whole system.
You assign fixed management IP addresses to system controller 1 and system controller 2. You also assign a floating management IP address, which always points to the active system controller. The floating IP address ensures that when you connect to that address, you are connecting to the currently-active system controller, regardless of which controller is currently active.
You also assign a management IP address to each configured chassis partition and tenant.
When sending traffic out of a management interface, consider this source IP address determination process:
  • Management traffic sourced from the active system controller uses the fixed management IP address for the active controller as the source IP address.
  • Management traffic sourced from a chassis partition uses the chassis partition's individual management IP address.
  • Management traffic sourced from a tenant uses the tenant's individual management IP address. For BIG-IP tenants, this is also the cluster IP address.
For example, when you run commands from the active system controller, if the routing table determines that traffic should leave from the management interface, the traffic uses the controller's fixed management IP address by default as the source IP address of the Internet Control Message Protocol (ICMP) packets. When the same process occurs from a chassis partition, the traffic uses the chassis partition’s individual management IP address.
This information might be required when you configure access lists on a firewall or router that the
system will traverse with its management traffic. Any application performing source IP address filtering, such as an Active Directory server used by the
system for remote authentication or an SNMP management system, should account for the same considerations.
For more information about configuring management IP addresses on BIG-IP tenants, see
VIPRION Systems: Configuration
at the BIG-IP LTM Knowledge Center.