F5 Bigip

---
name: f5-bigip
description: "Expert coverage of F5 BIG-IP across all versions: TMM/TMOS architecture, LTM virtual servers, pools, health monitors, persistence, iRules, SSL profiles, GTM/BIG-IP DNS for GSLB, ASM/Advanced WAF, APM, AFM, iControl REST API, HA, and BIG-IQ management. Use for \"F5 BIG-IP\", \"BIG-IP\", \"LTM\", \"GTM\", \"iRules\", \"ASM\", \"APM\", \"AFM\", \"TMOS\", \"TMM\", \"iControl\", \"BIG-IQ\", \"F5 WAF\". Do NOT use for cross-vendor comparison, platform selection, or category-wide architecture -- use the `load-balancing` skill."
license: MIT
---

# F5 BIG-IP

This skill covers F5 BIG-IP across all supported versions (15.1 through 17.5). Areas of expertise include:

- TMM (Traffic Management Microkernel), CMP (Clustered Multiprocessing), TMOS architecture
- LTM (Local Traffic Manager): virtual servers, pools, nodes, health monitors, profiles, persistence
- GTM / BIG-IP DNS: Wide-IPs, GSLB pools, topology records, iQuery
- ASM / Advanced WAF: security policies, attack signatures, bot defense, DataSafe
- APM (Access Policy Manager): access policies, SSL-VPN, SAML IdP/SP, SSO
- AFM (Advanced Firewall Manager): network firewall, DoS/DDoS protection, IP intelligence
- iRules: TCL-based event-driven traffic scripting
- SSL/TLS profiles, cipher management, certificate handling
- iControl REST API for automation
- HA: device groups, traffic groups, config sync, failover
- BIG-IQ centralized management
- F5 Distributed Cloud (XC) integration
- Terraform provider for infrastructure-as-code

When a question is version-specific, consult the matching `references/versions/` file. When the version is unknown, provide general guidance and note where behavior differs.

## How to Approach Tasks

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

| Type | Description | Use Case |
|---|---|---|
| Standard | Full proxy; terminates client, initiates to pool | Most HTTP/HTTPS applications |
| Performance (Layer 4) | FastL4; minimal processing, passes TCP/UDP | High-PPS forwarding, non-HTTP |
| Performance (HTTP) | FastHTTP; optimized HTTP | High-volume simple HTTP |
| Forwarding (IP) | Routes without load balancing | Transparent forwarding |
| Reject | Drops traffic with RST/ICMP | Explicit denial |

### 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

| Method | Description |
|---|---|
| Round Robin | Distribute in order |
| Least Connections (member) | Fewest active connections per member |
| Least Connections (node) | Fewest active connections per node (across pools) |
| Fastest | Member with fastest response time |
| Observed | Combines connection count and response time |
| Predictive | Predictive scoring based on observed trends |
| Ratio (member/node) | Weight-based distribution |
| Dynamic Ratio (SNMP) | Weights updated via SNMP from servers |

### Health Monitors

| Monitor | Use Case |
|---|---|
| ICMP (gateway_icmp) | Basic reachability |
| TCP | Port availability |
| HTTP/HTTPS | Web server response (GET, HEAD) |
| TCP Half Open | Firewall-friendly L4 check |
| MSSQL / MySQL / PostgreSQL | Database health |
| LDAP | Directory service |
| External | Custom script-based checks |
| Inband | Passive monitoring of production traffic |

**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

| Type | Mechanism |
|---|---|
| Source Address | Client IP to member mapping |
| Cookie | BIG-IP inserts or reads HTTP cookie |
| SSL Session ID | TLS session identifier |
| Universal | iRule sets custom persistence key |
| Hash | Hash of URL, header, or custom data |

### 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:

| Event | Trigger Point |
|---|---|
| `CLIENT_ACCEPTED` | New TCP connection from client |
| `HTTP_REQUEST` | HTTP request headers received |
| `HTTP_RESPONSE` | HTTP response headers received |
| `LB_SELECTED` | Pool member selected |
| `LB_FAILED` | All pool members down |
| `SERVER_CONNECTED` | Connection to pool member established |

### Key Commands
```tcl
# 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
| Method | Description |
|---|---|
| Round Robin | DNS round-robin |
| Topology | Geolocation-based selection |
| Least Connections | Prefer DC with fewest connections |
| Performance | Prefer DC with best measured performance |
| Static Persist | DNS persistence via hash |

### 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
| Mode | Description |
|---|---|
| Active-Standby | One active, one standby; VIP floats on failover |
| Active-Active | Both active with different traffic groups |
| Sync-Only | Config replication only, no failover |

### 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-Specific Guidance

| Version | Reference | What's version-specific |
|---|---|---|
| 17.5 | `references/versions/17.5.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.