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

The exhibit shows the configuration of aSelf IPwith:

Port Lockdown: Allow Custom

ACustom Listthat includes the following TCP ports:

443

22

Meaning of these ports:

TCP 443→ HTTPS (TMUI — web-based management)

TCP 22→ SSH (command-line remote access)

No other TCP, UDP, or protocol entries are listed; therefore, only these two services are allowed to reach the BIG-IP via this Self IP.

Evaluating the answer choices:

Option

Service

Port

Allowed?

FTP

TCP 21

Not listed

Not allowed

SSH

TCP 22

Listed

Allowed

Telnet

TCP 23

Not listed

Not allowed

Thus,SSHis the only traffic permitted through this Self IP configuration.

Access to the BIG-IP Configuration Utility (TMUI) is controlled through the/sys httpd allowlist.

This list defines which IP addresses or subnets are allowed to connect to the management web interface.

To allow two new subnets—172.28.31.0/24and172.28.65.0/24—the administrator mustaddboth subnets to the existing list without removing current entries.

In tmsh, subnet entries must be specified innetwork/netmask format, for example:

172.28.31.0/255.255.255.0

The correct tmsh command to append these networks is:

modify /sys httpd allow add { 172.28.31.0/255.255.255.0 172.28.65.0/255.255.255.0 }

Why the other options are incorrect:

Option B:

IPs are listed without masks, which is invalid for subnet-based access control.

The system requiresnetwork/netmaskformat.

Option C:

The command uses permit instead of allow, which is not a valid attribute of /sys httpd.

The correct keyword must beallow.

Thus, onlyOption Acorrectly adds both permitted subnets in the proper tmsh format.

Comprehensive and Detailed Explanation (Paraphrased from F5 BIG-IP Administration Install, Initial Configuration, and Upgrade concepts)

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 forknown bugs by TMOS version, module, severity, or defect ID.

Review thestatus 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 forhardware diagnostics(ports, memory, fans). It does not provide software-related issue verification and is not used for upgrade planning.

C. F5 University

This is atraining 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 isnot 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 licensing information, including theService Check Date, is stored in the file:

/config/bigip.license

This file contains all license attributes downloaded from the F5 licensing server, including:

License key

Licensed modules

Useful life date

Service check date

TheService Check Datedetermines whether the system is eligible for upgrades to specific TMOS versions. When reviewing upgrade readiness, administrators extract this value directly from the license file with:

grep "Service check date" /config/bigip.license

Why the other options are incorrect:

/config/bigip.confstores BIG-IP configuration objects, not license metadata.

/config/svc_chk_date.datisnota valid file in the licensing system; it does not contain license parameters.

/config/BigDB.datstores internal database values, not licensing attributes.

Thus, only thebigip.licensefile contains the correct licensing information required for verifying upgrade eligibility.

Port Lockdown controls which ports and protocols aSelf IPwill respond to.

However, certain traffic types bypass Port Lockdown for BIG-IP functionality and routing integrity.

The three types that areNOT affectedby Port Lockdown are:

1. Defined Virtual Server Traffic

Traffic destined to a Self IP that matches aconfigured virtual serveris always accepted by the BIG-IP, regardless of Port Lockdown settings.

This ensures that traffic processing does not break when administrators restrict Self-IP ports.

2. ICMP (Internet Control Message Protocol)

ICMP (such as ping, traceroute responses, etc.) always passes through a Self IP even when Port Lockdown is set to:

Allow Default

Allow None

Allow Custom

F5 allows ICMP for reachability and diagnostic purposes independent of Port Lockdown rules.

3. Centralized Management Infrastructure (CMI)

CMI includes the internal HA services used for:

Device Trust

ConfigSync

Failover

Mirroring

These essential HA communications bypass Port Lockdown to prevent accidental cluster failure.

The well-known port for this traffic isTCP 4353, which is always permitted.

Why the other options are incorrect:

Option A:SSHisrestricted by Port Lockdown unless explicitly allowed.

Option B:Same issue — SSH does not bypass Port Lockdown.

OnlyDefined VS Traffic,ICMP, andCMIbypass Port Lockdown.

Self-IPs implement a security feature known asPort Lockdown, which limits which services are reachable on a Self-IP.

However, certain services required for BIG-IP device-to-device communication bypass Port Lockdown to ensure cluster and HA functionality.

TCP 4353

TCP port4353is used byDevice Service Clustering (DSC)for:

Device trust establishment

Configuration synchronization

Failover communication

Because BIG-IP devices must always be able to communicate for HA functions to remain operational, port 4353 isexempt from Port Lockdown rules.

Why the other options are incorrect

A. TCP 443

Not required for device trust or synchronization.

HTTPS access is fully controlled by Port Lockdown.

C. UDP 53

DNS traffic is not required for synchronization and has no exemption under Port Lockdown.

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 theService Check Datein the device’s license file.

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

The systemboots into the new volume,

Butfails to load the configuration,

And will instead present messages indicating that the configuration cannot be applied due to aninvalid 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 thelicense was not reactivated before the upgrade, makingOption Bcorrect.

License reactivation updates the BIG-IP device’s license file to ensure:

TheService Check Dateis current

The device is eligible to install the intended TMOS version

Any module entitlement updates are received

Reactivationdoes not interrupt trafficand does not require a reboot, making it safe to performbeforethe maintenance window.

F5 best practices state:

Performall non-impact tasks priorto the scheduled maintenance window

Leave the window available for activities that require rebooting, such as the software installation itself

Since license reactivation isnon-disruptive, it should be donebeforethe upgrade window starts.

In BIG-IP, software images are installed onboot volumes(for example, HD1.1, HD1.2, HD1.3, etc.).

To install software on anew volume, the administrator must instruct the system to create a new boot location before installation.

There are two correct ways to create a new volume:

A. tmsh command (with correct syntax)

tmsh install software image /shared/images/BIGIP-.iso volume HD1.5 create-volume

This syntax correctly includes:

install software image

full path to ISO (/shared/images/...)

volume name (HD1.5)

create-volumekeyword

This instructs BIG-IP to create the new boot volume as part of the installation.

C. Using the GUI → System > Disk Management

From the Disk Management menu, the administrator can:

Select “New Volume”

Enter the volume identifier (e.g., HD1.5)

Apply changes

This GUI method is officially supported and explicitly creates a new boot volume before installing the software.

Why the other options are incorrect:

B. Incorrect tmsh syntax

Missing /shared/images/ path

Incorrect command structure

D. Incorrect command structure

Missing required keywords and correct command hierarchy

E. Software Management → Install does NOT create volumes

This installs to anexistingvolume only

The GUI install dialog does not create new boot volumes

Thus, onlyOption AandOption Cproperly create a new software volume.

Port Lockdown controls which ports and protocols aSelf IPwill respond to.

TheAllow Defaultsetting permits only a predefined set of BIG-IP internal and required service ports.

The Allow Default listincludes:

TCP 443→ HTTPS (Management/TMUI access via Self-IP)

TCP 4353 → CMI (device sync)

TCP/UDP ports related to HA communication

Other essential internal F5 ports

Why TCP 443 is correct:

It is one of the officially allowed ports underAllow Default.

It enables HTTPS/TMUI access through a Self IP.

Why the other options are incorrect:

A. TCP 80 (HTTP)

Not allowed under Allow Default

HTTP via Self-IP is blocked unless placed under Allow Custom

B. UDP 8443

Not an F5 default service

Not part of the Allow Default ports