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

To understand:

Which modules arelicensed

Which modules areprovisioned

Theresource 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 underResource Provisioning.

The exhibit shows theCurrent Resource Allocationfor:

CPU

Disk

Memory

In particular, theMemory Allocationbar displays the modules that are currently provisioned.

Memory is the most reliable indicator because BIG-IP allocates memoryonlyto modules that are actively provisioned.

From the exhibit:

MGMT(Management) – always present

TMM(Traffic Management Microkernel) – indicatesLTM is provisioned

GTM– this label indicates that theDNS moduleis provisioned (GTM = Global Traffic Manager, now called DNS)

APM– explicitly shown, indicatingAccess Policy Manageris provisioned

Therefore, the provisioned modules are:

LTM(implied by TMM allocation)

DNS/GTM

APM

This matchesOption C: LTM, DNS, APM.

Provisioning settings define which modules are enabled and how system resources are allocated to them.

These provisioning declarations are stored in:

/config/bigip.conf

This file contains:

Full module provisioning statements

TMSH-equivalent provisioning configurations such as:

sys provision ltm { level nominal }

sys provision asm { level nominal }

It is theprimary system configuration filethat stores all active provisioning details.

Why the other answers are incorrect

A. /config/bigip.license

Showslicensedmodules, not provisioned modules.

B. /config/bigip_base.conf

Stores base networking (VLANs, Self-IPs, routes), not provisioning.

D. config.ucs

A backup archive, not a live configuration file.

Thus, the correct file to review active module provisioning is/config/bigip.conf.

The exhibit shows aSelf IPwith:

VLAN:Data

Port Lockdown:Allow None

Impact of “Allow None” on SNMP

When a Self IP is configured with:

Port Lockdown: Allow None

the BIG-IP blocksallservices and ports except a few hardcoded HA communication ports.

This means:

UDP/161 (SNMP)is blocked

UDP/162 (SNMP traps)is blocked

The SNMP server cannot poll or receive data from the BIG-IP through this Self IP

SNMP relies on access through the Self IP if out-of-band (mgmt interface) is not used.

Thus, the issue is directly caused byPort Lockdown = Allow None, which prevents SNMP communication.

Why the other options are incorrect:

B. Traffic Group must use a floating Traffic Group

SNMP polling doesnotrequire floating Self IPs.

Floating groups apply to HA failover IPs, not SNMP functionality.

C. VLAN/Tunnel must allow All VLANs

Self IPs are always bound to a VLAN; SNMP doesnotrequire All VLANs.

As long as the Self IP belongs to a reachable VLAN, SNMP can work.

D. Configuration is correct

It is not correct:Allow Noneblocks SNMP and is the problem.

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

Install the base TMOS imageon an unused boot volume

Install the corresponding HotFixonto that same boot volume

Activate the updated boot volumeto 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

OptionCmatches 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 appliedafterthe 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 Cis the correct sequence.

To change the boot volume on a BIG-IP system from one installed TMOS version to another, the correct CLI tool is:

switchboot

The correct syntax uses the-bflag:

switchboot -b

This command marks the specified boot location as the one to be used on the next reboot.

Thus, to boot intoHD1.2which contains13.1.0.6, the sequence is:

Mark HD1.2 as the next boot location:

switchboot -b HD1.2

Reboot the system:

reboot

This is the standard and officially supported method for selecting a different installed volume.

Why the other options are incorrect:

A. "tmsh reboot HD1.2"

There is no such tmsh syntax.

Boot volume cannot be selected by adding a parameter to reboot.

C. switchboot -I HD1.2

The -I flag is invalid. Only -b is used.

D. "tmsh switchboot HD1.2"

switchboot isnota tmsh command; it is a system-level shell utility.

Therefore,Option Bis the correct and valid command sequence.

When you chooseAutomaticas the activation method in the License › Re-activate screen, the BIG-IP device itself contacts F5’slicense activation serviceover the Internet.

For successful automatic activation:

The BIG-IP must have outbound network connectivity (typically via the management interface).

DNS resolution and routing must allow it to reach theF5 license activation host(the one shown in option D).

The device sends its dossier and registration key to that service and receives an updated license file in return, which is then installed automatically.

The other hostnames in the options are not used by BIG-IP for license activation, so they cannot be correct in the context ofAutomatic Activation.

The BIG-IPmanagement interface (MGMT port)is controlled throughSystem 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 themanagement interfacemust be done under:

✔System → Configuration → Device → General

Which corresponds toOption C.

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.