F5 Networks BIG-IP Administration Support and Troubleshooting F5CAB5 Exam Questions

Page: 1 / 14
Total 65 questions
Question 1

A BIG-IP Administrator is receiving intermittent reports from users that SSL connections to the BIG-IP device are failing. Upon checking the log files, the administrator notices: SSL transaction (TPS) rate limit reached. Reviewing stats shows a max of 1200 client-side SSL TPS and 800 server-side SSL TPS. What is the minimum SSL license limit capacity required to handle this peak?



Answer : D

Troubleshooting SSL connection resets often involves verifying license limits against actual resource utilization. F5 devices use a 'Transactions Per Second' (TPS) license to control the amount of SSL processing the device can handle. The log entry SSL transaction (TPS) rate limit reached is a clear indicator that the traffic volume has exceeded the licensed capacity. When determining the necessary license level, it is important to know that F5 primarily licenses and limits the 'Client-side' SSL TPS---which represents the encrypted connections between the users and the virtual servers. In this specific scenario, the peak demand reached 1200 client-side transactions per second. Although there were also 800 server-side transactions (re-encryption from the BIG-IP to the pool), these typically do not count against the primary TPS license limit in the same manner. Therefore, to ensure that the virtual server works as expected during peak load, the administrator must upgrade the license to at least 1200 TPS. This troubleshooting process links system log errors to license-enforced resource constraints.


Question 2

A gateway_icmp health monitor is configured on a pool. The BIG-IP Administrator is investigating why the pool is reported as down while the server is online. Other pools with servers in the same subnet are correctly monitored.

What can cause this behavior? (Choose one answer)



Answer : C

A gateway_icmp monitor checks basic network reachability by sending ICMP echo requests (pings) to the pool member or its gateway. If the pool is markedDOWNwhile the server is confirmed to be online, the most likely cause is thatICMP traffic is being blocked.

Ahost-based firewall active on the server (Option C)can block ICMP echo requests or replies, preventing BIG-IP from receiving a successful response to the health check. This results in the monitor failing and the pool member being marked down, even though the server and application are otherwise functioning normally. This explanation is consistent with the scenario where other servers in the same subnet work correctly, indicating that routing and BIG-IP configuration are not the issue.

The other options are unrelated to ICMP monitoring. Logged-in users (Option A), missing patches (Option B), and stopped HTTP services (Option D) do not affect a gateway_icmp monitor. BIG-IP troubleshooting best practices recommend verifying ICMP reachability and firewall policies when diagnosing ICMP-based monitor failures.


Question 3

Refer to the exhibit.

The image shows the status of a virtual server namedapplication_vsin the BIG-IP Configuration Utility.

What is the cause of the status shown? (Choose two answers)



Answer : A, C

The exhibit shows the virtual serverapplication_vswith a status indicating it isoffline but enabled. In BIG-IP terminology, this status means the virtual server itself is administratively enabled, but it is unable to pass traffic becauseno usable pool members are available.

Two common and documented causes for this condition are:

Pool member(s) administratively disabled (Option A):When all pool members are administratively disabled, BIG-IP removes them from load-balancing decisions. Even though the virtual server remains enabled, it has no available pool members to send traffic to, resulting in an offline status.

Node(s) administratively disabled (Option C):Pool members inherit the status of their parent nodes. If a node is administratively disabled, all associated pool members are also marked unavailable. This condition causes the virtual server to show as offline, even though the virtual server configuration itself is correct.

The other options are incorrect:

Forced offline pool members (Option B)result in a different operational intent and are explicitly set for maintenance scenarios.

Virtual server administratively disabled (Option D)would show the virtual server as disabled, not enabled/offline.

This behavior is consistent with BIG-IP traffic management logic and is commonly verified by reviewingpool and node availability stateswhen diagnosing virtual server availability issues.


Question 4

A BIG-IP Administrator adds new Pool Members into an existing, highly utilized pool. Soon after, there are reports that the application is failing to load for some users. What pool level setting should the BIG-IP Administrator check?



Answer : A

When adding new members to an active, high-traffic pool, the Slow Ramp Time setting is critical for maintaining application stability.

Mechanism: The Slow Ramp Time feature (located in the Pool properties) allows the BIG-IP system to gradually increase the number of connection requests sent to a newly added or recently enabled pool member.

The Issue: In a highly utilized pool, if Slow Ramp Time is set to 0 (the default), the BIG-IP immediately begins sending a proportional share of traffic to the new members. If the application requires a 'warm-up' period (e.g., to build local caches or establish database connection pools), the sudden influx of traffic can overwhelm the new server, causing it to drop requests or fail to load content for users.

Recommendation: F5 recommends setting a non-zero Slow Ramp Time (measured in seconds) to allow the new member to scale up its processing capacity incrementally.


Question 5

Refer to the exhibit.

The BIG-IP Administrator has modified an iRule on one device of an HA pair. The BIG-IP Administrator notices there is NO traffic on the BIG-IP device in which they are logged into. What should the BIG-IP Administrator do to verify if the iRule works correctly?



Answer : D

Based on the provided exhibits, the BIG-IP device is currently in a Standby state ('ONLINE (STANDBY)') and has a sync status of 'Changes Pending' (Yellow icon).

Understanding Device State and Traffic: In an Active/Standby High Availability (HA) pair, traffic is processed by the Active device. The exhibit confirms the administrator is logged into the Standby device, which explains why there is 'NO traffic' currently observed on this specific unit.

Configuration Synchronization (ConfigSync): When an administrator modifies a local object, such as an iRule, on one member of a device group, the changes must be synchronized to the other members to ensure consistency. The 'Changes Pending' status indicates that the local configuration on this device is newer than the configuration on other group members.

Push vs. Pull: * Push: Sends the configuration from the current device to the other members of the device group.

Pull: Overwrites the current device's configuration with the configuration from another member of the group.

Resolving the Scenario: Since the administrator modified the iRule on 'this device,' they must Push the configuration to the group so the Active device receives the updated iRule. To verify the iRule works, the administrator can then monitor the traffic on the Active device or initiate a manual failover to make 'this device' Active, allowing it to process traffic with the new iRule.

Option D is the correct administrative workflow: synchronize the changes to the group (Push) and then monitor the traffic flow to validate the new logic.


Question 6

Pool /Common/testpool member /Common/10.120.0.5:8090 monitor status down. [ /Common/http: up, /Common/http2: down; last error: ] [ was up for lhr:0min:43sec ]

Why is this pool member being marked down?



Answer : C

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.


Question 7

A BIG-IP Administrator configured the following virtual server to pass traffic on all addresses and ports. After configuration is completed, the BIG-IP Administrator notices that the virtual server is unable to pass traffic.

ltm virtual forwarding_any_vs {

destination 0.0.0.0:any

ip-forward

mask 255.255.255.255

profiles {

fastL4 { }

}

serverssl-use-sni disabled

source 0.0.0.0/0

translate-address disabled

translate-port disabled

}

Which part of the configuration is the cause of the issue? (Choose one answer)



Answer : B

This virtual server is intended to function as aforwarding (IP-forwarding) virtual server, which is commonly used for routing or firewall-style deployments where BIG-IP forwards traffic transparently without load balancing or address translation. For a forwarding virtual server to match and passall traffic, the destination must be configured as 0.0.0.0:anywith a mask of 0.0.0.0, not 255.255.255.255.

The configured mask 255.255.255.255 represents a/32 host mask, which restricts the virtual server to matching traffic destined only for the exact IP address 0.0.0.0. Since 0.0.0.0 is not a valid routable destination for normal traffic, no packets will ever match the virtual server, causing it to pass no traffic at all.

This is a well-documented BIG-IP behavior:

destination 0.0.0.0:any

mask 0.0.0.0

together define acatch-all forwarding virtual server.

The destination itself (Option A) is correct for a forwarding VS, and disabling address translation (Option C) is expected and required for IP-forwarding mode. Therefore, the incorrect subnet mask is the sole reason the virtual server is not functioning as expected.


Page:    1 / 14   
Total 65 questions