F5-302 cheat sheet

Virtual server types: Standard (L4 TCP/UDP forwarding), Performance L4 (fast packet forwarding, no iRule or L7 inspection), Forwarding IP (matches any destination IP, used for wildcard routing), Stateless (no connection tracking, used for one-way UDP flows), Reject (drops traffic, returns TCP RST).

Load-balancing methods: Round Robin (sequential), Least Connections (fewest active connections, optional SNAT-aware), Observed (node with lowest current connection count), Predictive (least connections adjusted by historical trend), Ratio, Dynamic Ratio (SNMP-based weights), Fastest (lowest RTT), Least Sessions, and Priority Group Activation.

Priority Group Activation: members are grouped by priority; the LTM balances only within the highest-priority group that has at least the configured minimum number of available members; lower groups activate only when the active group falls below that threshold.

Persistence overrides load balancing: a persistence entry (source-IP, cookie, SSL session ID, destination-IP, hash, SIP) maps a returning client to the same pool member; persistence is checked before the LB method runs and persists for the configured timeout.

A pool monitor marks a member down after the configured failures; the member stays in the pool but is skipped; when all members are down, the virtual server returns an error unless a fallback host or 'all services down' action is configured.

SNAT: Automap uses the virtual server's self IP; SNAT pool uses explicit translation addresses; SNAT is required when pool members must see a consistent source address or when routing requires it; SNAT is applied after the LB decision.

OneConnect (connection pooling) reuses server-side TCP connections across client connections; it requires an HTTP profile and can break protocols that rely on per-connection state; it is incompatible with some NTLM scenarios unless NTLM handling is enabled.

Profiles are layered: a client-side profile controls client-facing behavior, a server-side profile controls pool-member behavior; the virtual server inherits defaults from the parent profile; the most specific profile wins.

Configuration hierarchy: partition > virtual server > pool > pool member > node; a node is a physical or logical server address; a pool member is a node plus a service port plus optional ratio and priority.

Virtual server states: Enabled/Disabled and Available/Offline; a disabled virtual server rejects new connections; an offline virtual server is not listening; both must be enabled and available to serve traffic.

iRule events fire in order: RULE_INIT (once at load), CLIENT_ACCEPTED, HTTP_REQUEST, LB_SELECTED, SERVER_CONNECTED, HTTP_RESPONSE, CLIENT_CLOSED; commands like pool, persist, snat, and drop take effect at the event where they run.

iRule commands: pool selects the pool; node selects a specific node; persist adds persistence; drop discards the packet; reject sends a reset; HTTP::redirect rewrites the response; HTTP::uri returns or sets the request URI.

Health monitors: interval (seconds between checks), timeout (max wait for a response), send (probe string), recv (expected response), and the up/down count; a member is marked down after 'down' consecutive failures and up after 'up' consecutive successes.

Profiles attach to virtual servers: TCP, HTTP, ClientSSL/ServerSSL, OneConnect, HTTP Compression, and Persistence; a profile can be attached to a virtual server or inherited from a parent profile.

The default pool on a virtual server is used when no iRule selects a pool or when the pool command is not invoked; if the default pool has no available members, the connection fails per the fallback setting.

The Web Application Firewall (ASM) runs as a profile on a virtual server; it inspects HTTP requests and responses against a security policy, which contains signatures, attack types, and enforcement settings.

Security policy enforcement modes: Transparent (log only), Blocking (block violations), and Learn (build the policy from observed traffic); the mode is set per policy and can be overridden per attack type.

Attack signatures are grouped into signature sets; the policy references sets, and violations are matched against enabled signatures; signature updates are applied via the signature update file.

Positive security (whitelist) uses learned or defined allowed URLs, parameters, and cookies; negative security (blacklist) uses signatures and attack types; a policy can combine both.

Learning suggestions are generated from traffic in Learn mode; suggestions must be accepted or ignored; only accepted suggestions change the policy; an accepted suggestion can be reverted.

Brute-force protection, session tracking, and IP reputation are separate features; IP reputation uses a subscribed intelligence feed and can be enabled per policy to block known-bad addresses.

Attack types include SQL injection, cross-site scripting, command injection, and buffer overflow; each attack type can be set to Alarm, Block, or Alarm and Block independently of the signature set.

APM provides access control via an access policy (a visual flow of actions) attached to a virtual server; the flow starts at the Start item and ends at Allow, Deny, or Redirect.

Access policy items include Authentication (AAA server, client certificate, SAML, OAuth), Authorization (AD group, LDAP query), Assignment (ACL, session variable), Logging, and Branching (decision on a session variable).

Session variables persist for the session and are referenced as session.; they carry identity, group, and endpoint data between items; they are evaluated at the branch item.

Authentication methods: AAA (RADIUS, LDAP, Active Directory, TACACS+), client certificate, Kerberos, SAML IdP/SP, OAuth, and certificate-based; each is an action item in the flow.

Access profiles define the session timeout, max sessions, and SSO method; SSO (single sign-on) can be form-based, NTLM, Kerberos, or SAML, and applies to the backend application.

Network access (VPN) requires a connectivity profile and a network access resource; the access policy assigns the ACL and the IP address pool; the client uses the BIG-IP Edge Client.

Per-request access policies evaluate on each HTTP request (not just at login) and are used for portal or per-URL authorization; they are attached separately from the main access profile.

GTM (Global Traffic Manager) answers DNS queries for wide IPs; a wide IP maps a FQDN to a pool of virtual servers; the pool contains GTM pool members (virtual servers or IP addresses).

Load-balancing methods for GTM: Round Robin, Return to DNS, Static Persist, Global Availability, Ratio, Topology, Least Connections, and Virtual Server Score; the method determines which pool member is returned in the DNS answer.

DNS resolution order: the client resolver queries the wide IP; GTM applies the LB method across available pool members; the answer is returned with the configured TTL; the client then connects to that address.

Health checks for GTM pool members are monitors (TCP, HTTP, ICMP, or a custom script); a member is marked down after the configured failures and is excluded from answers.

Topology load balancing uses a topology database (region, ISP, network) to map the client's source address to a preferred pool member; the topology record has a score and the highest-scoring match wins.

DNS Express serves authoritative DNS from the BIG-IP without a backend DNS server; it loads zone data and answers queries directly; it is used to offload or replace a DNS server.

A DNS profile on a virtual server enables DNS query processing; DNS cache and DNSSEC are configured in the profile; the GTM listener is a virtual server with a DNS profile.

Statistics are available per virtual server, pool, pool member, and node; key counters are current connections, total connections, bits in/out, and requests; counters reset on the configured interval or manually.

The dashboard shows real-time health: virtual server availability, pool member status, and system CPU/memory; a red indicator means down or offline, yellow means unknown or checking, green means up.

Logging: the LTM log records iRule log commands and system events; the audit log records configuration changes; the ASM log records security violations; each has its own destination and verbosity.

SNMP: the BIG-IP exposes MIBs for virtual servers, pools, and system health; traps are sent on state changes; the SNMP community and trap destination are configured in the system settings.

Analytics (AVR) provides per-application traffic statistics, latency, and response codes; it requires an analytics profile on the virtual server and a data collection setting.

Health monitor status is shown per pool member; a member can be up, down, or unknown; the monitor's send/recv strings and interval determine detection time.

Virtual server not responding: check that the virtual server is Enabled and Available, that a default pool is set or an iRule selects one, and that the pool has at least one up member.

Pool member marked down: verify the monitor's send/recv strings match the application response, the port is correct, and the member is reachable from the BIG-IP; a monitor mismatch is the most common cause.

Persistence not working: confirm the persistence profile is attached to the virtual server, the persistence type matches the application (cookie vs source-IP), and the timeout is longer than the client's retry interval.

OneConnect or NTLM failures: NTLM requires per-connection state; disable OneConnect or enable NTLM handling; otherwise the server sees mixed authentication on a reused connection.

SSL errors: check the ClientSSL profile's certificate and key match, the certificate chain is complete, and the SNI setting matches the requested hostname; a missing intermediate certificate causes client trust errors.

iRule errors: an unhandled TCL error aborts the event; check the LTM log for the error and the event name; a syntax error prevents the iRule from loading; use the iRule editor's syntax check.

DNS/GTM failures: confirm the wide IP and pool are enabled, the pool members are up per their monitors, and the GTM listener virtual server has a DNS profile; a TTL of 0 disables caching.