Skip to content

F5 BIG-IP

Scope

This file covers F5 BIG-IP load balancing and application delivery including LTM virtual servers, pools, and nodes, iRules and iApps for traffic manipulation, SSL offloading and certificate management, health monitors, persistence profiles, GTM/DNS for global server load balancing, ASM/Advanced WAF for web application security, APM for access management, BIG-IP Virtual Edition (VE) deployment, migration from hardware appliances to virtual or cloud editions, F5 Distributed Cloud services, and licensing models (perpetual vs subscription, vCMP guest provisioning). For general on-premises load balancing patterns and comparison with HAProxy/NGINX, see general/load-balancing-onprem.md.

Checklist

  • [Critical] Are LTM virtual servers configured with appropriate profiles (HTTP, TCP, SSL) and are pool members defined with correct service ports, priority groups, and connection limits to prevent backend overload?
  • [Critical] Are health monitors configured beyond basic TCP checks -- using HTTP monitors with expected response strings, interval/timeout ratios (interval should be less than 1/3 of timeout), and appropriate monitor assignments (pool-level vs member-level) to accurately detect backend failures?
  • [Critical] Is SSL offloading configured with client-SSL and server-SSL profiles, with certificate/key pairs managed through a renewal process, and are cipher suites restricted to TLS 1.2+ with strong ciphers (disabling SSLv3, RC4, 3DES)?
  • [Critical] Is the BIG-IP HA pair configured with device trust, config sync, and network failover (unicast or multicast), with connection mirroring enabled for critical virtual servers to preserve sessions during failover?
  • [Recommended] Are persistence profiles (cookie, source-addr, SSL session ID, universal) chosen appropriately for each application -- cookie persistence for web applications, source-addr for non-HTTP protocols, and are persistence timeout values aligned with application session timeouts?
  • [Recommended] Are iRules reviewed for performance impact -- avoiding excessive use of when HTTP_REQUEST events, minimizing TCL operations per request, and using data groups instead of nested if/else for routing decisions (iRules execute per-request and can become CPU bottlenecks)?
  • [Recommended] Is GTM/DNS configured for multi-site load balancing with appropriate topology records, wide IPs, and health monitors that verify application availability (not just ICMP), with TTL values balanced between failover speed and DNS cache efficiency (30-60s)?
  • [Recommended] Is ASM/Advanced WAF deployed with an appropriate enforcement mode (transparent for tuning, blocking for production), with learning suggestions reviewed regularly, and false positive exceptions documented to prevent security policy drift?
  • [Recommended] Is the licensing model evaluated against actual usage -- perpetual licenses require annual support renewals ($15K-$50K+/yr per appliance), subscription licensing may be more cost-effective for variable workloads, and vCMP allows multiple BIG-IP guests on a single chassis to maximize license utilization?
  • [Optional] Has migration from hardware BIG-IP to Virtual Edition (VE) or F5 Distributed Cloud been evaluated, including UCS config export/import limitations, iRule compatibility, throughput licensing tiers (25 Mbps to 10 Gbps for VE), and performance differences (no hardware SSL offload in VE)?
  • [Optional] Is APM configured for VPN and application access with appropriate access policies, SSO profiles, and endpoint checks, with session limits aligned to the APM license tier (base 500 CCU vs add-on packs)?
  • [Optional] Are configuration backups (UCS archives) automated on a schedule, stored off-box, and tested for restore -- UCS files contain certificates and keys so must be encrypted and access-controlled?
  • [Recommended] Is monitoring configured for BIG-IP platform metrics (CPU, memory, TMM utilization, SSL TPS) alongside virtual server metrics (current connections, throughput, pool member status) using SNMP, iControl REST, or telemetry streaming to a central observability platform?
  • [Optional] Is F5 AI Gateway evaluated for managing AI application traffic — provides LLM prompt security, token-based rate limiting, AI traffic routing, and observability for AI workloads delivered through F5 infrastructure?

Why This Matters

F5 BIG-IP is the most widely deployed enterprise application delivery controller, often found in environments with hundreds of virtual servers handling critical application traffic. Misconfigurations in health monitors can silently route traffic to failed backends, while poorly written iRules can introduce latency or security vulnerabilities across all traffic flows. SSL/TLS configuration errors on BIG-IP are particularly consequential because the device typically terminates SSL for the entire application portfolio -- a weak cipher suite or expired certificate affects every application behind it. HA configuration mistakes (missing config sync, incorrect failover triggers) can result in split-brain scenarios where both units process traffic with divergent configurations.

Migration decisions are increasingly common as organizations move away from expensive hardware appliances. BIG-IP VE provides the same TMOS functionality but without hardware SSL acceleration, meaning throughput per CPU core is significantly lower. F5 Distributed Cloud represents a shift to SaaS-based delivery but lacks feature parity with on-premises BIG-IP for complex iRule logic. Understanding the licensing implications -- perpetual licenses with mandatory support renewals vs consumption-based subscription -- is essential for accurate cost modeling in architecture designs.

Common Decisions (ADR Triggers)

  • Hardware BIG-IP vs Virtual Edition (VE) -- Hardware appliances provide dedicated throughput (up to 320 Gbps on i15800), hardware SSL offload (100K+ SSL TPS), and FIPS 140-2 HSM options, but cost $100K-$400K+ per HA pair with $15K-$50K+/yr support. VE runs on VMware/KVM/Hyper-V/cloud with software throughput tiers (25 Mbps to 10 Gbps), costs $5K-$50K/yr per instance, but SSL performance is CPU-bound (~5K-20K TPS depending on vCPU allocation). Choose hardware for high-throughput SSL-heavy workloads; VE for branch offices, lab environments, or cloud deployments.
  • iRules vs Local Traffic Policies -- iRules (TCL-based scripting) provide unlimited flexibility for traffic manipulation but are difficult to audit, version control, and can introduce performance issues. Local Traffic Policies (LTP) provide declarative, GUI-manageable routing rules with better performance (evaluated in C, not TCL) but limited to predefined actions. Use LTP for standard routing decisions; reserve iRules for complex logic that LTP cannot express.
  • ASM/AWAF vs external WAF -- F5 ASM integrates directly with LTM for inline web application firewall, simplifying architecture and reducing latency (no additional hop). External WAFs (Cloudflare, AWS WAF, dedicated appliances) may offer better threat intelligence feeds or cloud-native integration. ASM licensing adds $25K-$75K+ per appliance pair. Decision depends on existing F5 investment, security team expertise, and whether traffic is already flowing through BIG-IP.
  • F5 on-premises vs F5 Distributed Cloud -- Distributed Cloud provides SaaS-based load balancing, WAF, and DDoS protection without managing hardware, but requires routing traffic through F5's network (latency impact for on-premises backends). Best suited for internet-facing applications; on-premises BIG-IP remains necessary for internal east-west traffic and applications requiring custom iRules.
  • vCMP multi-tenancy vs standalone appliances -- vCMP partitions a single BIG-IP chassis into multiple virtual guests with isolated resources (CPU, memory, interfaces), enabling consolidation and per-tenant configuration. Requires VIPRION chassis or i-series appliances with sufficient resources. Reduces hardware costs but increases operational complexity. Choose vCMP when multiple teams or environments share hardware; standalone for simplicity or isolation requirements.

AI and GenAI Capabilities

F5 AI Gateway — Purpose-built for managing traffic to and from AI applications. Provides prompt security (injection detection, PII filtering), token-based rate limiting, AI-aware load balancing, and observability for LLM API traffic. Positioned as an AI application delivery layer that extends BIG-IP and F5 Distributed Cloud capabilities for organizations deploying AI services behind F5 infrastructure.

See Also

  • general/load-balancing-onprem.md -- on-premises load balancing patterns, HA designs, and comparison with HAProxy/NGINX
  • general/tls-certificates.md -- TLS certificate lifecycle management and automation strategies
  • general/security.md -- security architecture including WAF placement and defense-in-depth