F5-303 cheat sheet
F5-303 · Keep the key ideas within reach.
Application Delivery and Security Platform fundamentals
The BIG-IP platform terminates client TCP connections on a virtual server, then uses a load-balancing method to select a pool member and opens a separate server-side connection; client and server TCP sessions are independent.
A virtual server binds a destination IP:port and VLAN/listener; a pool groups pool members (IP:port) with a health monitor; an iRule or local traffic policy triggers on events such as HTTP_REQUEST or CLIENT_ACCEPTED.
Full proxy mode (default) allows payload inspection and modification; performance (fastL4) mode forwards at layer 4 with limited L7 inspection; forwarding (IP) virtual servers route based on destination without NAT.
Default load-balancing methods: Round Robin (sequential), Least Connections (fewest active connections), Observed (adaptive scoring), Predictive (trend-based), Ratio, and Source IP Hash (sticky by client address).
Persistence profiles override load balancing for a flow: source address, cookie (HTTP), SSL session ID, and destination address persistence. Persistence entries time out per profile timeout; mirroring replicates entries to a peer.
Health monitors mark a member up/down; a pool member is used only when its monitor is successful. Monitor interval, timeout, and retries determine detection time: worst-case detection ≈ interval × (retries + 1).
SSL/TLS termination at the virtual server offloads encryption from servers; client-side and server-side SSL profiles are configured independently, enabling re-encryption to pool members.
OneConnect (connection pooling) reuses server-side TCP connections across client requests; it changes server-side connection counts, so least-connections decisions and idle timeouts must account for it.
The platform separates data plane (TMM traffic processing) from control plane (configuration, GUI, iControl REST); a configuration change is compiled and distributed to TMM instances.
BIG-IP platform configuration and traffic management
Configuration object hierarchy: virtual server → pool → pool members; profiles (TCP, HTTP, SSL, persistence, analytics) attach to virtual servers and inherit from parent profiles; iRules attach to virtual servers.
A virtual server's destination can be a host IP, network, or wildcard; a network virtual server matches a subnet, and a wildcard virtual server matches any destination not otherwise matched (often used as a default).
Source NAT (SNAT) can be automap (uses the virtual server's self IP) or a SNAT pool/SNAT list; SNAT changes the source address seen by pool members and affects server-side logging and return routing.
iRules process events in order (e.g., CLIENT_ACCEPTED, HTTP_REQUEST, LB_SELECTED, HTTP_RESPONSE); commands such as pool, node, persist, and HTTP::redirect alter traffic; a violated iRule can drop or reset the connection.
Local traffic policies provide a GUI-driven, ordered rule set (conditions and actions) that can replace many iRules; rule order and the 'default' action determine the outcome.
Profiles control protocol behavior: TCP profile idle timeout, HTTP profile (redirect rewrite, X-Forwarded-For insertion, compression), and SSL profile (certificate, ciphers, TLS versions).
Persistence and load balancing interact: a persistence entry takes precedence over the load-balancing method until it expires; persistence can be mirrored to a standby device in a device group.
ConfigSync and device groups synchronize objects across HA peers; a change is not active on the peer until sync completes; failover uses network failover and/or a floating self IP.
Configuration deployment methods: tmsh (command line), iControl REST (HTTPS /mgmt/tm/...), and declarative AS3 (POST /mgmt/shared/appsvcs/declare) which creates or updates application service objects idempotently.
Application security and web application firewall
A web application firewall (WAF) security policy contains attack signatures, attack signature sets, and protections; enforcement mode can be transparent (log only) or blocking (drop/alert).
Learning and staging: a policy in staging learns from traffic; suggestions (signatures, parameters, URLs, cookies) are reviewed and accepted; a policy is enforced after staging is complete.
Positive security model: allowed URLs, parameters, cookies, and file types are defined; requests outside the model are violations. Negative model relies on signatures and attack patterns.
Violation categories include SQL injection, cross-site scripting, command execution, and protocol violations; each violation has an alarm/block setting and is logged with a support ID for correlation.
Attack signature sets have accuracy (low/medium/high) and risk (low/medium/high) attributes; signature staging and enforcement can be applied per signature or per set.
Bot defense and DoS protection are separate modules: bot defense classifies clients (browser, mobile, scripted) and can challenge or block; DoS profiles set thresholds and rate limits per endpoint.
SSL orchestration and certificate management apply to inspection: decrypted traffic can be inspected by the WAF, then re-encrypted to the server; TLS version and cipher policy affect inspection compatibility.
Security logging goes to local logs and remote logging (HSL/syslog); the request's support ID links a client error to the corresponding log entry for troubleshooting.
Automation, APIs, and integration
iControl REST base URL is https:///mgmt; authentication uses basic auth or token auth (POST /mgmt/shared/authn/login returns a token used in the X-F5-Auth-Token header).
Common REST endpoints: /mgmt/tm/ltm/virtual, /mgmt/tm/ltm/pool, /mgmt/tm/ltm/pool/
Common/members, /mgmt/tm/sys/...; object paths use ~ for folder separation.AS3 declarative API: POST /mgmt/shared/appsvcs/declare with a JSON declaration (class AS3, tenant, application, service, pool) creates or converges configuration; GET returns current state; DELETE removes.
DO (Declarative Onboarding) configures base system settings (hostname, network, DNS, NTP, license) via POST /mgmt/shared/declarative-onboarding; Telemetry Streaming (TS) pushes metrics/logs to consumers.
tmsh automation: tmsh commands can be scripted; 'tmsh list' and 'tmsh show' are read-only; 'tmsh save sys config' persists; 'tmsh load sys config' reloads.
Idempotency: AS3 declarations are desired-state; reapplying the same declaration should not duplicate objects; changing a declaration updates the service.
The iControl LX framework allows custom REST workers (extensions) deployed as RPMs; they expose endpoints under /mgmt/shared/.
API error handling: HTTP 4xx indicates request/validation errors, 5xx indicates server-side failures; the response body often contains a code and message; check task status for async operations.
Troubleshooting, monitoring, and operations
Troubleshooting order: verify virtual server status (available/offline), pool member health (monitor status), persistence, and iRule/policy actions; a down monitor explains most 'no traffic' cases.
Useful commands: tmsh show ltm virtual, tmsh show ltm pool members, tmsh show sys tmm-traffic, tmsh show sys performance, tmsh show ltm profile, and 'tcpdump -i 0.0:nnn host ' on the management or TMM interface.
Logs: /var/log/ltm (local traffic), /var/log/apm, /var/log/asm, /var/log/audit; qkview collects diagnostics for support; tcpdump and ssldump capture traffic and TLS handshakes.
Monitor failure causes: wrong port, protocol mismatch, timeout shorter than server response, or health check path returning non-2xx; test with curl from the BIG-IP to the member.
HA troubleshooting: check device group sync status (tmsh show cm sync-status), failover state (active/standby), and network failover connectivity; a forced offline state prevents failover.
Performance monitoring: TMM CPU, memory, and connection counts; 'tmsh show sys tmm-traffic' shows current connections and throughput; analytics profiles provide per-virtual metrics.
SSL issues: certificate expiry, chain order, cipher mismatch, and SNI; 'openssl s_client -connect host:443 -servername ' from the BIG-IP validates the handshake.
Change safety: take a UCS backup before changes, use qkview for support cases, and validate configuration with 'tmsh load sys config verify' before applying.