F5-CSE common mistakes
F5-CSE · Understand the traps and how to avoid them.
Treating a virtual server's destination address as the address the pool members receive, and predicting that nodes see traffic addressed to the VIP rather than to themselves.
Candidates learn the VIP as the 'front door' and stop reasoning about the packet's journey after the virtual server accepts it; the default SNAT behaviour (source address translated to a self IP, destination rewritten to the member) is easy to gloss over because it is invisible in the configuration.
What to do instead
Trace one connection end to end before answering: client to VIP (destination rewritten to member, source translated unless SNAT is disabled or a SNAT pool/automap is applied), member to client (return traffic must reach a self IP so the BIG-IP can reverse the translation). Practise stating which address appears in the member's logs and which appears to the client.
Assuming a pool member is used whenever it exists, without checking whether its node is marked down, whether the member is disabled/forced offline, or whether a monitor is actually assigned.
The GUI shows green/red icons that candidates read as 'configured', and a pool with no monitor marks members up unconditionally, so a broken service still receives traffic; conversely a monitor inherited from a template can mark a healthy member down.
What to do instead
Memorise the member state hierarchy (monitor down, session disabled, forced offline, node down) and the rule that no monitor means always up. When diagnosing, check monitor assignment at pool, member, and template level, and check the node object as well as the member.
Choosing a load balancing method by name rather than by behaviour - for example expecting round robin to account for connection counts, or expecting least connections to consider member capacity.
Method names sound self-descriptive, and the distinctions that matter (least connections with a ratio, observed/ predictive members, weighted least connections, fastest node, dynamic ratio) are rarely encountered in day-to-day work.
What to do instead
Build a one-line behaviour card per method: what counter it uses, whether it honours ratios or priorities, and how it behaves when a member is added or fails. Learn that priority groups only activate when all higher-priority members are down, and that least connections uses a snapshot rather than live counts.
Confusing a persistence profile with a load balancing method, and expecting persistence to override a member that has failed its monitor.
Both influence member selection, so candidates merge them; in practice persistence selects a member first and load balancing only applies when no persistence record exists or it has expired.
What to do instead
State the order explicitly: persistence lookup, then load balancing if no record, then monitor state as the gate that removes a member from selection regardless of persistence. Learn the common persistence types (source address, cookie, SSL session ID, destination address) and their timeouts, plus the meaning of match-across-services and match-across-virtual-servers.
Assuming a health monitor succeeds because the service is running, ignoring that the monitor's send string, receive string, interval, timeout, and transparent/NOT settings determine the verdict.
Candidates reason about application health rather than monitor mechanics, so they miss cases where the receive string never appears, the timeout is shorter than the server's response time, or the monitor runs over the wrong protocol or port.
What to do instead
For any monitor question, identify the protocol, the exact probe, the expected response, and the timing. Remember interval x retries sets how long a failure takes to register, and that a timeout counts as a failure. Practise reading a monitor definition and predicting its verdict against a described server response.
Treating an iRule as a script that runs once per connection, rather than as event-driven code that can fire multiple times (HTTP_REQUEST per request, LB_SELECTED per selection) with specific command availability per event.
General-purpose programming intuition suggests linear execution; iRules instead run in the context of a connection and event, and commands valid in one event are illegal in another.
What to do instead
Learn the event order for the common flows (CLIENT_ACCEPTED, HTTP_REQUEST, LB_SELECTED, SERVER_CONNECTED, HTTP_RESPONSE, CLIENT_CLOSED) and which commands belong to each. When reading an iRule, ask which event it is in and whether the command is permitted there, and remember that an unhandled event simply passes traffic through.
Believing SSL offload means the BIG-IP only decrypts, and ignoring the second leg - re-encryption to the pool member, SNI on the client side, and which certificate is actually presented.
'Offload' suggests the backend is always plaintext, but a client SSL profile and a server SSL profile are independent, and the certificate chosen for the client depends on SNI matching and profile inheritance.
What to do instead
Separate the two profiles in every answer: client SSL profile (what the client sees, which cert/key, SNI, cipher and TLS version settings) and server SSL profile (whether traffic to members is re-encrypted). Check certificate chain completeness and expiry as routine causes of client-side handshake failures.
Assuming a configuration change is live on both devices of a device group, or that a sync pushes everything including device-specific settings.
Sync direction, config sync vs. failover, and the fact that some objects (management IP, device-specific network settings) are not synchronised are subtle; candidates also forget that a change must be saved before it can sync.
What to do instead
Distinguish config sync (pushing configuration to peers) from failover (moving traffic), and remember the sync direction and that the change must be saved first. Know which settings are device-specific and therefore never synced, and check sync status rather than assuming a green light means identical configuration.
Answering failover questions by naming the active/standby state without connecting it to the failure detection mechanism (network failover, heartbeat, probe) and the traffic-group floating addresses.
High availability is learned as a diagram of two boxes, so the mechanism that decides a peer is dead - and the fact that floating self IPs and virtual addresses move with the traffic group - is not linked to observable behaviour.
What to do instead
Explain failover as: peer unreachable via heartbeat/network failover for the configured timeout, traffic group becomes active on the surviving device, floating addresses move. Learn the difference between active/standby and active/active, and what happens to existing connections (they are not preserved unless connection mirroring is configured).
Treating access and security controls (management access, administrative partitions, user roles, network firewall or AFM-style policies) as one undifferentiated 'security' topic, so questions about who can see or change an object are answered with the wrong control.
Several independent mechanisms restrict access - authentication and role determine what a user may do, administrative partitions determine which objects they can see, and traffic-facing policies determine what traffic is allowed - and candidates collapse them.
What to do instead
Map each control to its scope: user role and authentication for management permissions, administrative partition for object visibility and delegation, self IP/port lockdown and allowed addresses for management reachability, traffic policies for data-plane filtering. Answer by asking 'is this about a person, an object, or a packet?'