A BIG-IP virtual is a listener. The session is not the connection.

1. Why a green VIP is not the app

The NOC paste shows a green circle on vip_finance_443. The app team is already on the bridge. You have about four minutes before someone rebuilds the virtual. That is the wrong first move.

Official About Virtual Servers: the virtual listens for client traffic and directs it according to how you configured the virtual. A primary purpose is to distribute that traffic across a pool. Availability on the listener means the destination answers and at least one pool member is available. It does not mean every persisted user is still hitting a healthy node.

Hero · listener, not the app

2. Mental model — three objects, two tables

Hold the factory as three configuration objects and two runtime tables. Interviews fail when people call all five “the VIP.”

Pipeline · VS → pool → member → node

3. Decision flow on the ticket

Draw this before you touch the virtual. The first question is not “is the pool up.” The first question is “did SYN reach a listener on the active unit.” The second question is “is this TCP missing, or is a session pin leftover.”

Path · listener fork vs persist pin

4. How to choose which table to read

You do not pick SNAT or SSL first. You pick the object that matches the symptom. The connection table answers “is this flow alive on TMM.” Persist-records answer “where will the next handshake go.”

Visual · connection dies, persist remains

5. Runbook Side A → B → C

Goal: stand up the listener, attach a default pool with two members, then prove the connection table and the persist session as two facts. Partition /Common. Addresses are documentation / lab only.

Prerequisites

• You work on the active unit. In Sync is config only.
• VLAN external with a self-IP (floating self-IP if Auto Map + HA).
• Pool members that either use BIG-IP as default gateway, or you plan Source Address Translation = Auto Map.
• A lab certificate already imported if you terminate TLS. Do not invent production serials.

Side A — listener on the Configuration Utility

Path: Local Traffic › Virtual Servers › Virtual Server List › Create. Official: after this task you have a virtual server that listens for application traffic. It is not the website.

1. Create the listener, not the website

   Name vip_finance_443. Type Standard. Destination Address/Mask 198.51.100.50/32. Service Port 443. Protocol TCP. VLAN and Tunnel Traffic = Enabled on external only. Address Translation and Port Translation stay enabled on a Standard virtual so the destination becomes the pool member.

2. Attach the profiles that make L7 possible

   HTTP Profile = http. SSL Profile (Client) = clientssl_finance if you terminate TLS. Cookie persist and HTTP iRules need HTTP visibility. Without client-ssl the handshake belongs to the node.

3. Name the default pool on Resources

   Official: if no iRule or policy specifies another pool, Local Traffic Manager sends traffic to the default pool. Pick it here. Do not leave the virtual listening at nothing.

Side B — pool then member

Path: Local Traffic › Pools › Pool List › Create. Official: assign members, then associate the pool with the virtual.

1. Pool and monitor first

   Name pool_finance_web. Health Monitor https (or a custom HTTPS monitor on a cheap URI). Members 10.20.30.11:443 and 10.20.30.12:443. Official default load-balancing method is Round Robin; least-connections-member is the usual production pick when members are similar.

2. Know disabled vs down

   Official: a disabled member continues persistent and active connections. A member a monitor reports as down processes no connections. INC-4412 is the third case — persist Action On Service Down = None still aiming at the down member.

3. Persistence that dies with the member

   Local Traffic › Profiles › Persistence › Create. Parent cookie. Cookie Method = HTTP Cookie Insert (default cookie name BIGipServer<pool_name>). Set Action On Service Down = Reselect. Attach as Default Persistence Profile on the virtual.

tmsh show ltm virtual vip_finance_443
tmsh show ltm pool pool_finance_web members
tmsh show sys connection cs-client-addr 192.0.2.25
tmsh show ltm persist persist-records
tmsh show sys ha-status

Side C — prove both tables on the active unit

1. Prove you are on the right box

   tmsh show sys ha-status must say Failover State active. In Sync is config only. Mirror enabled is not “every virtual is mirrored.” If you are standby, stop. Both tables will look empty.

2. Prove the listener, then the member

   Show the virtual (enabled/available, VLAN, default pool). Show the pool members — not just pool availability. Dummy: 10.20.30.12:443 down with monitor: https (timeout). Pool can still be available.

3. Print the connection 4-tuple, then the persist record

   Connection table = this TCP. Persist = the pin. Dummy close for INC-4412 is a live persist at 10.20.30.12:443 while that member is down — not a rebuild of the VIP.

Sys::Connections
192.0.2.25:53122  198.51.100.50:443  203.0.113.10:44218  10.20.30.12:443
tcp  idle 14  (tmm: 0)

# Read as:
# cs-client → cs-server (VIP)   ss-client (SNAT/self) → ss-server (member)
# Client-side and server-side are two independent TCP connections on a Standard virtual.

Sys::Persistent Connections
virtual   vip_finance_443
mode      source-address
client    192.0.2.25
node      10.20.30.12:443
age       62

# Cookie Insert also stores BIGipServerpool_finance_web=… on the client.
# Deleting this TCP does not delete the pin.

6. Runtime — full proxy then persist

After the virtual is enabled, one client walk manufactures two TCP connections on a Standard virtual, then maybe one persist record. That is why a handshake failure never reaches the pool, and why a closed TCP does not free the user from the pin.

Proof · both tables on the active unit

7. Traps + proof

Interview close: “A virtual is a listener. Traffic walks VS → default pool → member. The connection table is this TCP. Persist is the session pin that can outlive it. I prove INC-4412 with ha-status, the virtual, the down member, one 4-tuple, and one persist record.”

Sources

• About Virtual Servers — LTM Basics (listens; Create path; dest address; Stateless skips connection table)
• Virtual Servers — LTM Concepts (VIP + service; default pool; dest translation to member)
• Pools — LTM Concepts (pool; member = node:port; disabled vs down)
• Session Persistence Profiles — LTM Concepts (session data; cookie insert)
• tmsh — ltm persistence persist-records
• tmsh — ltm virtual
• F5 301a introduction — virtual is a listener; Standard VS / K8082 handshake order
• K40033505 — Explaining tmsh show sys connection
• K41269952 — persist-records can outnumber sys connection
• K8082 — TCP setup for Standard virtual server types
• K15095 — Action On Service Down

Related: F5 evidence desk · F5 practice dashboard · LTM virtuals and pools · LTM troubleshooting scenarios

Dummy lab: tmsh on this page is documentation-range only. Confirm live syntax on /interview/f5#simulator before you type on a real box.