F5 F5CAB3 BIG-IP Administration Data Plane Configuration (F5CAB3) exam Exam Practice Test

To fulfill the requirement of " SSL Offload " limited to " TLSv1.2 only, " the administrator must focus on the client-side of the connection. SSL Offload means the BIG-IP terminates the encrypted connection from the user, processes the traffic (often as plain text internally), and optionally sends it to the backend. The profile responsible for this termination and the initial negotiation with the client ' s browser is the Client SSL Profile.

A custom Client SSL Profile must be created because the default clientssl profile typically allows a broad range of protocols for compatibility (including TLS 1.0, 1.1, and 1.2). To restrict communication specifically to TLS 1.2, the administrator modifies the Ciphers string within the profile. Using a string such as DEFAULT:!SSLv3:!TLSv1:!TLSv1.1 or specifically defining TLSv1.2-only suites ensures that the BIG-IP will reject any handshake attempts from older, less secure protocols.

Server SSL Profiles (Options B and C) are used for the encryption between the BIG-IP and the backend nodes, which is not what is requested here. Simply selecting " no TLSv1 " in an options list (Option D) is insufficient and often refers to older versions of the software; the modern and standard way to control protocol negotiation on a BIG-IP is through the precise application of Cipher Strings within the Client SSL profile. This ensures compliance with security standards like PCI-DSS while providing the offloading benefits to the backend infrastructure.

SSH is a TCP Layer 4 protocol. Applying an HTTP profile causes BIG-IP to expect HTTP headers, breaking SSH sessions. Removing the HTTP profile allows raw TCP forwarding.

Standard DNS queries use UDP. Configuring the Virtual Server for TCP causes DNS traffic to fail.

This question tests precise knowledge of both TMSH command syntax and BIG-IP object namespace hierarchy . Two critical distinctions must be correctly identified:

1. create vs. modify: Since the Trunk already exists and the administrator is adding interfaces to it, the correct verb is modify — not create . Using create on an existing object would either throw an error or attempt to overwrite the object entirely, neither of which is the desired outcome.

2. /sys vs. /net namespace: Trunk objects in BIG-IP reside within the /net namespace, which encompasses network-layer constructs including Trunks, VLANs, Self IPs, and Routes. The /sys namespace is reserved for system-level objects such as management settings, software, and licensing — it does not contain Trunk objects.

Therefore, the only syntactically and functionally correct command is:

tmsh modify /net trunk trunk_A interfaces add {1.3 1.4}

This command appends interfaces 1.3 and 1.4 to the existing trunk_A object without disrupting currently assigned interfaces, increasing aggregated bandwidth accordingly.

Options A and C use the incorrect /sys namespace, and options A and B incorrectly use the create verb for an existing object.

Slow Ramp Time prevents new pool members from receiving full traffic immediately, avoiding overload.

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.

Performance (Layer 4) virtual servers rely on FastL4 profiles to provide high-speed L4 processing without full proxy overhead.

Below is BATCH 2 (next 10 questions) extracted only from your uploaded document that are clearly related to BIG-IP Administration: Data Plane Configuration topics.

❗As requested, I have strictly excluded questions related to:

Licensing

HA / Device Trust / Sync-only

Logging destinations

User roles

Hardware, EUD, support processes

System-only administration

Source: Your uploaded TMOS Administration v2.0 document

WAN TCP profiles are optimized for high latency and packet loss typical of Internet clients, while LAN profiles are ideal for backend servers.

A red diamond indicates the Virtual Server is enabled but unavailable due to all pool members being down.

The issue of " lost shopping carts " in an ecommerce environment is a classic symptom of a missing or improperly configured Persistence Profile. In modern web applications, session data—such as items added to a cart—is often stored locally on the specific web server that initially handled the user ' s request. If the BIG-IP system load balances a user ' s subsequent request (like clicking " Checkout " ) to a different server among the 50 webservers, the new server will not have the session data, and the user will appear to have an empty cart.

While Least Connections (node) is an efficient load balancing algorithm, it makes a new decision for every connection unless persistence is enabled. To resolve this, the administrator must implement a persistence mechanism. HTTP Cookie Persistence (Option A) is the industry standard for web applications. By assigning a cookie persistence profile to the Virtual Server, the BIG-IP inserts a unique cookie into the HTTP response. When the user ' s browser returns that cookie in future requests, the BIG-IP identifies the specific server that handled the first request and consistently directs the user back to that same server for the duration of their session.

Sip_info (Option B) is a persistence method for VOIP traffic and is not applicable to web traffic. Ratio load balancing (Options C and D) merely changes the distribution frequency but still does not guarantee that a specific user will stay on the same server across multiple requests. Therefore, adding a cookie persistence profile is the direct procedural fix to maintain session state and ensure ecommerce functionality.

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.

When a failover occurs in a standard BIG-IP High Availability (HA) pair, the newly active device takes over the floating IP addresses (Virtual Servers, Self IPs). By default, the new active device sends Gratuitous ARP (GARP) messages to the local network switch to inform it that these IP addresses are now associated with its own physical MAC addresses. However, network switches and intermediate routers often have ARP aging timers or security features that may delay the updating of their ARP tables, leading to " black-holed " traffic or dropped packets for several seconds or minutes until the network infrastructure correctly relearns the new path.

To eliminate this delay and ensure a seamless transition, a BIG-IP Administrator should Configure MAC Masquerade. MAC Masquerade allows the administrator to assign a unique, " virtual " MAC address to a specific traffic group. Instead of using the hardware-burned MAC address of the individual appliance, the active device uses this shared virtual MAC address for all communication involving floating IPs. When a failover occurs, the standby device assumes control of the traffic group and begins using the exact same virtual MAC address. Because the MAC address associated with the VIPs never changes from the switch ' s perspective, there is no need for the switch to update its MAC address table or for the surrounding infrastructure to update its ARP caches. This effectively eliminates the " stabilization period " reported by users, as the data plane transition happens almost instantaneously at Layer 2, maintaining continuous traffic flow without being hindered by external network re-convergence times.

HTTP Compression on a BIG-IP system is an optimization feature that reduces the size of HTTP responses sent to clients, thereby saving bandwidth and improving page load times for end-users. To implement this functionality on a Virtual Server, the system requires two specific profiles to work in tandem: an HTTP profile and a Compression profile.

The HTTP profile (Option E) is a prerequisite because compression is an application-layer (Layer 7) operation. The BIG-IP must be " HTTP-aware " to parse the incoming requests and outgoing responses. The HTTP profile allows the BIG-IP to inspect the Accept-Encoding header from the client (to see if the client supports gzip or deflate) and to modify the Content-Encoding and Vary headers in the server ' s response. Without the HTTP profile, the Virtual Server operates at Layer 4 (TCP) and sees the traffic only as an opaque stream of bytes, making compression impossible.

The Compression profile (Option B) contains the actual settings and engine for the task. It defines which content types should be compressed (e.g., text/html, application/javascript), the compression level, and the minimum content length required before compression is applied. While a Stream profile (Option D) is used for data replacement (search and replace) and SSL profiles (Option C) are used for encryption, they do not provide compression logic. By applying both the HTTP and Compression profiles, the BIG-IP can successfully intercept server responses, compress the payload according to the configured policy, and deliver the optimized data to the user, effectively offloading the CPU-intensive compression work from the backend web servers.

Using “at least one” ensures each member is marked up based on its relevant service monitor.

To solve this requirement, we must distinguish between the two " legs " of an SSL connection in a BIG-IP environment: Client-side and Server-side.

Current State (SSL Bridging): The administrator states the servers currently require encrypted traffic. This means the BIG-IP is likely performing " SSL Bridging. " In this setup, a Client SSL profile terminates encryption from the user, and a Server SSL profile re-encrypts the traffic before sending it to the back-end servers.

Target State (SSL Offloading): The requirement is to " offload SSL " to reduce web server load. This means the BIG-IP will continue to handle the encryption for the users (keeping the Client SSL profile) but will communicate with the back-end servers using unencrypted HTTP.

Why Option A is correct:

Remove the Server SSL profile: By removing this profile, the BIG-IP stops attempting to initiate an SSL/TLS handshake with the pool members.

Configure Pool Members to use HTTP: The service port for the pool members must be changed (typically from port 443 to port 80) so that the BIG-IP sends standard HTTP traffic to the servers.

Why other options are incorrect:

B & D: These suggest removing the Client SSL profile. If you remove this, the users can no longer connect via HTTPS, which violates the requirement for encrypted communication between the users and the BIG-IP.

C: Changing the Virtual Server to accept HTTP traffic would mean the user-to-BIG-IP connection is no longer encrypted, which is the opposite of SSL termination/offloading.

This scenario describes a classic case of asymmetric routing in a " one-arm " or non-gateway deployment. When a BIG-IP system is configured for SSL offloading, the following traffic flow occurs:

Client-Side: The client establishes a successful SSL/TLS handshake with the Virtual Server. This explains why the user can " successfully establish an SSL connection. "

Server-Side: The BIG-IP decrypts the traffic and forwards it as plain HTTP to the backend server. The packet trace confirms the server receives the HTTP GET request and responds with the content.

The Routing Failure: By default, the BIG-IP system preserves the client ' s original source IP address. If the backend server ' s default gateway is not the BIG-IP system (or if the server is on the same subnet as the client), the server will attempt to send the response directly back to the client ' s IP address, bypassing the BIG-IP.

Stateful Drop: Because the BIG-IP is a Full Proxy, it expects the response to return through its own internal state table to be encrypted and sent back to the client. Since the response bypasses the BIG-IP, the BIG-IP connection eventually times out, and the client receives no data despite the server having sent it.

Solution (SNAT): Enabling Secure Network Address Translation (SNAT), specifically SNAT Auto Map, ensures that the BIG-IP replaces the client ' s source IP with its own internal self-IP before sending the request to the server. This forces the server to send the response back to the BIG-IP, allowing the BIG-IP to complete the transaction and deliver the content to the user.

In the F5 BIG-IP ecosystem, a standard ICMP health monitor functions by sending an ICMP echo request to a target node and expecting an ICMP echo reply within a specified timeout period. When a node is marked " DOWN " despite the backend server being configured to respond to ICMP, the issue typically lies in the network path or the specific packet exchange between the BIG-IP ' s self IP and the node ' s IP. Running a tcpdump is the most effective next step because it provides a real-time packet capture of the actual monitor traffic leaving the BIG-IP and any return traffic coming back from the server. This allows the administrator to verify if the BIG-IP is actually sending the echo request, if the request is reaching the server, and if the server is indeed replying or if the reply is being dropped by an intermediate firewall or a security policy.

While other tools have their place, they are inappropriate for this specific layer 3/4 connectivity issue. A qkview is a comprehensive diagnostic file used primarily for F5 Support to analyze the entire system ' s state but is overkill for initial connectivity troubleshooting. An ssldump is used for inspecting SSL/TLS handshakes and encrypted payloads, which is irrelevant for a non-encrypted ICMP monitor. A curl command is a tool for testing HTTP/HTTPS application-level responses; it cannot be used to troubleshoot ICMP (ping) connectivity directly. By using tcpdump -ni < vlan_name > host < node_ip > , the administrator can see the ICMP " type 8 " (request) and " type 0 " (reply) packets, immediately identifying if the monitor failure is due to a " Destination Unreachable " message or a simple lack of response, thereby pinpointing the root cause in the data plane.

When a single IP address (Virtual Server) must host multiple hostnames (e.g., site1.com, site2.com) over HTTPS, the BIG-IP must be able to present the correct SSL certificate for each site during the initial handshake. This requirement is handled by a technology called Server Name Indication (SNI).

To implement this on the BIG-IP, the administrator must use a Client SSL profile because the encryption is occurring between the user (Client) and the Virtual Server. Within the Client SSL profile settings, there is a field called Server Name. By creating multiple Client SSL profiles—each with a different " Server Name " (the hostname) and its corresponding certificate—and attaching them all to the same Virtual Server, the BIG-IP can inspect the SNI extension in the client ' s " Client Hello " packet. It then selects the specific profile that matches the requested hostname.

Option A is incorrect because " Client Name " is not the standard field name used for SNI hostname matching in the profile. Options B and C refer to Server SSL profiles, which manage the connection between the BIG-IP and the backend servers. While Server SSL profiles also have a " Server Name " field (used to send SNI to a backend server), the requirement here is to provide encrypted communication for " users " accessing the virtual server, which definitively requires a Client-side SSL configuration.

SSH (Secure Shell) operates over TCP port 22 , making the TCP health monitor the appropriate and correct choice for monitoring pool members in an SSH pool. The TCP monitor establishes a basic Layer 4 connection to each pool member on the designated port, verifying that the server is reachable and actively accepting TCP connections. A successful three-way handshake confirms the pool member is available; a failure marks it down and removes it from load balancing rotation.

The remaining monitor types are inappropriate for this use case:

UDP monitor operates at Layer 4 but uses the connectionless UDP protocol, which is incompatible with SSH since SSH exclusively uses TCP as its transport.

HTTP monitor sends a Layer 7 GET request expecting an HTTP response — irrelevant for an SSH service that does not speak the HTTP protocol.

HTTPS monitor functions identically to HTTP but over TLS — again, completely misaligned with SSH traffic and port behaviour.

For application-specific SSH validation beyond basic TCP connectivity, an external monitor or custom monitor could be used; however, TCP remains the standard and correct built-in monitor for SSH pool verification within the BIG-IP platform.

The log message “Intercept exhaustion” indicates that the BIG-IP system has exhausted the available source port translations for one or more SNAT addresses. This occurs when too many concurrent client connections are being translated through a limited number of SNAT IP addresses, and all ephemeral source ports (typically ~64,000 per SNAT IP) are in use.

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

Each SNAT IP address provides a finite number of available source ports.

When the number of concurrent connections exceeds the available port space, the BIG-IP logs an Intercept exhaustion error and new connections fail.

The recommended resolution is to increase the available SNAT resources by adding additional IP addresses to the SNAT pool.

Why the other options are incorrect:

A. Increase the timeout of the SNAT addressesIncreasing timeouts may actually worsen the problem by keeping ports allocated longer, accelerating port exhaustion.

B. Remove the SNAT pool and apply SNAT AutomapSNAT Automap uses the Self IP addresses on the egress VLAN, which may not provide additional capacity and can introduce routing or design issues. This is not a direct or recommended fix for SNAT exhaustion.

C. Remove an IP address from the SNAT poolThis would reduce the number of available source ports and further exacerbate the intercept exhaustion condition.

Correct Resolution:

By adding an IP address to the SNAT pool, the BIG-IP increases the total number of available source ports, alleviating intercept exhaustion and restoring successful client connections.

Persistence overrides load balancing decisions by maintaining client-to-server affinity.

To provide encrypted communication between users and a virtual server, the BIG-IP system acts as a transparent SSL/TLS proxy. The administrative configuration required for this is a Client SSL profile.

When multiple hostnames (FQDNs) are associated with a single IP address, the system must determine which SSL certificate to present to the client during the initial TLS handshake. This is achieved using an extension of the TLS protocol called Server Name Indication (SNI).

The configuration logic is as follows:

Profile Type: The Client SSL profile is responsible for terminating the SSL connection from the client (the user) to the BIG-IP system.

The Setting: Within the Client SSL profile (under the " Advanced " view), there is a field specifically called Server Name. By entering the specific hostname (e.g., www.example.com) in this field, the BIG-IP system can match the hostname requested by the client in the ClientHello message to the correct profile.

Implementation: The administrator typically creates multiple Client SSL profiles—one for each hostname—and assigns them all to the same virtual server. One of these profiles must be designated as the Default SSL Profile for SNI to handle requests where the client does not provide a hostname or provides one that does not match any specific profile.

By using the Client SSL profile and the Server Name setting, the BIG-IP system ensures that each user receives the correct certificate for the specific site they are trying to reach, even though all sites share a single virtual server IP.

Application-specific health checks must validate application responses, which requires HTTP monitors with custom send/receive strings.

An F5 iApp is a template-driven system used to deploy complex applications by grouping all necessary BIG-IP objects (Virtual Servers, Pools, Profiles) into a single management entity. Objects created by an iApp are distinguished by their naming convention and metadata. In the provided exhibit, the Virtual Server configuration in Option A is clearly identified as an iApp-managed object through two primary indicators. First, the object resides within a sub-directory or partition ending in .app (/Common/vmware_test.app/). Second, the configuration explicitly includes the attribute app-service /Common/vmware_test.app/vmware_test, which serves as the system ' s internal pointer linking the LTM object back to the parent iApp Application Service. Furthermore, several profiles associated with this virtual server also reside within the same .app container, such as /Common/vmware_test.app/vmware_test_http.

In contrast, Options B, C, and D represent standard, manually created Virtual Servers. While they may have complex configurations (such as the APM profiles in app2_vs and app1_vs), they lack the folder-based naming hierarchy and the app-service metadata attribute that denotes iApp ownership. Standard objects like app1_vs are managed individually, whereas the objects within vmware_test.app are typically protected by " Strict Updates. " This means their configuration is controlled by the iApp ' s template logic; any manual attempt to modify these specific parameters directly via the Virtual Server menu would result in an error message stating the service must be updated via the application management interface. Identifying these objects is a critical procedural step for administrators to determine whether a configuration should be edited through the standard LTM menus or through the iApp ' s " Reconfigure " tab to ensure consistency and prevent manual changes from being overwritten by the template.