F5 BIG-IP Technology Expert

1. Classify the request:

   • Troubleshooting -- Load references/diagnostics.md for TMSH commands, tcpdump, iHealth, pool/node status
   • Virtual server design -- Load references/best-practices.md for VS types, profile selection, pool configuration
   • Architecture -- Load references/architecture.md for TMM, CMP, module processing order, HA
   • iRules -- Apply iRule event model and performance guidance below
   • Automation -- Apply iControl REST API patterns
   • Security -- ASM/WAF policy design, APM access policy, AFM firewall rules

2. Identify version -- Determine BIG-IP software version. If unclear, ask. Version matters for feature availability and TMOS behavior.

3. Load context -- Read the relevant reference file for deep knowledge.

4. Analyze -- Apply F5-specific reasoning, not generic load balancer advice.

5. Recommend -- Provide actionable guidance with TMSH commands, iRules code, or API calls.

6. Verify -- Suggest validation steps (show ltm virtual, show ltm pool, tmsh show sys performance).

Core Architecture

TMM (Traffic Management Microkernel)

• Custom high-performance packet processing engine (not Linux kernel networking)
• Handles all traffic: SSL termination, load balancing, iRules, persistence, compression, caching
• Runs as userspace process; bypasses kernel network stack for performance
• Each TMM thread handles a subset of connections
• Cores dedicated exclusively to TMM processing

CMP (Clustered Multiprocessing)

• Scales TMM across multiple CPU cores on multi-blade chassis (VIPRION) and high-core appliances
• Flow-distribution algorithm distributes traffic across TMM instances
• Connection state synchronized across TMM instances

TMOS (Traffic Management Operating System)

• Based on CentOS Linux with F5 custom kernel and TMM
• Management plane: TMSH CLI, iControl REST API, GUI (Configuration Utility)
• Modules licensed and activated on top of TMOS base

Module Processing Order

Ingress Interface
    -> Packet Filter (rate-based rules)
    -> AFM (Advanced Firewall Manager)
    -> iRule FLOW_INIT event
    -> LTM / GTM-DNS (load balancing, virtual servers)
    -> APM (Access Policy Manager)
    -> ASM / Advanced WAF (application security)
Egress toward pool members

LTM (Local Traffic Manager)

Virtual Server Types

Pool Configuration

Pools group backend servers (nodes/members) with a load-balancing algorithm and health monitor:

create ltm pool POOL_APP {
    members add {
        192.168.10.11:8080 { priority-group 1 }
        192.168.10.12:8080 { priority-group 1 }
    }
    load-balancing-mode least-connections-member
    monitor http_head_f5
}

Load Balancing Methods

Health Monitors

Best practice: Always use the most specific monitor possible. HTTP monitor with expected response string is far better than TCP monitor for web services.

Persistence

Profiles

Profiles define protocol behavior attached to virtual servers:

• TCP Profile: Congestion control, buffers, keepalive, slow-start
• HTTP Profile: OneConnect (connection multiplexing), header manipulation, compression
• SSL/TLS Profile: Cipher suites, TLS versions, cert/key bindings, SNI, OCSP stapling
• Compression: gzip/deflate for HTTP responses
• Analytics: Per-VS application analytics

iRules

Event Model

iRules respond to events at specific traffic processing points:

Key Commands

# Route to pool
pool POOL_APP

# Header manipulation
HTTP::header insert "X-Forwarded-Proto" "https"
HTTP::header remove "Server"

# Redirect
HTTP::redirect "https://[HTTP::host][HTTP::uri]"

# Datagroup lookup
if { [class match [IP::client_addr] equals BLOCKLIST_IPs] } { drop }

# Custom persistence
persist uie [HTTP::cookie "SESSIONID"] 3600

# Logging
log local0. "Client [IP::client_addr] requested [HTTP::uri]"

iRules Performance

• iRules add CPU overhead per transaction
• Minimize event subscriptions (don't use HTTP_REQUEST if not needed)
• Use class match for large lists (O(log n) datagroup lookup)
• Avoid regexp in hot paths; use string match where possible
• Consider iRules LX (Node.js) for complex string processing

GTM / BIG-IP DNS (GSLB)

Wide-IP

A FQDN resolved using intelligent GSLB logic:

create gtm wideip a APP.EXAMPLE.COM {
    pools add { POOL_DC1 { order 0 } POOL_DC2 { order 1 } }
    pool-lb-mode topology
}

GSLB Methods

iQuery

Proprietary protocol between GTM and LTM instances exchanging real-time load and availability data for informed GSLB decisions.

ASM / Advanced WAF

WAF Policy Model

Positive security (whitelist) + negative security (attack signatures):

• Attack Signatures (OWASP Top 10, server-type-specific, CVE-based)
• Entity lists: URLs, parameters, file types, headers
• Bot Detection: proactive bot defense, JS challenges, CAPTCHA
• DataSafe: form field encryption against credential harvesting
• Brute Force Protection and L7 DDoS mitigation

Deployment Modes

• Transparent: Inspect only, no blocking (learning mode)
• Blocking: Block requests matching attack signatures
• Selective Blocking: Per-violation or per-entity decisions

APM (Access Policy Manager)

Visual workflow-based authentication and authorization:

• Endpoint inspection, multi-factor authentication
• LDAP, RADIUS, SAML, Kerberos, OTP, client certificate
• SSL-VPN with split tunneling
• SAML IdP and SP capabilities
• Per-session and per-request access policies

AFM (Advanced Firewall Manager)

Stateful L3-L7 network firewall before LTM processing:

• Rule lists with accept/deny/reject actions
• Applied at global, route-domain, virtual-server, or self-IP context
• DoS/DDoS protection (SYN flood, UDP flood, DNS DoS)
• IP Intelligence threat feeds

iControl REST API

Base URL: https://<bigip>/mgmt/tm/

Key patterns:

• GET /mgmt/tm/ltm/virtual -- List virtual servers
• POST /mgmt/tm/ltm/pool/~Common~POOL/members -- Add pool member
• PATCH .../members/~Common~IP:port with {"session":"user-disabled"} -- Drain member
• Transactions: POST /mgmt/tm/transaction for atomic batch operations

Authentication: Basic auth or token-based (X-F5-Auth-Token).

HA (High Availability)

Device Groups and Trust

• Device Trust: Cryptographic trust between BIG-IP devices
• Device Group: Trusted devices that synchronize configuration

HA Modes

Traffic Groups

Collections of floating IPs that move between devices during failover. Optional MAC masquerade address reduces ARP delay on failover.

Config Sync

• Incremental sync (default, efficient)
• Full sync (used after device replacement)

Common Pitfalls

1. OneConnect without persistence -- OneConnect multiplexes connections. Without persistence, subsequent requests from the same client may go to different pool members. Enable cookie persistence when using OneConnect with stateful applications.

2. iRule complexity causing CPU bottleneck -- Complex iRules (especially with regexp) on high-traffic virtual servers consume significant TMM CPU. Profile iRule performance with tmsh show ltm rule <name> stats.

3. Monitor interval too short -- Aggressive health check intervals (1 second) across many pool members generates significant backend probe traffic. Default 5-second interval is appropriate for most use cases.

4. Forgetting to sync configuration -- Changes made on one device are not automatically pushed to the peer. Always sync after configuration changes in HA pairs.

5. FastL4 when you need L7 -- FastL4 (Performance Layer 4) provides maximum throughput but cannot inspect HTTP content, apply iRules HTTP events, or perform SSL offload. Use Standard virtual server for HTTP/HTTPS applications.

6. SNAT automap exhausting ports -- SNAT automap uses self-IP ports. At very high connection rates, port exhaustion causes connection failures. Use a SNAT pool with multiple IPs for high-traffic VS.

7. ASM in transparent mode permanently -- Transparent mode is for learning. After tuning, switch to blocking mode. A WAF in transparent mode provides monitoring but zero protection.

8. Not using traffic groups for HA -- Default traffic-group-1 contains all floating IPs. For active-active, create separate traffic groups and assign VIPs appropriately.

Version Agents

For version-specific expertise, delegate to:

• 17.5/SKILL.md -- BIG-IP 17.5, latest LTS, TLS 1.2 minimum for management, ML-based bot detection, CGNAT improvements

Reference Files

Load these when you need deep knowledge:

• references/architecture.md -- TMM internals, CMP, TMOS, module processing order, HA mechanics, traffic groups. Read for "how does X work" questions.
• references/diagnostics.md -- TMSH show commands, tcpdump, iHealth, pool/node status, connection table, logs. Read when troubleshooting.
• references/best-practices.md -- Virtual server design, iRules patterns, monitor selection, HA deployment, SSL best practices, F5 XC integration. Read for design and operations questions.