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

F5-304: Application Delivery Fundamentals

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

All guide sections

Application Delivery Fundamentals

Application Delivery Fundamentals

The Application Delivery Fundamentals domain tests the concepts behind a BIG-IP ADC: why traffic is balanced, how health is verified, how sessions stick, and how TLS and profiles shape requests before they reach a pool. Questions are usually terminology and small design scenarios rather than deep command syntax.

Core rules

  • A virtual server is the listener (address:port); a pool is a group of nodes; a pool member is node:port. The virtual server's default pool is used when no iRule or persistence decision overrides it.
  • Load-balancing algorithms encode assumptions. Round robin assumes equal capacity; least connections considers active connections; weighted least connections and ratio handle unequal capacity; dynamic ratio uses monitor-supplied metrics; priority groups provide active/standby behavior.
  • Monitors have interval, timeout, and retries. A TCP monitor only proves the port is open. An HTTP monitor with a send string and receive string proves the application returns an expected payload. The receive string must match the actual response, including case and body.
  • Persistence profiles keep a client on a pool member: source address, cookie, SSL session ID, destination address, hash. Persistence has a timeout; when it expires, the client is load-balanced again. Cookie persistence requires an HTTP profile and a pool member that sets or accepts the cookie.
  • SSL termination can happen on the client side, the server side, or both. Client SSL profiles present the certificate chain; server SSL profiles re-encrypt to the pool. SNI selects a certificate by hostname. An incomplete chain causes client trust errors.
  • Profiles are inherited; a child profile overrides its parent. The HTTP profile enables HTTP parsing and HTTP iRule events. OneConnect pools server-side connections and can change source-port behavior.

Worked example

Three web servers sit behind one HTTPS virtual server: two 16-core hosts and one 8-core host. Login uses a JSESSIONID cookie, and /health returns HTTP 200 with the body 'Healthy'. Choose objects and justify them. Use weighted least connections, not round robin, because capacity differs. Use cookie persistence because the application already issues JSESSIONID. Attach an HTTP monitor with GET /health, Host header, and receive string 'Healthy'; a TCP monitor would mark a broken application as up. Terminate TLS with a client SSL profile and re-encrypt with a server SSL profile if the back end requires HTTPS. Set the monitor timeout above normal application response time.

Traps

Round robin on unequal servers; a TCP-only monitor; source-address persistence behind a NAT or forward proxy; a receive string that does not match the real body; persistence timeout shorter than the application session; missing intermediate certificates; forgetting server SSL when re-encrypting; and no default pool when an iRule fails to select one.