F5 F5CAB1 BIG-IP Administration Install, Initial Configuration, and Upgrade Exam Practice Test

The BIG-IP has two distinct planes:

Management-plane → handled entirely by the management interface (MGMT)

Data-plane (TMM) → handles Self IPs, VLAN interfaces, and traffic processing

To capture traffic on the management interface, only the management-side NICs may be used:

mgmt → Logical name for the management interface

eth0 → Physical Linux interface mapped to the management port on most BIG-IP platforms

Both of these correctly capture inbound/outbound WebUI (HTTPS/443) traffic on the management port.

Why the correct answers are A and B

A. tcpdump -i eth0 -n port 443

On BIG-IP appliances and VMs, the management port maps to eth0 at the Linux OS level.

Capturing on eth0 correctly shows HTTPS traffic to the WebUI.

B. tcpdump -i mgmt -n port 443

mgmt is the BIG-IP alias for the management interface.

This is the preferred and most explicit capture interface for management-plane packet captures.

Why the other options are incorrect:

C. tcpdump -i 0.0

Interface 0.0 is the TMM switch interface used for data-plane packet captures.

It does NOT capture management-plane traffic.

D. tcpdump -i tun0

Used for tunnel interfaces (IPsec, VXLAN, etc.)

Not related to management access.

E. tcpdump -i management

There is no interface named management on BIG-IP.

The correct names are mgmt or eth0.

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.

The Port Lockdown feature controls which services a Self-IP will respond to.

Setting a Self-IP to Allow None means:

The Self-IP will not accept any traffic except the very limited, hard-coded HA ports such as TCP 4353 used for device trust and configuration sync.

All other HA ports , including those needed for network failover and other HA mechanisms, are blocked .

When essential HA services cannot communicate, each device assumes its peer is down.

This results in:

HA failover misbehavior

Both devices thinking the other is offline

Potential active-active condition , which is not intended and can cause traffic disruption

Thus, Allow None can break HA functionality unless the Self-IP is not used for HA links.

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

To install software on a new 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- < version > .iso volume HD1.5 create-volume

This syntax correctly includes:

install software image

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

volume name (HD1.5)

create-volume keyword

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 an existing volume only

The GUI install dialog does not create new boot volumes

Thus, only Option A and Option C properly create a new software volume.

Port Lockdown controls which ports and protocols a Self IP will respond to.

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

The three types that are NOT affected by Port Lockdown are:

1. Defined Virtual Server Traffic

Traffic destined to a Self IP that matches a configured virtual server is 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 is TCP 4353 , which is always permitted.

Why the other options are incorrect:

Option A: SSH is restricted by Port Lockdown unless explicitly allowed.

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

Only Defined VS Traffic , ICMP , and CMI bypass Port Lockdown.

Self-IPs include a security feature called Port Lockdown , which restricts which services respond on that Self-IP.

By default, Self-IPs block management access (SSH and HTTPS/TMUI), meaning an administrator cannot manage the device through in-band Self-IPs unless explicitly allowed.

Allow Mgmt / Allow Management

These settings enable only the management services required for administrative access, specifically:

SSH (22)

HTTPS/TMUI (443)

These options allow secure administration without opening unnecessary ports.

Why these are correct:

They provide only the essential access for management.

They follow F5 security best practices when using in-band admin access.

They do not expose all services, reducing the attack surface.

Why the other options are incorrect:

A. Allow Default

This allows only a minimal set of system-required ports (e.g., failover, config sync), not SSH or HTTPS.

Administrator access would still fail.

B. Allow All

Opens all ports on the Self-IP, which is not secure .

Exposes services that should remain restricted.

Therefore, Allow Mgmt / Allow Management are the correct choices.

From the exhibit, the administrator performs the following actions:

Displays the current SSH allow configuration:

tmsh list sys sshd allow

allow { ALL }

Replaces the existing SSH allow list with a specific subnet:

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

Confirms the updated configuration:

tmsh list sys sshd allow

allow { 10.0.0.0/24 }

This configuration restricts SSH access to only hosts that fall within the 10.0.0.0/24 network.

Evaluation of the options

A. 10.0.0.100

This address is within the 10.0.0.0/24 subnet and is a valid host address, so SSH access is permitted.

B. 10.0.0.254

This address is also within the 10.0.0.0/24 subnet and is a valid host address, so SSH access is permitted.

C. 10.0.0.256

This is not a valid IP address because an IPv4 octet cannot exceed 255.

D. 100.0.1.10

This address is outside the configured 10.0.0.0/24 subnet and will not be allowed.

E. 100.0.0.10

This address is also outside the configured subnet and will not be allowed.

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.

BIG-IP hardware platforms use chassis LEDs to indicate system health states.

A solid yellow status LED typically indicates a warning condition , such as:

A non-critical hardware alert

A temperature threshold nearing limit

A minor fan or sensor irregularity

Other non-fatal environmental or system conditions

This state reflects a warning-level alarm , meaning the unit is operational but requires investigation.

Why the other options are incorrect

A. Halted or EUD mode

This is associated with different LED patterns (usually flashing conditions or specific color codes), not a solid yellow status LED.

B. Standby in device group

HA state is not indicated by the chassis status LED.

Standby status is a logical device state, not a hardware LED state.

D. Power supply failure

Power supply indicators use separate LEDs located on each power module (usually flashing amber/red), not the system status LED.

Thus, a solid yellow status indicator signifies a warning-level alarm .

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.

BIG-IP allocates CPU and memory resources based on module provisioning levels.

To view how much CPU a module is assigned, administrators must check provisioning information from:

C. GUI — System » Resource Provisioning

This page visually displays CPU allocation via color-coded bars.

Hovering over the CPU bar shows:

CPU usage percent per module

Which modules share CPU cycles

The system’s total resource allocation

This is the primary GUI method.

D. tmsh show /sys provision

This command displays detailed module provisioning information including:

Provisioned modules

Their provisioning level

CPU and memory allocation data

It is the authoritative CLI method for resource provisioning status.

Why the other options are incorrect:

A. top

Shows real-time process usage, not provisioned CPU allocation.

B. tmsh show /sys cpu

Displays CPU runtime utilization, not per-module provisioning.

E. Statistics Dashboard

Only shows traffic / system runtime metrics, not provisioning resource allocations.

Therefore, C and D are correct.

Within the BIG-IP Traffic Management Shell (tmsh), system configuration objects—including the management IP—are organized under the /sys hierarchy. The management IP address is a configurable property stored in the system configuration and can be viewed using the tmsh list command, which displays configuration objects and their currently assigned values.

Why “list /sys management-ip” is correct

The list command in tmsh is used to display configured system values , not runtime statistics.

The object that holds the management IP settings on BIG-IP systems is located at: /sys management-ip

Running the command: list /sys management-ip will reveal the settings for the management IP interface, including the address, netmask, and any associated attributes.

This is the standard method used during system setup and verification to confirm the management IP configuration.

This behavior aligns with BIG-IP administration procedures, where configuration information is retrieved using list , while operational data is retrieved using show .

Why the other options are incorrect

A. run /util bash ifconfig mgmt

This command enters the Bash shell, then runs ifconfig to display the management interface.

While this can show the management interface address, it is not a tmsh-native command , and the question specifically asks for a tmsh command.

Administrators use tmsh directly for configuration display rather than leaving the shell.

C. show /sys management-ip

The show command displays statistics or operational data , not configuration values.

The management-ip object does not maintain statistics; therefore show does not return the configuration details required.

Only the list command reveals stored configuration data such as IP address and netmask.

When installing a BIG-IP software version with a HotFix on a new boot volume , F5 requires that both the base TMOS image and the HotFix image be installed together as part of the same installation workflow.

The correct process is:

Specify the base TMOS ISO

Specify the HotFix ISO that corresponds to that base version

Instruct the system to create a new boot volume

Install both images into that new volume

This is achieved with the following tmsh syntax:

tmsh install /sys software BIGIP- < version > .iso hotfix Hotfix-BIGIP- < version > -ENG.iso create-volume HD1.2

This command:

Installs the base image first

Applies the HotFix on top of the base image

Creates and installs everything on HD1.2

Leaves the currently active volume untouched for rollback

Why the other options are incorrect

A. Installing only the hotfix

A HotFix cannot be installed by itself on a new volume. A base image must already be present.

C. Using create instead of install

The create keyword is not valid for software installation operations.

D. Using copy

The copy command does not install software images or hotfixes.

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

The Service Check Date embedded in the BIG-IP license acts as a gating mechanism that determines eligibility for software updates. F5 enforces that the Service Check Date must be equal to or newer than the software release date of any BIG-IP version being installed. If the installed license carries a Service Check Date from two years ago, attempting to upgrade to a newly released BIG-IP software version — whose release date post-dates that Service Check Date — will fail, as the system validates this date during the upgrade process.

Option A is incorrect — generating and uploading a QkView to F5 iHealth is a diagnostic activity that requires no license validation or Service Check Date verification whatsoever.

Option C is incorrect — ASM signature and threat campaign updates are content updates, not platform software upgrades. These updates are independent of the Service Check Date requirement and do not trigger license validation checks during installation.

Only a platform software upgrade to a newly released BIG-IP version directly invokes the Service Check Date validation, mandating license renewal prior to the upgrade proceeding successfully.

Reference Topics: License Service Check Date, Software Upgrade Prerequisites, License Reactivation — BIG-IP Administration Study Guide.