08 LTM Profiles
A profile is a group of settings attached to a virtual server that unlocks or tunes how BIG-IP handles a protocol. Profiles are where most of BIG-IP’s features live: TCP tuning, HTTP awareness, compression, caching, connection reuse, SSL. This note covers the common profiles, their dependencies and limitations, and how to choose between them.
How profiles work
- Built-in profiles (
tcp,http,clientssl…) are parents. Don’t edit them: create a child profile that inherits from the parent and change only what you need. - Profiles have dependencies: HTTP needs TCP; HTTP/2 needs HTTP + TCP + Client SSL; Stream needs TCP + HTTP.
- iRules depend on profiles too: an
HTTP_REQUESTiRule needs an HTTP profile on the VS. - Client-side vs server-side: protocol and SSL profiles can differ on each side (e.g. mobile-optimized TCP toward clients, LAN-optimized TCP toward servers).
TCP profiles
| Profile | Tuned for |
|---|---|
tcp | Generic parent profile |
f5-tcp-progressive | Most performance features; a good modern default |
f5-tcp-lan / tcp-lan-optimized | Low latency, high bandwidth (server side) |
f5-tcp-wan / tcp-wan-optimized | High latency links (Internet/WAN clients) |
f5-tcp-mobile / tcp-mobile-optimized | Cellular clients: loss and variable latency |
Buffers and congestion
Contenido complementario
These TCP details come from the 301b outline and general BIG-IP knowledge, not from my lessons. Validate in the lab.
Pendiente: validar en el lab
Este contenido no salió de mis clases. Probar estos comandos y pasos en BIG-IP VE antes de usarlos en un trabajo real, y corregir lo que difiera en mi versión.
- BIG-IP buffers data between the fast side and the slow side. Proxy Buffer High/Low: when the buffer reaches High, BIG-IP stops reading from the sender; it resumes at Low. Bigger buffers enable content spooling: the server finishes fast and BIG-IP feeds the slow client.
- Send Buffer and Receive Window limit throughput on high-latency links (bandwidth-delay product).
- Congestion control (Cubic, BBR, Woodside…), Nagle, delayed ACK, SACK, idle timeout (default 300 s) are tuned in the TCP profile.
- Packet loss → retransmissions → smaller congestion window → lower throughput.
Other common profiles
| Profile | Purpose | Notes |
|---|---|---|
| UDP | Connectionless apps (DNS, TFTP, DHCP) | |
| SCTP | Message-oriented apps (e.g. Diameter); multi-streaming in one association | |
| HTTP | L7 awareness: headers, cookies, URIs, redirects, X-Forwarded-For, fallback host | Required for most L7 features |
| OneConnect | Reuses idle server-side connections between BIG-IP and members | Fewer active sessions on servers, better HTTP performance. Needs HTTP; with HTTPS, BIG-IP must decrypt (no pass-through) |
| HTTP Compression | Compresses responses to clients | Reduces network traffic, offloads the servers, increases capacity. Options: HTTP/1.0 requests, CPU saver, gzip level |
| Web Acceleration | Caching of static content (images, CSS, JS) | Best when content is static; pairs well with compression |
| QUIC + HTTP/3 | Gateway for HTTP/3 over QUIC (UDP) | |
| Client SSL / Server SSL | Encryption toward clients / servers | See [[Contenido/F5/09 - SSL and TLS on BIG-IP |
Servers already compress?
Set Request Header Erase:
Accept-Encodingin the HTTP profile so the servers send uncompressed content and BIG-IP does the compression (or the stream/inspection) itself.
TCP + HTTP (Standard VS)
Use them when you need any of these: IPv6 · TCP Express & content spooling · full OneConnect (including HTTP/1.0 transformations) · L7 persistence (cookie, hash, universal, iRule) · full HTTP iRules · caching / Web Acceleration · compression · HTTP pipelining · virtual server authentication · redirect rewriting · SPDY.
HTTP features work on clear text: with HTTPS, BIG-IP must decrypt first. “HTTP features work best with SSL traffic” is false.
HTTP/2 profile
- Gateway for HTTP/2: reduces latency and improves traffic-flow efficiency (multiplexing, header compression).
- Dependencies: HTTP + TCP + Client SSL.
- Limitations: header compression uses extra CPU/memory; no source-address persistence before v15.0.0; not compatible with NTLM; not compatible with client SSL renegotiation.
- Full proxy HTTP/2 (HTTP/2 toward the servers too): 1) HTTP/2 (Server) profile, 2) enable HTTP MRF Router, 3) Server SSL profile.
FastHTTP profile
- Goal: increased throughput for simple HTTP.
- Used on a Performance (HTTP) VS; depends on the TCP profile.
- Limitations: no ASM policies, limited iRules, no compression, no VS authentication, no pipelining, limited TCP optimizations, limited persistence.
- Course guidance: best throughput for internal web applications.
Modern versions
Per F5 (K8024): FastHTTP always applies SNAT (servers never see the client IP; ~65,536 concurrent connections per self IP toward each node), has no IPv6, no SSL offload, no caching, no PVA, no state mirroring, and it drops out-of-order packets that carry HTTP headers. It works packet by packet with built-in OneConnect, and AS3 can’t configure it. F5 recommends the standard HTTP profile for Internet traffic. Key idea: it trades L7 features for throughput under ideal network conditions.
FastL4 profile
- Used by Performance (Layer 4), Forwarding (Layer 2) and Forwarding (IP) VSs.
- Offloads work to the PVA chip on supported hardware → frees TMM resources.
- PVA acceleration levels: Full (everything in hardware), Assisted (some), None.
- Limitations: no HTTP optimizations or server offloading, no OneConnect, no compression, no VS authentication, no pipelining, limited persistence (source/destination address, hash, universal), iRules only see L4 information, SNAT can downgrade the acceleration level.
- Course: a FastL4 VS that doesn’t reach full PVA acceleration → check that monitors are configured.
Stream profile
- Find and replace strings in the payload as it passes (nothing to do with media streaming). Example: replace an old company name with the new one on every page.
- Dependencies: TCP + HTTP.
- Not compatible with compression: if the server compresses, BIG-IP can’t read the text → set Request Header Erase =
Accept-Encodingin the HTTP profile.
Choosing a profile
| Requirement | Choose |
|---|---|
| General Internet web applications | HTTP |
| Compression or OneConnect | HTTP (not FastL4) |
| IPv6 or pipelining | HTTP / HTTP/2 / Stream (course: not FastHTTP or FastL4) |
| HTTP/2 clients | HTTP/2 |
| Best throughput for an internal web app | FastHTTP |
| Complex HTTP iRules or VS authentication | HTTP |
| Rewrite content in transit | Stream |
| Maximum L4 speed, no L7 | FastL4 |
Performance impact
To reduce server load: SSL offloading (Client SSL), HTTP compression, Web Acceleration (caching static content) and OneConnect. FastL4 frees BIG-IP resources by offloading to hardware.
Self-check
Q1 — Which profile enables caching of web content?
Respuesta
Web Acceleration.
Q2 — An app uses OneConnect and compression and needs fast connections. Is Performance (Layer 4) a good choice?
Respuesta
No. FastL4 doesn’t support OneConnect or compression.
Q3 — Which three profiles are dependencies of HTTP/2?
Respuesta
HTTP, TCP and Client SSL.
Q4 — HTTP/2 client and server profiles are configured but BIG-IP isn't in full proxy mode. What's missing?
Respuesta
Enable the HTTP MRF Router setting (and a Server SSL profile).
Q5 — Which VS type supports the FastHTTP profile?
Respuesta
Performance (HTTP).
Q6 — Which HTTP feature is not compatible with the Stream profile?
Respuesta
Compression.
Q7 — Your company was acquired; replace the old company name with the new one on every page. Which profile?
Respuesta
Stream.
Q8 — To implement OneConnect on an HTTP application, which profiles?
Respuesta
TCP, HTTP and OneConnect (plus Client SSL for HTTPS).