F5CABR (BIG-IP Recert) cheat sheet

BIG-IP runs TMOS, a Linux-based appliance OS; traffic management processes run in user space with a full-proxy architecture where each connection is terminated and re-originated by the BIG-IP.

A virtual server is the listener object matching destination IP/port; a pool is a group of nodes with a health monitor; a node is the server address; a pool member is node:port with its own state.

The configuration object model is hierarchical: partitions contain virtual servers, pools, profiles, monitors, and iRules; object names must be unique within a partition but may repeat across partitions.

Full-proxy design means client-side and server-side TCP connections are independent, so the BIG-IP can apply profiles, SSL termination, persistence, and iRules separately per side.

Configuration is stored in /config/bigip.conf and /config/bigip_base.conf; changes are held in memory and only persisted to disk by a config save (tmsh save sys config).

FastL4 profile uses a packet-by-packet path with limited inspection; Standard and TCP profiles use full proxy; performance layer 4 vs layer 7 must be chosen per application need.

Every virtual server has a destination address and service port; a wildcard virtual server (0.0.0.0/0 or ::/0) can forward traffic to a pool or to a VLAN-based default.

Management access uses the management port with its own IP and routes, separate from the data-plane self IPs; the default admin account is admin with a forced password change on first login.

Pool member states: up (monitor passing), down (monitor failing), checking, unchecked, forced offline, and disabled; only up members receive new connections unless the pool's action on service down allows otherwise.

Default load balancing method is Round Robin; Least Connections selects the member with fewest active connections, weighted by member ratio; Observed uses a dynamic performance score.

Ratio and priority are per-member attributes: ratio works with most methods to weight distribution, priority is used with priority group activation to restrict traffic to a subset of members.

Pool member monitoring: a monitor assigned to the pool applies to all members; a monitor assigned directly to a member overrides the pool monitor for that member.

Virtual server types include Standard (layer 4/7), Performance L4, Forwarding IP, Stateless, Reject, and DHCP relay; a forwarding virtual server routes traffic without translating the destination.

Source address translation options on a virtual server are None, Automap (uses the egress self IP), and SNAT pool; SNAT is applied on the server side of the connection.

A virtual server can reference a pool directly or use an iRule with pool selection; if no pool is selected, the connection is reset or dropped based on the virtual server configuration.

Health monitor intervals and timeouts determine failover speed: interval is how often the check runs, timeout is how long to wait for a response, and retries multiply the interval before marking down.

Profiles are inherited in layers: default profile, parent profile, and the profile assigned to the virtual server; a child profile overrides only the settings it explicitly changes.

Common profile families: TCP, UDP, HTTP, SSL client/server, OneConnect, FTP, DNS, SIP, and stream. OneConnect reuses server-side connections to reduce handshake overhead.

Persistence methods include source address affinity, cookie (HTTP), SSL session ID, destination address, hash, and universal persistence; a persistence profile is attached to the virtual server.

Cookie persistence inserts a BIG-IP cookie (default name BIGipServer) or rewrites an existing application cookie; encrypted cookie mode hides pool member details from the client.

Persistence timeout and the virtual server's idle timeout interact: if the persistence entry expires, a returning client may be load balanced to a different member.

iRules use TCL syntax with events such as HTTP_REQUEST, CLIENT_ACCEPTED, SERVER_CONNECTED, and LB_SELECTED; commands include pool, node, snat, persist, and pool member select.

iRule precedence: virtual server iRules run in the order listed; profiles and iRules can both influence the connection, but iRules execute at event time and can override profile-driven decisions.

A stream profile or iRule with STREAM_MATCHED can inspect and modify payload content that is not HTTP; content-based routing requires collecting enough data before selecting a pool.

SSL termination means the client SSL profile decrypts traffic on the BIG-IP, which then sends clear or re-encrypted traffic to the pool via a server SSL profile.

Certificate objects are imported as SSL certificates with a matching key; a certificate and key pair is referenced by a client SSL profile, and the profile controls ciphers, protocols, and SNI.

SNI (Server Name Indication) allows one virtual server to present different certificates per hostname; the client SSL profile must have SNI configured with a default certificate fallback.

Certificate chain order matters: the server certificate must be first, followed by intermediate CA certificates; a missing intermediate causes client trust failures even when the leaf is valid.

OCSP stapling lets the BIG-IP attach a signed revocation response to the handshake; CRL and OCSP checks can also be enforced for client certificates.

Client certificate authentication uses the client SSL profile's trusted certificate authorities and optional frequency (once, request, require); the peer certificate is available to iRules.

TLS protocol and cipher control lives in the SSL profile; the default profile may allow older protocols, so hardened profiles restrict to TLS 1.2/1.3 and approved cipher suites.

Certificate expiration monitoring uses the certificate's expiration date; a monitor or iRule can alert before expiry, and a replaced certificate must be re-linked to every profile that references it.

A device group defines which devices participate in config sync and failover; sync-failover groups synchronize configuration and support automatic failover, sync-only groups synchronize without failover.

A traffic group is a floating set of virtual addresses (self IPs and virtual server addresses) that moves between devices; each device has one active traffic group by default and others in standby.

Config sync pushes the configuration from the device that holds the config-sync authority to group members; device trust (certificate exchange) must be established before sync or failover.

Failover triggers include network failure (monitored self IP or VLAN), hardware/daemon failure, and forced offline; the failover method can be network-based or always.

HA state values are active, standby, offline, forced offline, and unknown; the active device owns the traffic group and answers for its floating addresses via gratuitous ARP.

VLAN failsafe and gateway ICMP checks detect loss of network reachability; a failsafe timeout can force the device offline to trigger failover.

Mirroring (connection and persistence mirroring) keeps state on the standby device so sessions survive failover; mirroring requires a dedicated VLAN or network path.

Config sync status values include synchronized, changes pending, and out of sync; a device that is out of sync will not receive automatic config pushes until the difference is resolved.

A VLAN is a layer 2 broadcast domain bound to one or more interfaces; interfaces are assigned tagged or untagged, and a VLAN must have at least one interface or a trunk before traffic flows.

A self IP is an address on a VLAN used for termination of management and monitoring traffic and as a source for SNAT automap; self IPs should not be used for virtual server destinations.

Floating self IPs belong to a traffic group and move with failover; non-floating self IPs stay on their device and are used for device-specific services.

The default route (0.0.0.0/0) is configured as a gateway route; static routes target a gateway or a VLAN, and the BIG-IP forwards traffic only if a route matches the destination.

SNAT translates the client source address to a SNAT address; SNAT pools provide multiple addresses, and automap uses the egress self IP of the VLAN toward the server.

SNAT and virtual server address translation are independent: SNAT affects the server-side source address, while destination NAT affects the server-side destination address.

VLAN groups combine multiple VLANs for redundancy; a member VLAN failing can move traffic to another member, and the VLAN group is referenced by a self IP.

ARP behavior: the BIG-IP answers ARP for its self IPs and virtual addresses; on a shared L2 segment, a virtual address must be reachable via ARP from the client side.

APM provides access policy enforcement: a per-request access policy (visual policy editor) evaluates authentication, authorization, and session variables before allowing a connection to the pool.

APM access profiles attach to virtual servers; the access policy can use local authentication, LDAP, RADIUS, SAML, or OAuth, and supports single sign-on and session persistence.

AFM (Advanced Firewall Manager) enforces network-layer policies: firewall rules, DoS protection, IP intelligence, and DNS security; it operates on packet and flow attributes.

AFM firewall rules match on source/destination address, port, protocol, and VLAN; a default deny rule drops traffic not explicitly allowed, and rules are evaluated in order.

ASM (Application Security Manager) is a web application firewall: it enforces a security policy with attack signatures, parameter checks, and bot defense on HTTP traffic.

ASM policy enforcement modes are transparent, blocking, and disabled; learning suggestions can be accepted to build a positive security policy from observed traffic.

ASM and APM can chain on the same virtual server: APM authenticates the user and ASM inspects the request; ordering is controlled by the virtual server's profile configuration and iRules.

Security logging: AFM events go to the firewall log, ASM events to the application security log, and APM events to the access log; each has its own log publisher and destination.

Health monitors are assigned to pools or pool members and can be layered: a member is up only when all assigned monitors pass; monitor type determines the check (ICMP, TCP, HTTP, HTTPS).

The /var/log directory holds key logs: ltm, tmm, apm, asm, audit, and boot.log; tmsh show sys log and the qkview utility collect diagnostics for support.

tcpdump on the BIG-IP captures traffic on a VLAN or interface; the capture can be filtered by host or port and written to a file for analysis.

Connection and persistence tables can be inspected with tmsh show sys connection and tmsh show ltm persistence; stale entries can be cleared to resolve stuck sessions.

The qkview command bundles configuration, logs, and system state into a single file for support; it is the standard first step for complex troubleshooting.

Software upgrades use the boot location model: a new volume is installed, the system boots into it, and the previous volume remains available for rollback.

Statistics are available via tmsh show ltm virtual, show ltm pool, and show sys performance; SNMP and iHealth provide external monitoring and reporting.

Common failure checks: virtual server state (offline), pool member state (down), monitor status, route/ARP reachability, and profile misconfiguration; each layer should be verified in order.