F5CAB1 BIG-IP Administration Install, Initial Configuration, and Upgrade Questions and Answers

When installing a HotFix on a BIG-IP device, F5 best practices require:

Installing the base TMOS image on a new, unused boot volume (HD1.2)

This ensures the upgrade happens on a clean volume.

The existing active boot location remains untouched for rollback.

Installing the HotFix onto the SAME new boot volume (HD1.2)

HotFixes must be applied on top of a base version.

They cannot be installed on an empty volume.

They must match the base image version.

Activating the new boot volume (HD1.2)

The system reboots into the updated software stack.

Activation happens after base + HotFix installation is complete.

This sequence is exactly shown in Option C :

Install base Image in HD1.2

Install HotFix in HD1.2

Activate HD1.2

Why the other options are incorrect:

A. Install HotFix before base image

Impossible.

HotFix requires an installed base version first.

B. Installing HotFix on HD1.1 (active boot volume)

Not recommended.

Upgrading in-place removes rollback safety.

HotFix cannot be applied cleanly without applying base image first.

D. Activate HD1.2 before installing anything

You cannot activate an empty boot volume.

Activation only occurs after the base + HotFix software is installed.

To understand:

Which modules are licensed

Which modules are provisioned

The resource requirements (CPU / RAM) of each module

The administrator uses:

System » Resource Provisioning

This page displays:

All modules present in the license

Whether they are enabled or disabled

Required memory to activate each module

CPU and disk allocation information

Provisioning level options (None / Minimal / Nominal / Dedicated)

This is the exact location where BIG-IP administrators evaluate module capacity before enabling or purchasing licensing upgrades.

Why the other options are incorrect:

A. Configuration » OVSDB

Used for network virtualization integrations, not licenses or modules.

B. Software Management

Used for software image installation, not licensing.

C. Configuration » Device

Displays hostname, failover settings, device properties — not module resource requirements.

Thus, module licensing and memory requirement data are found under Resource Provisioning .

Comprehensive and Detailed Explanation From BIG-IP Administration — Install, Initial Configuration, and Upgrade:

BIG-IP Self IP addresses have an associated Port Lockdown feature that governs which protocols and services are permitted to communicate directly with that Self IP. By default, Self IPs may allow broader access than desired, making Port Lockdown a critical hardening control.

The Allow Custom option under Port Lockdown is the precise mechanism for administrators who need granular, port-specific filtering. When selected, only the explicitly listed TCP/UDP ports are permitted — all others, including port 443 (HTTPS), are implicitly denied. This satisfies the requirement of blocking 443 specifically while preserving access on other required ports.

The remaining options are incorrect for this scenario:

Option A references SSH access control under System » Platform, which governs management-plane SSH — not Self IP service filtering.

Option B disables the entire Self IP, removing all traffic handling, which is operationally disruptive.

Option D — Allow None — blocks all traffic to the Self IP, not selectively port 443.

The Allow Custom approach provides the surgical precision required: administrators enumerate permitted ports, and everything outside that list — including 443 — is dropped.

Reference Topics: Self IP Port Lockdown, Network Security Hardening, Self IP Configuration — BIG-IP Administration Study Guide.

When a TMOS image (.iso file) is uploaded into the /shared/images/ directory, the BIG-IP performs an internal validation step before the ISO appears in the GUI.

1. The system verifies the internal checksum

BIG-IP automatically reads the embedded checksum inside the ISO file

Verifies integrity of the uploaded image

Confirms the file is not corrupted or incomplete

Ensures the image is a valid F5 TMOS software image

Only after this checksum verification succeeds does the image appear under:

System → Software Management → Image List

Why the other options are incorrect:

A. The system performs a reboot into a new partition

Uploading an ISO file never triggers a reboot.

C. The system copies the image to /var/local/images/

All valid TMOS images remain in /shared/images/ .

No copying occurs.

BIG-IP module provisioning determines how CPU, memory, and disk resources are allocated to each licensed module. F5 defines a specific set of supported provisioning levels.

Valid provisioning (resource allocation) settings

Nominal

Allocates a standard, balanced amount of system resources to a module.

Intended for typical production deployments where multiple modules may be provisioned at the same time.

Dedicated

Allocates all available system resources to a single module.

Used when the BIG-IP device is dedicated to running only one module (for example, ASM-only or APM-only deployments).

No other modules can be provisioned when one is set to Dedicated.

These two options are valid and supported provisioning levels.

Why the other options are incorrect

Maximum

This is not a valid BIG-IP provisioning level.

BIG-IP does not use “Maximum” as a resource allocation setting.

Limited

This is also not a supported provisioning level.

BIG-IP uses levels such as None, Minimal, Nominal, and Dedicated (module-dependent), not Limited.

When performing a TMOS upgrade, F5 recommends validating the target software version to ensure that the release does not contain defects that may impact system behavior. The upgrade preparation process includes checking for known issues, validating compatibility, and reviewing advisory information for the intended version. Two primary F5 tools serve this purpose:

B. F5 iHealth

iHealth is a cloud-based diagnostic and analysis platform used to evaluate the operational state of a BIG-IP system.

Administrators upload a QKView file to iHealth to receive an automated assessment of the system. As part of upgrade planning, iHealth provides:

Version-specific issue analysis , comparing the system’s configuration and hardware against F5’s internal catalog of published issues.

Upgrade advisories , identifying potential risks such as deprecated features, module compatibility concerns, or changes in behavior between TMOS versions.

Checks against known defects , allowing administrators to determine whether the target TMOS version contains issues relevant to their deployment.

This aligns with F5’s recommended upgrade workflow, where iHealth is used before upgrading to confirm system readiness and detect software-level concerns.

D. F5 Bug Tracker

The Bug Tracker is F5’s dedicated interface for reviewing software defects across TMOS releases.

It enables administrators to:

Search for known bugs by TMOS version , module, severity, or defect ID.

Review the status of defects (open, resolved, fixed in later releases).

Identify whether high-impact or security-related issues are associated with the target upgrade version.

F5 documentation emphasizes reviewing known defects prior to installation of new software images, making the Bug Tracker a critical resource for upgrade validation.

Why the other options are not correct

A. F5 End User Diagnostics (EUD)

EUD is used exclusively for hardware diagnostics (ports, memory, fans). It does not provide software-related issue verification and is not used for upgrade planning.

C. F5 University

This is a training platform , not an operational tool. It does not provide defect listings or upgrade-specific warnings.

E. F5 Downloads

Although it provides access to software images and release notes, it is not a tool for identifying known bugs . Release notes summarize general fixes and features, but systematic bug verification requires iHealth or the Bug Tracker.

BIG-IP controls access to the web-based Configuration Utility (TMUI) through the /sys httpd allow list. This parameter specifies which client IPs or subnets may initiate HTTP/HTTPS connections to the management interface.

To restrict TMUI access to only the 10.0.0.0/24 subnet:

The correct method is to modify the HTTPD allow list so that it contains only this subnet.

This requires replacing the entire current list with the new subnet using:

modify /sys httpd allow replace-all-with {10.0.0.0/24}

This ensures that only clients within 10.0.0.0/24 can reach the Configuration Utility.

Why the other options are incorrect:

Options A and C create network ACL objects under /net acl, which apply to data-plane traffic, not management-plane TMUI access. TMUI access is not controlled by LTM ACLs but by the HTTPD allow directive.

Option B is incorrect syntax and references /ltm httpd, which is not the proper object; the correct hierarchy is /sys httpd.

Thus, only modifying the /sys httpd allow list achieves the required restriction.

When upgrading to a newer TMOS software version, BIG-IP validates whether the current license is permitted to run that version.

This is controlled by the Service Check Date in the device’s license file.

If the Service Check Date is older than the minimum required for the target version:

The system boots into the new volume ,

But fails to load the configuration ,

And will instead present messages indicating that the configuration cannot be applied due to an invalid or outdated license .

This is a well-known behavior:

An outdated license, not reactivated before upgrade, causes configuration load failure after reboot into the new software.

Why the other options are incorrect:

A. Performed on the standby unit

Upgrading a standby unit does not cause configuration load failure.

Standby-only upgrades are standard best practice.

C. Two reboots required

BIG-IP does not require two reboots during an upgrade.

One reboot into the new volume is sufficient.

D. DNS connectivity failure

DNS connectivity does not affect configuration loading.

DNS is only needed for automatic license activation, not for applying config at boot.

Thus, the configuration failed to load because the license was not reactivated before the upgrade , making Option B correct.

When logged into the bash shell of a BIG-IP system, there are two valid ways to view the management-ip address:

A. tmsh list /sys management-ip

Even from the bash shell, the administrator can enter a tmsh command by typing:

tmsh list /sys management-ip

This displays:

Management IP address

Netmask

Any configured management routes

This is the official tmsh method for viewing the management-ip configuration.

C. ifconfig mgmt

In the underlying Linux OS, the management interface maps to the mgmt interface.

Running:

ifconfig mgmt

displays:

Assigned management IP

Netmask

Link-level status

This is a valid Linux-level method used frequently for troubleshooting.

Why the other options are incorrect:

B. show mgmt ip

Not a valid bash or tmsh command on BIG-IP.

D. list / sys management-ip

Missing the tmsh prefix.

In bash, this will generate a syntax error.

The correct form requires:

tmsh list /sys management-ip

The BIG-IP management interface (MGMT port) is controlled through System settings , not through the Network menu.

SSH access on the management interface is configured here:

System → Configuration → Device → General → SSH Access / SSH IP Allow

This section allows the administrator to:

Enable or disable SSH service

Restrict SSH access to specific IP addresses or subnets

Apply security policies to the management interface

Why the other options are incorrect:

A. Network > Interfaces

Used for data-plane physical interface settings, not management plane SSH restrictions.

B. Network > Self IPs

Controls in-band management or data-plane access, not the dedicated management port.

D. System > Platform

Used for hostname, time zone, LCD contrast, hardware settings — not SSH security on the management port.

Therefore, restricting SSH access to the management interface must be done under:

✔ System → Configuration → Device → General

Which corresponds to Option C .

When installing a software upgrade with a HotFix on BIG-IP, the correct workflow requires:

Install the base TMOS image on an unused boot volume

Install the corresponding HotFix onto that same boot volume

Activate the updated boot volume to boot into the new software

This method ensures:

The existing active system (HD1.1) is untouched

The upgrade occurs in a new, clean volume (HD1.2)

The HotFix applies properly to the same base image

The administrator can revert to HD1.1 if issues occur

Option C matches the correct F5 upgrade sequence:

1. Install base image on HD1.2

2. Install HotFix on HD1.2

3. Activate HD1.2

Why the other options are incorrect:

A. Install HotFix before base image

HotFixes must be applied after the base image; not valid.

B. Installing a HotFix on the active boot location (HD1.1)

Not recommended and does not use a clean new volume.

Also does not involve installing the base image.

D. Activating HD1.2 before installing anything

Cannot activate an empty or invalid boot volume.

Thus, Option C is the correct sequence.