F5 LTM Pools

F5 LTM (Local Traffic Manager) pools are a crucial component for load balancing traffic across multiple servers. Here's a comprehensive summary:

A pool is a logical set of servers (nodes/pool members) that receive traffic from a virtual server. When creating a pool, you define the load balancing method to distribute traffic across members.

Creating and Viewing LTM Nodes

Nodes represent the physical servers that will be load balanced. To create a node, specify the IP address and service port. You can view existing nodes under "Local Traffic > Nodes" in the GUI or use the "ltm node" TMSH commands.

Creating and Viewing LTM Pools

Pools contain the nodes that will receive load balanced traffic. Create a pool by adding members (nodes) and configuring properties like load balancing method. View existing pools under "Local Traffic > Pools" or use "ltm pool" TMSH commands.

Load Balancing Algorithms

F5 offers various load balancing methods to distribute traffic across pool members:

• Round Robin: Cycles through members in order
• Ratio: Distributes traffic based on pre-defined member weights
• Dynamic Ratio: Distributes based on various performance metrics
• Least Connections: Picks member with fewest active connections
• Observed: Picks members based on faster response times
• Predictive: Like Observed, but analyzes performance history

Priority Groups

Priority groups provide failover if all members of a higher priority are unavailable. Configure multiple pools with different priorities to implement primary/backup server groups.

Health Monitors

Health monitors determine if nodes are available to receive traffic based on port, service checks, or external monitors. Associate monitors with pools to dynamically remove failed members.

By understanding nodes, pools, load balancing methods, priorities, and monitors, you can effectively configure F5 LTM to optimize application traffic distribution across your server infrastructure.

# (Only needed if you want to name the nodes to be used in the pool, otherwise you can just create a new pool using the IP:Port with no issues)

# Create LTM Node to Add to Pool
create ltm node <nodeName> address <ipAddress>

# View LTM Node

list ltm node <nodeName>

# Create Layer 4 TCP Health Check
create ltm monitor tcp TCP-80 destination *:80

# Create LTM Pool using Least Connections & Layer 4 Health Check
create ltm pool <poolName> load-balancing-mode least-connections-member monitor tcp TCP-80 members add { <ip/Node>:<port> <ip/Node>:<port> }

# Create Layer 7 Health Check
create ltm monitor http my_http_monitor recv "HTTP/1.1 200 OK" send "GET /health.php
HTTP/1.1\r\nHost: example.com\r\n\r\n"

# Create LTM Pool using Least Connections & Layer 7 Health Check
create ltm pool <poolName> load-balancing-mode least-connections-member monitor http my_http_monitor members add { <ip/Node>:<port> <ip/Node>:<port> }

# Modify LTM Pools Health Check Monitor
modify ltm pool <poolName> monitor tcp <tcpMonitor>
modify ltm pool <poolName> monitor http <httpMonitor>

# Add New Pool Members to Existing Pool
modify ltm pool <poolName> members add { node1:<port> node2:<port> }

View Only Pool Members Status

show ltm pool <poolName> members | grep -E 'member|Member:|Status'

View Pool Status & Members Status

show ltm pool <poolName> members
show ltm pool <poolName> members | grep -E 'Avail|State|Reason|Monitor|Member|Pool'

View Pool Status

show ltm pool <poolName>

To view specific LTM Pool

list ltm pool <poolName>
list ltm pool <poolName> all-properties

To view all LTM Pools

list ltm pool
list ltm pool * all-properties

View Health Monitor

list ltm monitor tcp <monitorName>
list ltm monitor http <monitorName>

View Pool Health Monitor

list ltm pool <poolName> monitor

To disable a pool member's ability to accept new connections while allowing existing connections use "session-disabled"
This will prevent the pool member from receiving new traffic, but existing connections will be allowed to timeout gracefully
To completely disable a pool member & force all existing connections to be dropped you can use "state-down"

Disable modify ltm pool <poolName> members modify { <memberIP>:<port> disabled }
modify ltm pool <poolName> members modify { <memberIP>:<port> state-down }
modify ltm pool <poolName> members modify { <memberIP>:<port> session-disabled }

Enable modify ltm pool <poolName> members modify { <memberIP>:<port> enabled }
modify ltm pool <poolName> members modify { <memberIP>:<port> state-up }
modify ltm pool <poolName> members modify { <memberIP>:<port> session-enabled }

Enable/Disable Pool

modify ltm pool <poolName> disabled
modify ltm pool <poolName> enabled

With this setting, if less than 2 members in the highest priority group are available, traffic will go to the next lower priority as well

# Enable Priority Groups on Pool
modify ltm pool <poolName> priority-group-activation enabled

# Add Pool Members with Priority
modify ltm pool <poolName> members add { 10.2.1.8:80 { priority 10 } 10.2.1.9:80 { priority 5 } }

# Modify Existing Pool Members Priority
modify ltm pool <poolName> members modify { 10.2.1.9:80 { priority 3 } }

# Set minimum members for Higher Priority
- Configure minimum number of members that must remain available in a higher priority group before traffic is also sent to lower priorities

modify ltm pool <poolName> min-active-members <2>

Load Balancing Methods

least-connections-member
least-connections-node
round-robin
ratio-member
dynamic-ratio-member
fastest-app-response
observed-member
predictive-member
ratio-node
dynamic-ratio-node
fastest-node
observed-node
predictive-node

# Modify Pool Load Balancing Mode
modify ltm pool <poolName> load-balancing-mode <mode>

round-robin - Distributes connections across pool members in a circular and sequential pattern

ratio-member - Distributes connections among pool members based on the ratio weights you define
for each member

dynamic-ratio-member - Distributes connections based on various dynamic ratios, such as the
number of current connections and CPU utilization

fastest-app-response - Distributes connections to the pool member that is currently responding
the fastest

least-connections-member - Distributes connections to the pool member that currently has the
fewest active connections

observed-member - Distributes connections based on which pool member currently exhibits the
fastest response times as determined by the BIG-IP system

predictive-member - Distributes connections based on instructions received about system
performance from a predictive analytics server external to the BIG-IP system

ratio-node - Same as ratio-member but based on the server node instead of just the pool member

dynamic-ratio-node - Same as dynamic-ratio-member but based on the server node

fastest-node - Distributes connections to the node that is currently responding the fastest

least-connections-node - Distributes connections to the node that currently has the fewest
active connections

observed-node - Same as observed-member but based on the server node

predictive-node - Same as predictive-member but based on the server node

• To create a pool selection iRule on an F5 load balancer, you can use either a data group or a switch-glob statement. Make sure you have the appropriate http profile on the virtual server before implementing. Here's how you can implement both approaches:

Example1: This iRule retrieves the requested URI, looks up the corresponding pool name in the "uri_pools" data group, and if found, selects that pool. If no match is found, it selects the "default_pool".

# Using a Data Group Pool Selection iRule

create data-group <data_group_name> type string
modify data-group <data_group_name> records add { "/account/*" { "pool account_pool" }
"/customer/*" { "pool customer_pool" } "/equipment/*" { "pool equipment_pool" } }

when HTTP_REQUEST {
set uri [HTTP::uri]
set pool [class match -value $uri equals -data group/uri_pools]
if { $pool != "" } {
pool $pool
} else {
pool default_pool
}
}

# Add the iRule to a Virtual Server
modify virtual <virtual_server_name> rules { <irule_name> }

Example2: In this example, the iRule uses the switch-glob statement to match the requested URI against different patterns. If the URI starts with "/account/", it selects the "account_pool". If it starts with "/customer/", it selects the "customer_pool", and so on. If no pattern matches, it selects the "default_pool"

# Using Switch-Glob Pool Selection iRule

when HTTP_REQUEST {
switch -glob [HTTP::uri] {
"/account/*" {
pool account_pool
}
"/customer/*" {
pool customer_pool
}
"/equipment/*" {
pool equipment_pool
}
default {
pool default_pool
}
}
}

# Add the iRule to a Virtual Server
modify virtual <virtual_server_name> rules { <irule_name> }