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

Answer : C

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.

Answer : B

The log message 'aggressive mode activated' indicates that the BIG-IP's adaptive connection management system (the 'Sweeper') has detected that the system's memory or connection limits are reaching a critical threshold. To protect the system from crashing due to memory exhaustion (OOM), the BIG-IP enters Aggressive Mode, where it begins to proactively and rapidly reap (close) idle connections to free up resources for new incoming traffic.

To mitigate this and return the system to a healthy state, the administrator needs to reduce the overall resource footprint of existing connections. Decreasing the TCP profile Idle Timeout value (Option B) is the most effective administrative action. In many environments, the default idle timeout is 300 seconds (5 minutes). If a large number of connections remain 'open' in the BIG-IP connection table long after the clients have stopped sending data, they consume valuable TMM (Traffic Management Microkernel) memory. By lowering the timeout (e.g., to 60 or 120 seconds), the BIG-IP can expire and remove these inactive entries much sooner, preventing the connection table from bloating and triggering the Sweeper's aggressive mode.

Conversely, increasing the timeout (Option C) would exacerbate the problem by keeping 'dead' connections in memory even longer. Connection Mirroring (Option D) actually increases memory usage because every connection must be duplicated on the standby peer. An active-active configuration (Option A) might spread the load but does not address the underlying resource management issue on the individual units. Therefore, tightening the idle timers is the standard procedural fix for memory pressure caused by high connection volumes.

Answer : A

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

Answer : A

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

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 : C

A 400 Bad Request response from an HTTP/1.1 web server is a definitive indicator that the HTTP request sent by the health monitor is missing a required Host header. In HTTP/1.1, the Host header is mandatory per RFC 7230. Web servers --- particularly those hosting named virtual hosts such as www.f5.com --- will reject any HTTP/1.1 request that omits the Host header, returning a 400 error, which the BIG-IP monitor interprets as a failed health check, marking all members DOWN.

The correct Send string must include:

The GET request line with HTTP/1.1 protocol declaration

A \r\n (carriage return + line feed) after the request line

The Host: www.f5.com header to satisfy HTTP/1.1 requirements

A \r\n after the Host header

Connection: Close header to instruct the server to close the connection after responding

A final \r\n\r\n to properly terminate the HTTP request headers

Only option C satisfies all these requirements with the correct syntax and Host header inclusion.

Option D (the current configured string) omits the Host header entirely --- the root cause of the 400 error. Options A and B are structurally incomplete or syntactically malformed.

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.