The BIG-IP Administration Data Plane Configuration (F5CAB3) exam (F5CAB3)

In F5 BIG-IP systems, an iApp is a template-driven framework used to deploy and manage application-specific configurations. When an iApp is deployed, the system creates a specialized folder or " Application Service " container to hold all the resulting Local Traffic Manager (LTM) objects, such as virtual servers, pools, and profiles. This container is visually and programmatically identified by the .app extension in its path name.

The naming convention for these objects follows a specific hierarchical structure: / < partition > / < iapp_name > .app/ < object_name > . For example, if an administrator creates an iApp named " testhttp " in the " /Common " partition, the virtual server created by that iApp would be identified in the configuration (TMSH) and the GUI as /Common/testhttp.app/testhttp. This structure allows the BIG-IP system to distinguish between manually created objects and those managed by the iApp ' s automation logic.

This identification is crucial because iApp-managed objects typically have Strict Updates enabled, which prevents administrators from making direct manual changes to the object settings outside of the iApp ' s reconfigure interface. Attempting to modify such an object directly will result in an error message stating that the application service must be updated using an application management interface. By recognizing the .app path and the repeated name within the structure, an administrator can immediately identify that the object belongs to an iApp and should be managed through the iApp ' s specific management screen rather than standard LTM configuration menus.

SSH is a Layer 4 TCP-based protocol that operates on TCP port 22 and does not use HTTP in any capacity. In the exhibit, the Virtual Server is configured with an HTTP Profile applied, which is inappropriate for SSH traffic and causes connection failures.

According to the BIG-IP Administration: Data Plane Configuration documentation:

An HTTP profile must only be applied to Virtual Servers handling HTTP or HTTPS traffic.

When an HTTP profile is attached, BIG-IP expects HTTP headers and attempts to parse application-layer data.

Non-HTTP protocols such as SSH, FTP (control), SMTP, and other raw TCP services will fail if an HTTP profile is enabled.

Why the other options are incorrect:

A. Set Protocol to UDPSSH uses TCP, not UDP. Changing the protocol would break SSH entirely.

B. Set Source Address to 10.1.1.2The source address setting controls client access restrictions and is unrelated to protocol parsing issues.

C. Set Destination Address/Mask to 0.0.0.0/0The destination address is already valid for a specific SSH service and does not impact protocol handling.

Correct Resolution:

The BIG-IP Administrator should remove the HTTP Profile (set it to None) so the Virtual Server functions as a pure Layer 4 TCP service, allowing SSH connections to pass through successfully.

The BIG-IP Configuration Utility (GUI) organizes information hierarchically to allow for granular management of application objects. A Pool is a collection of backend servers (pool members) that provide the same service. To verify the specific network parameters—such as the IP address and the service port—of the servers within a pool, the administrator must navigate to the specific pool ' s configuration.

The standard procedural path to verify this is Local Traffic > Pools: Pool List, where the administrator selects the specific pool name. Once inside the pool ' s configuration, the Members tab displays a list of all IP addresses and service ports associated with that pool. Under the " Service Port " column, the administrator can confirm if the member is listening on port 80 (HTTP).

Options A and B are incorrect for this specific verification task. While Nodes (Option A) show the health of a physical server, a node represents only an IP address and does not have a " Service Port " associated with it until it is defined as a pool member. Verifying the Health Monitor (Option B) would tell the administrator how the system is checking the member ' s status, but it does not definitively show the port on which the member is actually receiving application traffic. In a BIG-IP environment, a pool member is uniquely identified by the combination of its Node IP and its Service Port, and the Members tab is the primary interface for managing and auditing these specific member attributes.

A Performance (Layer 4) virtual server does not inspect or process application-layer data such as HTTP headers or cookies. Therefore, only Layer 4–compatible persistence methods can be used.

According to the BIG-IP Administration: Data Plane Configuration documentation:

Source Address Affinity persistence operates at Layer 4 and uses the client IP address to maintain session persistence.

It is fully compatible with Performance (Layer 4) virtual servers.

It works regardless of encryption, making it suitable for TLS-secured applications.

Why the other options are incorrect:

B. Cookie persistenceRequires an HTTP profile and Layer 7 inspection, which is not supported on Performance virtual servers.

C. Microsoft RDP persistenceIs protocol-specific and not applicable to web-based TLS traffic.

D. Host persistenceRequires HTTP host header inspection, which is not available at Layer 4.

Correct Resolution:

Source Address Affinity persistence is the appropriate choice for maintaining persistence on a Performance (Layer 4) virtual server handling TLS traffic.

Below is Batch 1 (Questions 1–10) extracted only from your uploaded document that are directly related to BIG-IP Administration: Data Plane Configuration topics (Virtual Servers, Pools, Load Balancing, Monitors, Persistence, SNAT, Profiles).

I have excluded system-only, licensing, support, hardware, HA management-only, and admin UI questions that are not Data Plane–focused.

Source: Your uploaded TMOS Administration v2.0 document

✅ BATCH 1 (10 Questions)

Source Address Affinity (Persistence) works by tracking the source IP address of incoming packets to ensure a client stays connected to the same backend server. The " netmask " setting within the persistence profile determines the " granularity " of this tracking. A netmask tells the BIG-IP how many bits of the source IP address to ignore when creating the persistence record. For example, the current setting of 255.0.0.0 (a /8 mask) means the BIG-IP only looks at the first octet of the IP; this results in all users from the same large Class A network (e.g., everyone from 10.0.0.0 to 10.255.255.255) being persisted to the exact same server, which can lead to severe load imbalance.

To ensure that each unique IP address creates its own individual persistence record, the administrator must set the netmask to 255.255.255.255 (for IPv4). This is a " host mask " or /32, which instructs the BIG-IP to evaluate all 32 bits of the client ' s source IP address. With this setting, 10.1.1.1 and 10.1.1.2 will be treated as distinct entities and can be load balanced to different servers, each maintaining their own " stickiness " . While Option A (255.255.255.0) would group users by their local subnet, only the full 255.255.255.255 mask satisfies the requirement for true unique-IP persistence. This configuration is standard for internet-facing applications where users arrive from diverse locations and the administrator wants to maintain the most granular and balanced distribution of traffic possible.

In F5 BIG-IP administration, iApps are designed to manage complex application configurations as a single unit. When an iApp is deployed, it creates an " Application Service " object that owns all the associated LTM objects, such as Virtual Servers, Pools, and Nodes. By default, these iApps are created with Strict Updates enabled. Strict Updates is a safety mechanism that prevents administrators from making manual " out-of-band " changes to the individual objects created by the iApp. The system enforces this because manual changes would be overwritten the next time the iApp template is updated or re-entered.

When the administrator attempts to change the destination IP address directly on the Virtual Server object, the BIG-IP system checks the " Strict Updates " flag. If it is set to " Enabled, " the system blocks the modification and generates the error message stating the service must be updated via the application management interface. To resolve this, the administrator must navigate to the iApp > > Application Services menu, select the specific application service, and go to the " Reconfigure " tab. Within the iApp configuration form, the destination IP can be safely changed. Alternatively, if the administrator specifically wants to manage the objects manually and forgo the benefits of the iApp template management, they could disable " Strict Updates " in the iApp properties, though this is generally discouraged as it breaks the template ' s logic. The error is not related to subnetting or duplicate IPs, but strictly to the configuration authority assigned to the iApp service.

In F5 BIG-IP architecture, a Trunk is a logical aggregation of physical interfaces designed to increase bandwidth and provide link redundancy through 802.3ad Link Aggregation Control Protocol (LACP). When creating a Trunk object within the BIG-IP configuration, the administrator must assign physical Interfaces to it — these are the underlying hardware ports (e.g., 1.1, 1.2, 1.3) that will be bundled together to form the aggregated logical link.

It is critical to understand the layered object hierarchy on the BIG-IP platform:

Interfaces → assigned to Trunks

Trunks (or individual Interfaces) → assigned to VLANs (as tagged or untagged members)

VLANs → assigned Self IP addresses

Self IPs / Routes → configured at the network layer above

VLANs are not added to a Trunk; rather, a Trunk is added as a member of a VLAN. IP addresses and network routes are configured independently at a higher abstraction layer and have no direct association with Trunk creation.

This layered design ensures proper separation of concerns across the data plane. Misunderstanding this hierarchy is a common configuration error that can result in traffic forwarding failures.

Connection rate limiting controls how many new connections per second are accepted, protecting backend resources.

The requirement states that load balancing decisions must be based on the number of active connections on each pool member. This directly maps to the Least Connections (member) load balancing method.

According to the BIG-IP Administration: Data Plane Configuration documentation:

Least Connections (member) selects the pool member with the fewest active connections at the time of the request.

This method dynamically adapts to real-time traffic patterns and ensures that more heavily loaded pool members receive fewer new connections.

It is especially effective for web servers where connection duration may vary and equal distribution of active sessions is desired.

Why the other options are incorrect:

B. Round RobinDistributes connections sequentially without considering current load or active connections.

C. Ratio (member)Distributes traffic based on static ratios, not real-time connection counts.

D. Ratio (node)Uses predefined ratios at the node level and does not account for active connection counts.

Correct Resolution:

Using Least Connections (member) ensures that new connections are directed to the pool member currently handling the fewest active connections, meeting the stated requirement.