F5 301B BIG-IP LTM common mistakes
F5 301B BIG-IP LTM · Understand the traps and how to avoid them.
Reading a virtual server's destination as the address the client actually connects to, and therefore mis-predicting which virtual server will match a given flow when several share a port.
Candidates treat the destination field as a plain listener address and forget that address, port, and network mask together form the match tuple, and that the most specific match wins regardless of configuration order. They also overlook that a wildcard destination (0.0.0.0:443) will capture traffic intended for a more specific address the candidate assumed was separate.
What to do instead
For any scenario, list every virtual server on the port with its destination tuple, then rank by specificity: exact host address beats subnet, subnet beats wildcard. Practice predicting matches for flows like 10.1.2.3:443 against 0.0.0.0:443, 10.1.0.0/16:443, and 10.1.2.3:443 to internalize the ordering, and remember that a virtual server with no pool drops or rejects rather than passing traffic through.
Assuming a pool member marked down by a monitor still receives new connections because it is listed as available in the configuration or because a persistence entry points to it.
Candidates conflate administrative state with monitor-driven state and forget that a failed monitor removes the member from load-balancing selection. They also assume persistence overrides health, when in practice a persisted connection to a down member is typically rebalanced to a healthy member unless the persistence profile is configured to allow it.
What to do instead
Memorize the state model: a member must be enabled and monitor-up to receive new connections; persistence records are only honored if the target is still eligible. When troubleshooting, check member availability (not just enable/disable) and the monitor status, and remember that a node with no monitor is assumed up, which is a frequent source of silent failures.
Choosing a load-balancing method by name without reasoning about how it distributes: expecting round robin to account for member capacity, or expecting least connections to ignore member weights and ratios.
The method names sound self-explanatory, so candidates skip the mechanics. They miss that ratio and priority settings alter effective distribution for most methods, that least connections is connection-count based rather than throughput based, and that observed-member and predictive-member methods use dynamic performance metrics rather than static counts.
What to do instead
For each method, state the selection input (static order, connection count, ratio-weighted count, dynamic performance score) and whether ratio and priority modify it. Work a small example: three members with ratios 1:2:3 under round robin versus least connections, and predict the split. Choose methods by traffic shape, not by familiarity.
Configuring a source-address persistence profile and expecting all clients behind one NAT device to be persisted independently, or expecting persistence to survive when the pool changes without checking the persistence entry's pool binding.
Source address persistence keys on the client IP as seen by the BIG-IP, which for NATed clients is the NAT address, so many users collapse onto one member. Candidates also forget that persistence records are tied to a pool and that a new pool or a changed member set can invalidate them.
What to do instead
When clients share a source address, select a persistence method that includes more of the flow (for example a cookie or SSL session ID for HTTP/HTTPS) or enable a persistence profile that maps by additional attributes. Always verify which pool the persistence profile applies to and test behavior after pool membership changes.
Writing an iRule that references an event or command in the wrong context, such as calling a payload-inspection command in CLIENT_ACCEPTED or expecting HTTP commands to work on a non-HTTP virtual server.
Candidates learn command names without learning which events fire for which protocol and at which point in the connection lifecycle. They also assume an iRule runs once per request when many events fire per connection and per request, causing repeated or missed actions.
What to do instead
Map each command to its valid events before writing logic: HTTP commands belong in HTTP_REQUEST or HTTP_RESPONSE, TCP payload commands in CLIENT_DATA or SERVER_DATA, and connection setup decisions in CLIENT_ACCEPTED. Trace a single request through the event sequence and confirm the virtual server's profile set supports the protocol the iRule assumes.
Configuring client certificate verification but leaving the trust chain or the certificate-request behavior incomplete, so clients are never prompted or all certificates are rejected regardless of validity.
Candidates set the client certificate requirement without attaching a CA bundle the BIG-IP trusts, or they confuse requesting a certificate with requiring one, and they do not account for the difference between verifying the chain and checking revocation or the subject.
What to do instead
For mutual TLS, confirm three things: the Client SSL profile requests the certificate, a trusted CA certificate or bundle is associated so the chain can be validated, and any additional checks (subject, expiry, revocation) are explicitly configured. Test with a certificate signed by an untrusted CA to confirm rejection and with a valid one to confirm acceptance.
Diagnosing a monitor failure by changing the monitor interval or timeout instead of confirming the probe's send string, receive string, and destination address and port actually match what the service returns.
Interval and timeout changes only affect timing; candidates reach for them because the failure appears as intermittent flapping. The real cause is usually a receive string that no longer matches the response body, a probe sent to a port the service does not answer on, or an address the member does not own.
What to do instead
Reproduce the probe manually against the member and compare byte-for-byte with the configured send and receive strings, including case and whitespace. Verify the monitor's destination address and port (or the inherited member address and port) and confirm the service answers on that exact socket before touching timers.
Assuming SSL termination happens automatically once a Client SSL profile is attached, without checking that the server-side profile is absent or that the pool members expect plaintext versus re-encrypted traffic.
Candidates attach the client profile and stop, then are surprised when the backend receives TLS handshake bytes or when the client receives a certificate for the wrong name. They also overlook that the server SSL profile, not the client one, governs re-encryption to members.
What to do instead
Decide the termination model explicitly: client-side TLS only (no server SSL profile, members speak plaintext) versus full proxy with re-encryption (server SSL profile attached). Verify the certificate and key on the client profile match the requested hostname, and confirm the member's listening protocol matches what the BIG-IP will send.
Treating a pool's configured members as the set that will actually serve traffic, ignoring priority groups and fallback behavior when higher-priority members are unavailable.
Priority groups are easy to configure and easy to forget. Candidates test with all members healthy, see even distribution, and then misread failover behavior because the lower-priority group only activates when the higher group is fully unavailable.
What to do instead
Before predicting distribution, list members by priority group and state the rule: traffic goes to the highest available priority group, and lower groups receive traffic only when all higher groups are down (subject to the pool's fallback setting). Test by disabling the high-priority members and observing the shift.
Troubleshooting a connection failure by reading only the virtual server statistics and concluding the virtual server is at fault, without checking the profile stack, the pool member state, and the actual reset or timeout source.
Statistics show counters, not causes. Candidates see zero connections on a virtual server and assume a configuration error, when the traffic never arrived, was rejected by a listener or firewall, or was terminated by an idle timeout in a profile. They also miss that a reset can originate from the member rather than the BIG-IP.
What to do instead
Work the path in order: confirm the packet reaches the virtual server (connection counters increment), confirm a pool member is selected (member counters), then confirm the response returns. Check idle timeouts and protocol profiles for premature resets, and use connection-level logging to see which side closed the flow before changing configuration.