Refer to the Exhibit Practice Questions

The cookie remains on the client machine until manually deleted.

Why it fails: Setting the expiration to 0 defines the cookie as a session cookie. Browsers are designed to remove session cookies automatically when the browser application is closed. Therefore, it does not persist on the hard drive or remain until a manual deletion process is performed by the user.

The BIG-IP forces the client to re-authenticate immediately.

Why it fails: The persistence profile only manages server selection, not authentication. While losing persistence might cause an application error if the user is directed to a server that does not have their session, the BIG-IP itself does not trigger authentication workflows based on cookie persistence expiration.

The cookie remains valid for 3600 seconds as the default.

Why it fails: The configuration explicitly overrides any default values by setting expiration to 0. This configuration is not a time-based duration in seconds; it is a structural flag for the browser indicating the cookie should be treated as a temporary session-bound entity rather than a persistent one.

The TCP monitor is configured with an incorrect port.

Why it fails: If the monitor had an incorrect port, the health monitor would fail and the pool members would be marked as 'Down'. The exhibit shows the members are currently 'Up', proving that the TCP connection to port 80 is successfully completing the three-way handshake as expected.

The pool members are not responding to the TCP SYN packets.

Why it fails: The pool members are marked as 'Up', which indicates they are responding correctly to the TCP SYN packets. If they were failing to respond, the LTM would mark them as 'Down' based on the timeout and interval settings defined within the TCP monitor configuration.

The load balancing algorithm is set to Round Robin.

Why it fails: The load balancing algorithm determines how incoming requests are distributed, but it does not evaluate the health of the destination server. Even if the algorithm were changed, the underlying application issue causing the 503 error would persist regardless of which server is chosen for traffic.

The certificate has expired.

Why it fails: An expired certificate will trigger an 'Untrusted Certificate' or 'Expired' warning in the browser, but it will not prevent the SSL handshake from completing. The handshake failure indicates a mismatch in protocol version or cipher suite negotiation, not a certificate validation issue.

The virtual server is missing an HTTP profile.

Why it fails: The absence of an HTTP profile would prevent the BIG-IP from processing HTTP requests, but it would not cause an SSL handshake failure. SSL handshake occurs at the layer 4/5 boundary, before the HTTP profile is ever invoked to parse the application-layer headers.

The key and certificate do not match.

Why it fails: If the key and certificate did not match, the BIG-IP would typically fail to load the SSL profile during configuration or startup. If it managed to load, it would prevent the handshake, but it would show as a server-side config error rather than a protocol negotiation failure.

The monitor is missing the 'interval' and 'timeout' parameters.

Why it fails: The LTM uses system defaults for interval and timeout if not specified in the monitor configuration. While explicit values are recommended for production, the absence of these parameters will not cause the monitor to fail. The failure is due to the logic of the match, not the timing settings.

The HTTP version in the send string is causing a protocol mismatch.

Why it fails: HTTP/1.1 is standard and widely supported by all modern web servers. Specifying the version in the send string is common practice to ensure the request is handled correctly. If the server supports HTTP/1.0, it would still typically handle an HTTP/1.1 request without triggering a complete monitor failure.

The connection should be set to 'Keep-Alive' instead of 'Close'.

Why it fails: Setting the connection to 'Close' is actually a best practice for health monitors. It ensures the server terminates the connection after sending the response, preventing the BIG-IP from keeping unnecessary idle connections open to the backend servers. Changing this would not resolve the monitor match failure.

Yes, because the timeout is set to 180 seconds.

Why it fails: The timeout setting defines the lifespan of the persistence record, not the scope of its application. Even if the record is still active within the 180-second window, the 'match-across-virtuals' setting is the primary directive that governs whether that record is eligible to be applied to a different virtual server.

Yes, because source-addr persistence is global.

Why it fails: Source address persistence is not global by default. Its scope is strictly controlled by the settings within the persistence profile. Without enabling cross-virtual matching, the system maintains separate persistence tables for each virtual server, preventing the sharing of session state between different virtual server instances regardless of the client IP.

No, because the timeout must be set to indefinite.

Why it fails: The duration of the persistence record has no impact on whether it can be shared across virtual servers. Persistence duration is purely for determining when an entry should expire. The capability to share state between virtual servers is exclusively defined by the 'match-across-virtuals' configuration attribute within the persistence profile.

The virtual server is disabled.

Why it fails: A disabled virtual server would not impact the availability status of the backend pool members. The pool members would still be reported as 'up' or 'down' based on their individual health monitors, regardless of whether the virtual server object itself is enabled or disabled in the configuration.

The default route on the BIG-IP is missing.

Why it fails: If the default route were missing, the BIG-IP would likely be unable to reach the servers at all, even for ping. Because the specialist can ping the servers, the routing table is correctly configured to reach the subnet where the backend servers reside.

The SNAT pool is exhausted.

Why it fails: SNAT pool exhaustion prevents the BIG-IP from translating client source IPs, but it does not cause the health monitor to mark pool members as offline. Health monitors function independently of the data plane traffic and would continue to report the status correctly even if a SNAT pool were full.

It forces all traffic to be converted to IPv6 for backend server processing.

Why it fails: The BIG-IP does not automatically translate traffic to IPv6 for the backend servers. This setting only affects how the persistence table records client addresses. The traffic itself remains in its original IP format, ensuring compatibility with the existing backend server configuration and avoiding unexpected addressing issues.

It allows the LTM to translate IPv6 client requests to IPv4 backend servers.

Why it fails: IP translation is handled by NAT and SNAT configurations, not by persistence settings. 'map-to-ipv6' is strictly a persistence-table management function used for maintaining session affinity. It has no role in the routing or translation of actual data packets moving between the client and the backend server.

It is required for performance optimization on the BIG-IP management plane.

Why it fails: This feature is related to data plane traffic processing, specifically for maintaining persistence consistency. It has no impact on the BIG-IP management plane performance. Enabling it does not improve the speed or efficiency of system management tasks and is strictly limited to traffic-handling logic for persistence.

It improves performance for clients connecting over long-distance WAN links.

Why it fails: The 'tcp-lan-optimized' profile is optimized for low-latency, high-bandwidth networks. It does not provide the congestion control or retransmission settings necessary to handle the high latency and packet loss inherent in long-distance WAN links, which would be better served by the 'tcp-wan-optimized' profile instead.

It provides faster window scaling for high-latency connections.

Why it fails: Window scaling is generally handled by the TCP stack. The 'tcp-lan-optimized' profile actually keeps the TCP buffers smaller, which is efficient for low-latency LANs but counterproductive for high-latency connections that require larger windows to keep the 'pipe' full and maintain high throughput over distance.

It disables TCP keep-alives to save memory on the BIG-IP.

Why it fails: The profile choice does not automatically disable TCP keep-alives; that is a specific setting within the TCP profile configuration. The primary differentiator between the LAN and WAN optimization profiles is how they handle congestion control, retransmission, and buffer management, not the enabling or disabling of keep-alives.

The persistence timeout is too high, causing records to overlap across services.

Why it fails: The timeout value of 300 seconds simply determines how long the persistence record remains in the table. It does not dictate whether the record is scoped to a specific service or port; that behavior is governed by the 'match-across-services' setting within the persistence profile configuration.

The persistence profile is applied to the virtual server without a mask.

Why it fails: The mask setting in a source-address persistence profile controls the granularity of the IP matching, such as applying persistence to a subnet rather than a single host. It does not control whether persistence is restricted to a specific destination service or port; that is controlled by 'match-across-services'.

The virtual server is using a shared pool, forcing persistence across services.

Why it fails: Sharing a pool across virtual servers does not automatically force persistence across those services unless the persistence profile itself is configured to ignore the service port. Without 'match-across-services' enabled, the BIG-IP would typically treat the combination of source IP and destination port as the unique persistence key.

The HTTP profile is misconfigured and needs an iRule to function.

Why it fails: The HTTP profile configuration is correct for X-Forwarded-For insertion. No iRule is required to perform this function, as the native profile feature is optimized for this exact task. The issue lies within the backend server's log configuration, not an iRule, which would only add unnecessary processing overhead.

The virtual server is missing a Client SSL profile.

Why it fails: A Client SSL profile is for decrypting SSL traffic. It has no impact on the source IP translation behavior. If the traffic is plain HTTP on port 80 as shown in the exhibit, the presence or absence of a Client SSL profile is irrelevant to the reported source IP issue.

The pool members are in a different subnet than the virtual server.

Why it fails: Subnet placement does not force SNAT or determine the visibility of the source IP. The BIG-IP handles routing regardless of the subnet configuration. The source IP visibility is purely a function of whether SNAT is enabled or if the backend server's default gateway is the BIG-IP.

profile /Common/cookie

Why it fails: Profiles are assigned within the 'profiles' block of the virtual server configuration. Adding 'profile /Common/cookie' is syntactically incorrect for enabling persistence. Persistence profiles are defined specifically under the 'persist' setting, not within the general profiles list that includes protocol-specific settings like TCP or HTTP.

persistence-mode cookie

Why it fails: The 'persistence-mode' attribute is not a valid configuration parameter in the current BIG-IP tmsh syntax for virtual servers. Persistence must be implemented by associating a configured persistence profile object with the virtual server's 'persist' attribute, ensuring the correct profile parameters are applied during the traffic processing lifecycle.

pool /Common/pool_http persist

Why it fails: The 'persist' keyword is not a valid argument within the pool definition block. Persistence is configured at the virtual server level to define how traffic reaching that specific entry point is handled. Associating it at the pool level is not supported and would fail to produce the desired behavior.

The cookie profile mode must be set to 'rewrite'.

Why it fails: The 'insert' mode is the standard and most reliable method for cookie persistence, as it allows the BIG-IP to add its own cookie without relying on the backend server. The 'rewrite' mode is for modifying existing cookies, which is not required for basic session persistence functionality.

The HTTP profile needs to be set to 'oneconnect'.

Why it fails: OneConnect is for connection optimization and has no functional requirement or relationship with cookie persistence. Associating the two is unnecessary and does not solve the underlying issue of the persistence profile not being applied correctly to the virtual server's configuration, which is the primary cause here.

The virtual server requires an iRule to parse the cookie.

Why it fails: Cookie persistence is a built-in feature of the LTM module and does not require an iRule. The BIG-IP handles the cookie insertion and parsing automatically once the profile is correctly assigned to the virtual server. Using an iRule for this would be redundant and inefficient.

It will automatically increase the SNAT pool size.

Why it fails: The BIG-IP does not dynamically scale SNAT pool sizes. The administrator must manually define the number of addresses in the pool. If the limit is reached, the system will continue to experience connection failures until additional addresses are added or the timeout settings are lowered to reclaim ports.

It will bypass the SNAT pool and use the Self-IP.

Why it fails: The BIG-IP will not automatically failover to a Self-IP if the SNAT pool is exhausted. It strictly follows the defined SNAT configuration. If the SNAT is mandatory for the traffic flow, the exhaustion of the pool results in a total block of new sessions for that VIP.

It will rotate the source IP to the next available virtual address.

Why it fails: SNAT translation is specific to the defined SNAT pool or the configured Auto Map setting. The BIG-IP does not arbitrarily select other virtual addresses for translation. This would break session integrity and security policies, as backend servers expect traffic from the defined SNAT source range.

The monitor timeout is too low.

Why it fails: While timeout issues can cause monitor failure, the most immediate issue in this specific configuration snippet is the potential mismatch between the receive string and the server's actual response. The timeout would typically manifest as flapping or delayed detection, whereas a string mismatch results in a consistent 'Down' state.

The HTTP version is unsupported.

Why it fails: The monitor is using 'HTTP/1.1', which is standard and fully supported by all modern BIG-IP LTM versions. The issue is not the protocol version but rather the way the monitor is configured to parse the response returned by the backend server relative to the 'recv' string criteria.

The send string is missing the User-Agent header.

Why it fails: Most web servers do not strictly require a User-Agent header for a simple health check request. While some security policies might block requests missing this header, the primary failure point in standard BIG-IP monitoring logic remains the receive string validation rather than the absence of specific optional HTTP headers.

The request is dropped by the LTM.

Why it fails: The BIG-IP will not drop the request if a cookie is missing. Instead, it will load balance the request to a pool member using the configured algorithm, then insert the persistence cookie into the response as it returns to the client, ensuring subsequent requests are tracked appropriately for the session.

The LTM forces a redirect to the login page.

Why it fails: The BIG-IP LTM does not have default logic to force redirects based on missing persistence cookies. The LTM's role is simply to facilitate traffic flow and session persistence. Any business-logic-driven redirects, such as forcing a user to a login page, must be implemented via iRules or the application itself.

Persistence is permanently disabled for that session.

Why it fails: Persistence is not disabled; it is simply established for the first time by the BIG-IP. By inserting the cookie in the response, the BIG-IP creates a state for the session that will be used by the client for all following requests, ensuring persistence is active for the remainder of the session.