Manual Chapter :
Configuring Persistence
Applies To:
Show Versions
BIG-IP LTM
- 15.0.1, 15.0.0
Configuring Persistence
About load balancing with persistence
Configure persistence through attributes in the session profile. Attaching a
persistence profile to Virtual server is an invalid configuration and results in a
configuration error.
There are two persistence types (persist-types) available;
session
(default) and none
. If persist-type is set to
none
, persistence is disabled. When persist-type is set to
session
, the persist-key specifies if BIG-IP persists on
Call-ID
(the default value), Src-Addr
(source address), or custom
. Persistence records are kept in SessionDB and therefore synchronized between TMMs and
blades.
The custom persist-key is specifically for iRules to create customer specific persistence
keys. An iRule script may modify the message's persist-key during the SIP_REQUEST,
SIP_RESPONSE or MR_INGRESS events. The value of the message's persist key after
MR_INGRESS event is used for persistence lookup, if the persist-key is set to
Custom
.About session persistence
Session persistence avoids a route lookup based on state recorded on the BIG-IP system.
It guarantees those messages carrying the same persistence key are going to be delivered
to the same (L4) peer.
Persistence entries are keyed by a value extracted from a message initiating a new
session. The value used for the persist entry key depends on the persist-key
configuration attribute.
When an existing persistence record is matched, the current message is delivered to the same
(L4) destination avoiding a route lookup and load balancing (LB) pick.
Recommendation: Set the
persist-timeout
to be greater than the
transaction timeout, specified in the SIP session configuration, as the lesser of the
two is used when creating the persist record on receiving of the initial SIP request
message. The initial SIP request can be INVITE/SUBSCRIBE/MESSAGE
.
Upon receiving of the response for the initial SIP Request message the persistence
record is updated with the persist-timeout value. (For any subsequent responses received
the persist timeout is updated for the persist record.)Example of basic load balancing with session persistence
This diagram shows a call from Call-ID 1-2883 @10.20.0.2 being load balanced to Server 10.10.10.2. And it also shows a call from 1-3000@10.20.0.6 being load balanced to 10.10.10.7, and the persist records created from these calls when persistence is enabled with a key of Call-ID.
Basic load balancing with session persistence example
Configure basic load balancing
In a route, you must specify at least wildcard entries for UDP and TCP.
Route entry - ["", "", "", peer-udp] (Wildcard entry, default route for UDP) Route entry - ["", "", "", peer-tcp] (Wildcard entry, default route for TCP)
Load Balancing Configuration
ltm pool udp-default-pool { members { 10.10.0.10:5060 { address 10.10.0.10 } 10.10.0.11:5060 address 10.10.0.11 } } } ltm message-routing sip peer peer-udp { pool udp-default-pool } ltm message-routing sip route default-route-udp { peers { peer-udp } } ltm message-routing sip profile router siprouter-lb { routes { default-route-udp } } ltm virtual sip-lb-udp { destination 10.20.0.60:5060 mask 255.255.255.255 ip-protocol udp profiles { udp sipsession siprouter-lb } }
