F5-301A: Virtual Servers and Profiles

Concepts

A virtual server is a listener: destination address, port and type, plus a default pool and profiles. Types matter - Standard proxies TCP/UDP fully; Performance (Layer 4) is faster but has no HTTP awareness; Forwarding (IP) forwards without a pool; Network virtual servers match traffic rather than a socket; Reject drops cleanly.

Profiles shape behaviour per layer: TCP, HTTP, client SSL, server SSL, HTTP compression, OneConnect and persistence (cookie, source address, SSL, destination address, hash). Virtual servers inherit from default profiles, and each profile may have a parent, forming a chain. Cookie persistence, HTTP iRules and header insertion all require an HTTP profile on the virtual server.

Traps

• Editing /Common/http or /Common/clientssl directly: the change hits every virtual server. Create a child profile instead.
• Expecting cookie persistence to work without an HTTP profile.
• Forgetting that SSL termination needs a client SSL profile and, for re-encryption, a server SSL profile.
• Overlooking Auto Last Hop, enabled by default, which can defeat routing to backend servers.
• Confusing source-address persistence with SNAT.
• Attaching a persistence profile to a pool only, when the virtual server also needs it.

Worked example

Terminate TLS and forward HTTP: create virtual server 10.0.0.100:443 with default pool web_pool, attach a custom client SSL profile whose parent is /Common/clientssl, and add an HTTP profile so cookie persistence and HTTP iRules function. If backend traffic must be re-encrypted, add a server SSL profile as well.

Rule of thumb: one virtual server, one purpose; never edit a default profile - clone it, name it, then attach it.