Free Practice Questions for F5 F5CAB5 Exam

In an HTTPS session, the application-layer payload—including HTTP request headers, response headers, cookies, and body content—is encrypted using SSL/TLS. Without decrypting the traffic (for example, without SSL offloading on BIG-IP or access to the private keys), a packet capture cannot reveal any HTTP-level details.

However,network-layer and transport-layer information remains visible, even when encryption is used. This includes source and destination IP addresses, source and destination ports, TCP flags, sequence numbers, and TLS handshake metadata. Therefore, thesource IP address (Option B)is visible in a packet capture of HTTPS traffic without decryption.

Options A, C, and D are incorrect because HTTP headers and cookies are part of the encrypted payload once HTTPS is established. BIG-IP troubleshooting documentation emphasizes this distinction when analyzing encrypted traffic flows using tcpdump, as administrators must rely on IP, port, and timing information unless SSL inspection or decryption is configured.

To utilize the F5 iHealth service, a BIG-IP Administrator must generate a diagnostic snapshot of the system known as a QKView file.

GUI Path: In the BIG-IP Configuration Utility (GUI), the QKView generation tool is located under System > Support.

Process: On the Support page, the user selects the "New Support Snapshot" button. From there, they ensure "QKView" is selected. Once the BIG-IP finishes collecting the data (which includes logs, configuration, and hardware statistics), the user can download the resulting .qkview file directly to their local machine.

iHealth Integration: This file is then uploaded to ihealth.f5.com. The Upgrade Advisor tool within iHealth specifically parses this QKView to check the current configuration against known bugs, hardware limitations, or syntax changes in the target TMOS version.

Evaluation of Other Options:

System > Configuration (Option B): This section contains general system settings like DNS, NTP, and SNMP, but does not contain diagnostic tools.

System > Software Management (Option C): This is where new TMOS images (.iso files) are uploaded and installed, but it is not used for generating diagnostic reports.

System > Archives (Option D): This is used to create and manage UCS (User Configuration Set) files, which are full system backups. While UCS files contain configuration, they do not contain the deep diagnostic logs and hardware stats required by iHealth for an Upgrade Advisor analysis.

These log messages indicate that the BIG-IP system is under significant resource pressure and has activated its Adaptive Connection Management.

Global Eviction Policy: The message Aggressive mode ... activated (global memory) confirms that the system has reached a memory utilization threshold that triggers the eviction policy. This happens because TMM (the data plane) is running low on available memory pages.

Sweeper/Reaping: Once in "Aggressive mode," the BIG-IP "sweeper" starts reaping (terminating) connections to free up memory. The log Connections killed confirms this is occurring.

Impact: The system does not drop all connections; it targets connections based on the eviction policy (e.g., oldest connections or those exceeding limits) to bring memory usage back to safe levels. Thus, some connections will be dropped (Option A), and the cause is TMM memory exhaustion (Option C).

The failure to connect is caused by a restrictive Source Address filter configured on the Virtual Server.

Source Address Filtering: In the BIG-IP system, the Source Address field on a Virtual Server acts as an implicit Access Control List (ACL). Only traffic originating from a client IP address that matches the specified network range will be accepted and processed by the Virtual Server.

Analyzing the Exhibit: The provided configuration for vs_http shows the Source Address is set to 10.128.10.0/24. This means the Virtual Server will only accept connections from the subnet ranging from 10.128.10.1 to 10.128.10.254.

Identifying the Conflict: The user trying to connect has the IP address 192.168.162.70. Since 192.168.162.70 does not fall within the allowed 10.128.10.0/24 range, the BIG-IP system will not match this traffic to the Virtual Server, effectively blocking the connection attempt.

Evaluation of Other Options:

All Ports (Option A): Configuring a Virtual Server for "All Ports" (port 0) allows it to handle traffic for any destination port, which would not block a standard HTTP application.

Destination Address (Option B): The destination address 192.168.162.80 is the Virtual IP (VIP) users should be connecting to; this is a standard configuration and not the cause of the failure for a user reaching out to it.

Standard Type (Option C): A "Standard" Virtual Server is the most common type used for HTTP applications as it allows for Layer 7 profiles and full proxy capabilities.

When traffic "stabilizes after a few minutes" following a failover, it points to a network-level performance issue involving ARP cache on upstream routers and switches. Each BIG-IP interface has a unique hardware MAC address. During failover, the Standby device takes over the floating IP address, but the upstream switch still associates that IP with the MAC of the now-offline device. Traffic is lost until the switch learns the new MAC or its ARP entry expires. "MAC Masquerading" solves this by creating a shared, virtual MAC address for the floating traffic group. This virtual MAC is used by whichever device is currently active. Because the MAC address for the virtual server IP never changes from the perspective of the network, the upstream devices do not need to update their ARP tables. This troubleshooting solution eliminates the delay associated with failover, providing a seamless transition and ensuring that application traffic flow is not disrupted when the BIG-IP HA state changes.

The BIG-IP system uses the audit log to track administrative actions and configuration changes.

Audit Logging Functionality: When a user modifies the configuration via the Configuration Utility (GUI), the Traffic Management Shell (tmsh), or iControl, the system records the event in the audit log. This includes the name of the user who made the change, the timestamp, and the specific command or object that was modified.

Log Location: The audit log is stored at /var/log/audit.

Evaluation of Other Options:

/var/log/messages (Option A) contains general system and kernel messages but is not the primary source for configuration change details.

/var/log/secure (Option B) primarily logs authentication and authorization attempts (logins and logouts).

/var/log/user.log (Option D) is a generic Linux log file for user-level applications and does not track BIG-IP LTM configuration changes.

The End User Diagnostics (EUD) utility is a hardware-level testing suite used to verify the integrity of the physical components of a BIG-IP appliance.

Access Requirements: Because the EUD must be run while the TMOS operating system is not loaded (typically when the device cannot boot or requires hardware validation), it cannot be accessed via network-based interfaces like the Management Port or VLANs.

Console Connection: The administrator must connect a terminal to the physical Console Port (using a serial cable) to interact with the boot menu.

Execution Process: Upon restarting the appliance, the administrator must intercept the boot process at the GRUB menu and select the "End User Diagnostics" option. All output and menu selections are then handled through the serial console session.

This log entry indicates that multiple monitors are assigned to the pool member, and the member is failing one of them.

Understanding Monitor Logic: By default, if multiple monitors are assigned to a pool or pool member without a "Minimum To Up" (Availability Requirement) setting, the system requires all monitors to pass for the member to be marked "Up".

Analyzing the Log: The log clearly states: [ /Common/http: up, /Common/http2: down; ... ]. This means the standard HTTP monitor is successful, indicating the member is serving HTTP traffic, but the http2 monitor has failed.

Conclusion: Since the http monitor is "up" but the member as a whole is "down," we can conclude the member is successfully responding to standard HTTP requests but not HTTP2 requests. Therefore, the member is currently only serving standard HTTP traffic.

To successfully performSSL offload and re-encryptionon a BIG-IP system, the virtual server must be configured withboth a Client SSL profile and a Server SSL profile. The Client SSL profile enables BIG-IP to decrypt inbound HTTPS traffic from clients, while the Server SSL profile is required tore-encrypt traffic before forwarding it to the pool members.

From the exhibit, the virtual server has aClient SSL profile configured, which allows BIG-IP to accept HTTPS connections from clients. However, there isno Server SSL profile attached, meaning BIG-IP attempts to sendunencrypted HTTP trafficto pool members listening on HTTPS (port 443). This protocol mismatch causes the server-side SSL handshake to fail, resulting in users being unable to connect to the application.

This behavior is well documented in BIG-IP SSL troubleshooting guides: when backend servers expect HTTPS, a Server SSL profile is mandatory to establish a secure connection from BIG-IP to the pool members.

The other options are incorrect:

Removing the Client SSL profile (Option A) would break client-side HTTPS.

The server-side TCP profile (Option B) is unrelated to SSL encryption.

Forward Proxy (Option C) is only used for outbound SSL inspection scenarios.

Therefore, configuring anSSL Profile (Server)is the correct and required solution.