I85PREP
⌘ K
F5-304 study materials
F5-304 study resources

F5-304: BIG-IP Local Traffic Management

F5-304 · Work through your exam, one topic at a time.

All guide sections

BIG-IP Local Traffic Management

BIG-IP Local Traffic Management

This domain tests how LTM processes a connection from client to pool member: virtual server types, profiles, iRules, SNAT, persistence, and the order in which decisions occur. Expect scenario questions that ask which object or event actually runs.

Core rules

  • Virtual server types matter. A Standard virtual server is a full proxy and uses TCP/HTTP profiles and most iRules. A Performance L4 (fastL4) virtual server forwards packets with less inspection and supports a limited iRule set. Forwarding IP, Internal, Reject, Stateless, and DHCP relay types serve specific roles.
  • Profiles are applied in layers. Default profiles are inherited unless overridden; a child profile inherits from its parent. The HTTP profile must be attached before HTTP iRules events and cookie persistence work.
  • iRules are event-driven. CLIENT_ACCEPTED runs when the TCP connection arrives; HTTP_REQUEST runs after the request is parsed; LB_SELECTED runs after pool selection; SERVER_CONNECTED runs after the server-side connection; HTTP_RESPONSE runs on the response; LB_FAILED runs when no pool member can be chosen. The pool command in HTTP_REQUEST overrides the default pool.
  • SNAT controls source address translation. Automap uses a self IP; a SNAT pool uses specified addresses. SNAT is often required when servers do not route return traffic through BIG-IP.
  • Persistence is a virtual-server property. The profile, timeout, and fallback method determine whether a returning client stays on the same member. Cookie persistence depends on HTTP; source-address persistence depends on the client IP seen by BIG-IP.
  • Route domains, VLAN listeners, and self IPs affect whether the virtual server is reachable and whether return traffic is symmetric.

Worked example

A virtual server at 10.1.1.10:443 must send /api requests to api_pool and all other requests to web_pool; a separate port-80 virtual server must redirect to HTTPS. Reasoning: on the port-80 virtual server, attach an HTTP profile and an iRule with HTTP_REQUEST that redirects to https://[HTTP::host][HTTP::uri]. On the 443 virtual server, use HTTP_REQUEST: if {[HTTP::uri] starts_with '/api'} { pool api_pool } else { pool web_pool }. Set web_pool as the default pool as a fallback. Do not inspect the URI in CLIENT_ACCEPTED because the HTTP request has not been parsed yet. If no member is available, LB_FAILED can send a custom response.

Traps

Using HTTP commands without an HTTP profile; inspecting a URI in CLIENT_ACCEPTED; forgetting a default pool; assuming SNAT automap always uses the virtual server address; route-domain mismatches in SNAT pools; a wildcard virtual server conflicting with a specific listener; and persistence profiles that cannot operate without HTTP.