F5 301B BIG-IP LTM key terms

A BIG-IP LTM object that listens on a defined IP address and port and distributes arriving client connections to pool members according to its configured profiles and load balancing settings.

The wildcard or specific address portion of a virtual server that determines which client traffic is matched; a wildcard destination matches any address not already claimed by another virtual server.

A setting on a virtual server that restricts which VLANs may send traffic to it, allowing the same address and port to be reused across different network segments.

The pool a virtual server forwards traffic to when no iRule or other logic selects a different destination for the connection.

A named collection of nodes and services, called pool members, that receive traffic from a virtual server and are health-checked and load balanced as a group.

A node address combined with a service port inside a pool; the member is the actual endpoint that receives connections and carries its own monitor and ratio settings.

A logical object representing a backend server's IP address. Nodes exist independently of pools and can be referenced by multiple pools with different service ports.

The algorithm a pool uses to choose among available members, such as round robin, least connections, or observed, each favoring different traffic patterns.

A per-member weight that scales how much traffic a member receives relative to its peers when the pool uses a ratio-aware load balancing method.

A number assigned to pool members so that members in a lower-numbered active group receive all traffic while higher-numbered groups serve only as failover targets.

A pool member designated to receive traffic when all other members are unavailable, commonly used with priority groups to provide a last-resort destination.

A test that BIG-IP periodically runs against pool members or nodes to decide whether they are available to receive traffic; results mark objects up or down.

The number of seconds a monitor waits between successive probes of the same object, controlling how quickly a failure can be detected.

The number of seconds a monitor waits for a probe response before counting it as a failure; it is normally shorter than the interval.

Text a monitor searches for in the server's response; if the string is absent or the connection fails, the monitored object is marked down.

The request payload a monitor transmits to the server, such as an HTTP GET or an SMTP greeting, before it evaluates the response.

A configuration object attached to a virtual server that controls how BIG-IP processes traffic, such as HTTP parsing, TCP behavior, SSL handling, or persistence.

The base profile from which a custom profile inherits default settings; a child profile stores only the values it overrides.

A profile that enables HTTP parsing on a virtual server, allowing header insertion, response rewriting, and HTTP-aware features that plain TCP forwarding cannot provide.

A feature that reuses server-side TCP connections for multiple client requests, reducing connection setup load on backend servers for short-lived HTTP traffic.

A profile that makes the virtual server terminate TLS from clients, presenting the configured certificate and key and optionally requesting a client certificate.

A profile that makes BIG-IP initiate TLS toward backend servers, so traffic is re-encrypted after decryption at the virtual server, creating full SSL bridging.

Server Name Indication lets a client name the host it wants during the TLS handshake, allowing one virtual server address to select among multiple certificates.

The ordered set of certificates from the server certificate through intermediate authorities to the root, which clients need in order to validate the presented identity.

A TLS setting that requires clients to present a certificate, optionally validated against a trusted CA bundle, before the connection is accepted.

A certificate revocation list that BIG-IP can check during client certificate validation to reject certificates that the issuing authority has revoked.

A deployment where BIG-IP decrypts client TLS, inspects or modifies the traffic, then re-encrypts it toward the server using a server SSL profile.

A profile that keeps a client's subsequent connections going to the same pool member for a defined period, based on a cookie, source address, or SSL session.

A cookie inserted by BIG-IP, or an existing application cookie it reads, that records which pool member served the client so later requests return there.

A persistence method that maps a client's source IP address to a pool member, which can misbehave when many clients share one address through NAT.

The idle period after which a persistence entry expires; a value of zero or indefinite means the record persists until it is manually cleared or the member fails.

A TCL-based script bound to a virtual server that fires on events such as HTTP_REQUEST or CLIENT_ACCEPTED to inspect and change traffic handling.

A named trigger in the connection lifecycle, such as CLIENT_ACCEPTED, HTTP_REQUEST, or LB_SELECTED, at which an iRule's associated script block executes.

The act of choosing which pool receives a connection, done by a default pool, an iRule command, or a combination where the iRule overrides the default.

A setting that copies connection and persistence state to a standby device so sessions survive failover without requiring clients to reconnect.

A paired device configuration where an active unit handles traffic and a standby unit takes over on failure, synchronizing configuration and connection state.

A configuration object that groups devices for configuration synchronization and defines failover order and network failover behavior between them.

Counters such as current connections, total connections, and bits in and out that show how much traffic a virtual server or pool member is handling.

The Traffic Management Shell, a command-line interface used to create, list, modify, and save LTM objects, and to run show commands for troubleshooting.

The process of pushing configuration objects from one device in a device group to its peers so that all units share the same LTM definitions.