F5CAB3 Questions and Answers

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.

In F5 BIG-IP systems, an iApp is a template-driven framework used to deploy and manage application-specific configurations. When an iApp is deployed, the system creates a specialized folder or " Application Service " container to hold all the resulting Local Traffic Manager (LTM) objects, such as virtual servers, pools, and profiles. This container is visually and programmatically identified by the .app extension in its path name.

The naming convention for these objects follows a specific hierarchical structure: / < partition > / < iapp_name > .app/ < object_name > . For example, if an administrator creates an iApp named " testhttp " in the " /Common " partition, the virtual server created by that iApp would be identified in the configuration (TMSH) and the GUI as /Common/testhttp.app/testhttp. This structure allows the BIG-IP system to distinguish between manually created objects and those managed by the iApp ' s automation logic.

This identification is crucial because iApp-managed objects typically have Strict Updates enabled, which prevents administrators from making direct manual changes to the object settings outside of the iApp ' s reconfigure interface. Attempting to modify such an object directly will result in an error message stating that the application service must be updated using an application management interface. By recognizing the .app path and the repeated name within the structure, an administrator can immediately identify that the object belongs to an iApp and should be managed through the iApp ' s specific management screen rather than standard LTM configuration menus.

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

The Local Traffic > Network Map provides a single consolidated view within the BIG-IP Configuration Utility that displays the full relationship hierarchy of all application delivery objects simultaneously. This includes Virtual Servers, their associated Pools, individual Pool Members, applied iRules, profiles, and the health status of each object — all rendered in a single topological screen.

This view is specifically designed for administrators and users who need rapid situational awareness across the data plane without navigating multiple menu screens. Each object is colour-coded to reflect its current availability state (green = available, red = unavailable, yellow = degraded).

The alternative options do not satisfy all requirements:

Local Traffic > Monitors only displays health monitor configurations, not virtual server or pool member relationships.

Statistics provides performance counters and throughput data, not object relationship mapping.

Local Traffic > Virtual Servers lists virtual server configurations individually but does not provide a unified topology view inclusive of pool members and iRules in a single screen.

The Network Map is the authoritative single-pane-of-glass tool for application object visibility on BIG-IP.

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.

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.

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.

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.

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.

This scenario requires unequal load distribution based on server capacity. The newer servers must receive more connections than the older ones, while still dynamically accounting for active connection counts.

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

Weighted Least Connections (member) combines:

Connection awareness (least connections)

Administrator-defined weights (ratios) to reflect server capacity

Pool members with higher weights receive proportionally more new connections than members with lower weights, even when using the same load balancing algorithm.

Why B is correct:

Allows assigning higher weights to newer servers and lower weights to older servers

Ensures smarter traffic distribution based on both capacity and real-time load

Why the other options are incorrect:

A. Global AvailabilityUsed for disaster recovery and site failover, not intra-pool load distribution.

C. Round RobinDistributes connections evenly without considering server capacity.

D. Least Connections (member)Balances only by current connection count and does not account for differences in server performance or capacity.

Correct Resolution:

Use Weighted Least Connections (member) and assign higher weights to newer servers so they receive more traffic while protecting older servers from overload.

When multiple users share one source IP, source-address persistence fails. Cookie persistence uniquely identifies users at Layer 7 and ensures correct session handling.

Forwarding (IP) virtual servers forward traffic based on routing decisions and do not use pools or pool members.

From the exhibit, the pool contains different applications on different service ports (for example, HTTP/80, FTP/21, HTTPS/443, SSH/22). To mark pool members correctly, BIG-IP must be able to verify the actual service running on each member’s port.

In BIG-IP Administration: Data Plane Configuration, monitor behavior is described as follows:

When multiple monitors are assigned to a pool, the Availability Requirement controls how monitor results are evaluated:

At least one = the pool member is marked up if any one of the assigned monitors succeeds.

All = the pool member is marked up only if every assigned monitor succeeds.

For pools containing members with different services/ports, using All can incorrectly mark members down because monitors intended for other services will fail on the wrong port.

Why C is correct:

Assigning HTTPS, HTTP, FTP, and SSH covers the actual services shown in the pool.

Setting the Availability Requirement to at least one ensures that each pool member is considered available when its appropriate service monitor succeeds, without being forced to pass unrelated service monitors.

Why the other options are incorrect:

A / D (Availability Requirement = all): would cause members to be marked down when unrelated monitors fail (e.g., SSH monitor against an HTTP member).

B (includes ICMP): ICMP can indicate the host is reachable even if the application service is down, which does not “accurately” reflect service availability.

Therefore, the best choice is HTTPS, HTTP, FTP, and SSH with Availability Requirement of at least one health monitor.

BIG-IP provides several built-in TCP profiles optimized for different traffic patterns and network conditions. When attempting to improve general TCP performance, the recommended starting point is f5-tcp-progressive.

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

f5-tcp-progressive is designed as a balanced, general-purpose TCP optimization profile.

It dynamically adjusts TCP behavior to improve throughput and latency for most enterprise applications.

It is the recommended first-choice profile when tuning TCP performance before moving to more specialized profiles.

Why the other options are incorrect:

A. f5-tcp-legacyThis profile exists for backward compatibility and does not include modern TCP optimizations.

C. f5-tcp-mobileThis profile is optimized specifically for high-latency, lossy mobile networks and is not suitable for general-purpose environments.

D. No optionBIG-IP explicitly provides built-in TCP profiles for performance tuning; using none would forgo optimization opportunities.

Correct Resolution:

The administrator should first apply f5-tcp-progressive to evaluate potential TCP performance improvements before considering more specialized profiles.

Slow Ramp Time prevents new pool members from receiving a full share of traffic immediately, allowing applications to warm up gradually.

SNAT Automap is a common configuration that replaces the client ' s original source IP address with one of the BIG-IP ' s self IP addresses. This ensures that the backend servers send return traffic back through the BIG-IP, which is necessary for the ADC to process the traffic correctly. However, a side effect of SNAT is that the backend servers only see the BIG-IP ' s IP in their logs, losing visibility into the true identity of the client.

To resolve this while still using SNAT for routing purposes, the administrator must configure the BIG-IP to " pass " the client ' s IP address at the application layer. This is achieved by using an HTTP Profile with the Insert X-Forwarded-For setting enabled. When this profile is applied to the Virtual Server, the BIG-IP intercepts the HTTP request, adds a header (X-Forwarded-For) containing the client ' s original IP, and then forwards the modified request to the server. The backend web server can then be configured to read this header and log the original client IP instead of the BIG-IP ' s SNAT address.

Other options are incorrect for this requirement. Performance (HTTP) (Option A) is a virtual server type optimized for speed but often lacks the full Layer 7 header manipulation capabilities of a Standard Virtual Server. SNAT Pool with the client IP (Option C) is technically impossible as SNAT pools use static, pre-defined IPs. There is no such thing as an HTTP Transparent profile (Option D) in standard BIG-IP administration for this purpose. The X-Forwarded-For header insertion within the HTTP profile is the standard procedural method for maintaining client visibility in SNAT-enabled environments.

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.

F5 provides several pre-configured (built-in) TCP profiles designed to optimize traffic for different network conditions. When an administrator is looking to improve general performance but does not have a specific, narrow use case (like strictly mobile or strictly long-haul WAN), the f5-tcp-progressive profile is the recommended starting point.

The f5-tcp-progressive profile is designed as a modern, high-performance replacement for the older default TCP settings. It incorporates several advanced congestion control algorithms and buffer management techniques that allow it to adapt dynamically to varying network latencies and packet loss scenarios. Unlike f5-tcp-legacy (Option A), which uses older, less efficient stacks, the progressive profile leverages modern TMM (Traffic Management Microkernel) optimizations.

While f5-tcp-mobile (Option B) is highly effective for high-loss cellular networks and f5-tcp-wan (Option D) is optimized for high-latency long-distance links, they can sometimes be too aggressive or poorly suited for standard campus or data center environments. The f5-tcp-progressive profile acts as a " best-of-all-worlds " template that typically provides an immediate performance boost for most web applications by improving window scaling and fast-retransmit behavior. Therefore, it is the procedural " first step " in TCP performance tuning before moving to more specialized, niche profiles.

In the BIG-IP object hierarchy, a Pool Member is a child object of a Node . A pool member represents a specific IP:Port combination, while the parent node represents the underlying server IP address. When a node is disabled , all pool members that are children of that node are rendered unavailable — regardless of the individual pool member ' s own health or enabled state.

The Network Map depicted shows the pool member (192.168.212.30:80) with its Parent Node (192.168.212.30) disabled. This parent-child dependency means that even if the pool member itself is healthy and enabled, the disabled node cascades its unavailable state downward, causing the pool to have no available members and rendering VS_HTTP unresponsive to incoming connections.

The other options can be eliminated as follows:

Pool member monitor failed — the monitor status is not indicated as failed in the Network Map display.

Pool member is disabled — the pool member itself is not shown as disabled; the parent node is.

Node monitor failed — no monitor failure is indicated; the node ' s administrative state is explicitly disabled.

Understanding the node-to-member inheritance of availability state is fundamental to accurate BIG-IP traffic troubleshooting.