F5-CTS-LTM Flashcards — Free F5 Certified Technology Specialist: BIG-IP LTM Study Cards

The cipher suite compatibility between the BIG-IP and the pool member. / The 'Receive String' configured in the HTTPS monitor.

When HTTPS monitors fail despite successful ICMP responses, the issue usually involves TLS handshake failures or application-layer response mismatches. Checking the cipher compatibility ensures the BIG-IP and server can establish a secure connection. Verifying the receive string is vital because a 200 OK status code does not guarantee the application is actually functional; the BIG-IP must receive the expected content within the response body to confirm service health.

tmsh show ltm pool

The 'tmsh show ltm pool' command is the primary tool for administrators to inspect the current state of load-balanced resources. It provides immediate visibility into member health, active connections, and traffic statistics. Being proficient with this command is essential for daily monitoring and rapid incident response, as it allows operators to quickly identify overloaded nodes or servers that have unexpectedly failed their health checks during production operations.

The cookie is removed when the browser session ends.

The 'expiration 0' setting in the cookie persistence profile indicates that the persistence cookie is a session cookie, which persists as long as the browser remains open. Once the browser is closed, the cookie is deleted. Understanding how session versus persistent cookies function is vital for LTM administrators to manage user experience and ensure that session stickiness is maintained correctly across different browser behaviors and application requirements.

Ratio

When pool members have varying hardware specs, simple algorithms like Round Robin perform poorly because they send equal traffic to all servers regardless of their ability to handle it. 'Ratio' load balancing allows the administrator to assign a weight to each server, ensuring more powerful servers receive a higher proportion of traffic, which optimizes overall application performance and prevents the saturation of weaker servers.

HTTP Profile

The HTTP profile is required for any Layer 7 processing. Without an HTTP profile, the BIG-IP treats traffic as raw TCP streams. By enabling the HTTP profile, the LTM gains the ability to parse HTTP requests and responses, allowing for features like header manipulation, cookie persistence, and content switching, which are standard requirements for modern web application delivery controllers.

To enable TCP connection reuse to backend servers.

The OneConnect profile enables connection pooling between the BIG-IP and the backend servers. By keeping backend connections open even after a client request is fulfilled, the BIG-IP can reuse these existing connections for subsequent requests. This reduces the overhead associated with the TCP three-way handshake for every new request, significantly lowering the CPU utilization on backend servers and improving overall latency.

The application-level health check is missing or insufficient.

A TCP monitor only confirms that the port is open and the operating system is accepting connections, not that the application service is operational. In this case, the web server process might have crashed or be misconfigured, leading to an HTTP 503 response. The LTM treats the server as 'Up' because the TCP handshake succeeds, failing to detect the application-level failure requiring an HTTP monitor.

Fastest

The 'Fastest' load balancing algorithm tracks the time it takes for a server to respond to a request. The BIG-IP uses this metric to dynamically direct new connections to the pool member that currently provides the lowest latency. This is highly effective in environments where server performance varies due to heterogeneous hardware or fluctuating application loads.

The cipher string excludes TLS 1.0, which some clients require.

The cipher string 'DEFAULT:!SSLv3:!TLSv1' explicitly disables TLS 1.0. Many legacy clients still require TLS 1.0 to establish a handshake. By excluding it, the BIG-IP is rejecting any connection attempt from clients that do not support TLS 1.1 or higher. This is a common configuration error when trying to harden security without auditing the client base's compatibility first.

The 'receive' string does not account for the entire HTTP response body.

The health monitor configuration requires exact string matching for the 'receive' field. If the server returns extra whitespace, headers, or different formatting than expected by the BIG-IP, the match will fail. The monitor configuration in the exhibit is correct in syntax, but the 'receive' string must match exactly the data found in the raw response body, which often differs from how a terminal-based curl output displays information.

No, because match-across-virtuals is disabled.

The persistence profile has 'match-across-virtuals' set to 'disabled'. Because this attribute is disabled, the BIG-IP will not share persistence information between Virtual Server A and Virtual Server B. When the user lands on Virtual Server B, the system will initiate a new load balancing decision instead of respecting the persistence session established on the first virtual server, which is crucial for managing multi-virtual server architectures.

Simplified management by grouping related LTM objects into a single logical entity. / Reduction of configuration errors through enforced deployment standardization.

iApp templates provide a structured, simplified interface for deploying complex applications. By abstracting the creation of multiple objects (virtual servers, pools, profiles, iRules) into a single deployment unit, they reduce the risk of human error and configuration drift. These templates are essential for maintaining consistency across large environments and ensuring that best practices are followed during every configuration step.

Least Connections (member)

The 'Least Connections' method is the correct choice for load balancing based on active session counts. This algorithm dynamically tracks the current load on each server and directs new requests to the member with the fewest active connections. It is essential for application environments where individual requests vary significantly in duration or resource consumption, preventing any single server from becoming overwhelmed.

The health monitor is misconfigured or the service is down.

The pool status is 'offline' and 'children are down' despite servers being reachable via ping. This indicates the health monitor configured on the pool is failing, likely because the specific service (e.g., HTTP on port 80) is not responding or the monitor is misconfigured. Ping only tests network layer connectivity, whereas LTM monitors test application-layer availability, which is the standard for determining if a server can actually process traffic.

To reduce administrative overhead for simple configurations.

SNAT Automap is the simplest way to manage source translation because it automatically uses the BIG-IP's floating self-IP address. It is ideal for environments where a dedicated pool of IP addresses is not required. This reduces administrative complexity and configuration overhead, which is beneficial for smaller deployments or scenarios where the backend servers only need to see the BIG-IP as the source of traffic.

Traffic is balanced exclusively between the single remaining priority 10 member and the two priority 5 members.

Priority Group Activation directs traffic to the highest available priority group until the number of active members in that group drops below the specified minimum active members threshold. When one priority 10 member fails, one remains active, which is below the minimum threshold of 2, triggering activation of the lower priority group while keeping the remaining priority 10 member active.

Persistence is enabled, causing the BIG-IP to bypass the load balancing algorithm for existing sessions.

The 'Least Connections' method is highly dependent on the accuracy of the connection table. If persistence is configured, the BIG-IP will ignore the least connections algorithm for any request that is part of an existing session. This is a frequent point of confusion where administrators expect even distribution but see skewed results because users are 'stuck' to specific servers due to their persistence records.

It creates a unified persistence table for both IPv4 and IPv6 clients.

In dual-stack environments, both IPv4 and IPv6 clients might access the same application. The 'map-to-ipv6' feature ensures that IPv4 addresses are normalized into an IPv6-compatible format within the persistence table. This creates a unified persistence context, allowing the BIG-IP to correctly track and persist traffic from both address types to the same backend server, maintaining session consistency across different network protocols.

An iRule in the 'HTTP_RESPONSE' event with 'HTTP::header remove Server'.

An iRule using the 'HTTP_RESPONSE' event is the most flexible way to modify headers. Using the 'HTTP::header remove' command, an administrator can strip sensitive version information from the 'Server' header before the response reaches the client. This is a common security hardening task that prevents potential attackers from fingerprinting the backend server version and identifying known vulnerabilities associated with that specific platform.