F5 Networks BIG-IP Administration Data Plane Configuration F5CAB3 Exam Questions

Answer : D

By default, BIG-IP load balancing algorithms (such as Round Robin) distribute connections evenly across all available pool members. However, persistence profiles override normal load balancing decisions by forcing subsequent connections from a client to be sent to the same pool member.

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

Persistence creates a client-to-server mapping that is honored before load balancing algorithms are applied.

When persistence is enabled, BIG-IP may repeatedly select the same pool member even if others are available.

This directly alters load balancing behavior.

Why the other options are incorrect:

A . Adding a OneConnect profileOneConnect optimizes server-side TCP connections but does not change which pool member is selected.

B . Enabling SNAT automapSNAT affects source address translation, not pool member selection.

C . Enabling a fallback host in the HTTP profileA fallback host is only used when no pool members are available.

Correct Resolution:

Adding a persistence profile alters load balancing behavior by maintaining client affinity to a specific pool member.

Answer : D

Similar to the logic required for managing multi-service backend environments, the issue described---where servers hosting multiple protocols like FTP and HTTP are experiencing uneven distribution---stems from the BIG-IP's default behavior of treating each pool independently. If the administrator uses a member-based load balancing method, the BIG-IP distributes HTTP traffic regardless of how much FTP traffic that same physical server is currently processing.

To resolve this, the administrator must utilize the Least Connections (Node) method. By switching both the HTTP and FTP pools to this algorithm, the BIG-IP begins to make load balancing decisions based on the total combined connection count for the IP address of each server. When a new HTTP request arrives, the BIG-IP checks which server has the fewest total connections (including existing FTP sessions). This prevents a server that is already busy with long-lived FTP transfers from being overwhelmed by a sudden burst of HTTP requests.

Ratio methods (Options A and C) are static and rely on the administrator manually assigning weights to servers based on their perceived capacity; they do not adapt to real-time fluctuations in traffic volume across different pools. Least Connections (Member) (Option B) remains blind to the 'cross-pool' traffic on the same hardware. Only the Node-based Least Connections approach provides the global visibility necessary to 'even out' the total resource utilization across servers supporting multiple distinct applications.

Answer : A

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

Answer : A

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.

Answer : B

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.

Answer : A

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.

Answer : D

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.