F5 301B BIG-IP LTM study materials
F5 301B BIG-IP LTM study resources

F5 301B BIG-IP LTM: Profiles and traffic processing

F5 301B BIG-IP LTM · Work through your exam, one topic at a time.

All guide sections

Profiles and traffic processing

Domain 2 covers profiles: what each type does, how inheritance resolves, and the order in which BIG-IP processes a connection. Questions usually present a traffic symptom and ask which profile is missing or which setting changed behaviour.

Inheritance

  • Every profile names a parent; values left at inherit resolve from that parent, and the Effective column shows the resolved value.
  • Editing a system default profile changes every virtual server that uses it.
  • One profile per type per virtual server; iRules are the exception and can be attached many times, executed by priority (default 500).

Processing order

  • Client side: TCP → SSL → HTTP → persistence → load balancing. Server side: HTTP → SSL → TCP.
  • An HTTP profile is what makes BIG-IP parse HTTP. Without it, HTTP iRule events do not fire and layer 7 features have nothing to work with.
  • To terminate HTTPS and still do layer 7 work (header insert, URI routing), the virtual server needs both a client SSL profile and an HTTP profile.
  • A server SSL profile is required to encrypt the pool side; no profile means clear text to the member even though the client leg is HTTPS.
  • The default tcp profile carries a 300-second idle timeout that applies to idle connections on either side.

Worked example

An iRule inserting X-Forwarded-For worked, then stopped after a maintenance change; the pool and monitors are fine. Reasoning: when HTTP_REQUEST only fires when an HTTP profile is attached. Removing or replacing the HTTP profile demotes the connection to raw TCP, so no HTTP event occurs and the header is never inserted. Checking the profile list with tmsh list ltm virtual <vs> confirms it; re-attaching the HTTP profile restores behaviour. The same reasoning explains silent compression (needs an http-compression profile) and broken cookie insert.

Traps

  • Assuming a profile's inherited value is its own - check Effective, not the box you edited.
  • Confusing client-side and server-side processing when debugging a header that never reaches the pool.
  • Believing HTTPS on the front means HTTPS to the members.
  • Overlooking that a profile edit is global to every virtual server using it.