When a session is maintained by an application, it is necessary to ensure that a persistent session between the client and the server is correctly maintained. This is necessary to guarantee that the server can continue to handle requests from the client. In the case of web-based shopping carts, for instance, it is normal for the user to be required to maintain persistence to a single server during every step of the session.

The use of a persistent profile is what is required in order to configure persistence. The load balancing behavior of a virtual server is being altered as a result of this. BigIP is able to monitor and save session data within a persistence record in the event that the client connection is initially established.

Persistence Methods:-

In F5, Below are the types of persistence methods:

ü  Source Address Persistence

ü  Cookie

ü  Destination Address

ü  Hash

ü  Microsoft Remote Desktop Protocol

ü  SIP

ü  SSL

ü  Universal

ü  Source Address Persistence

Using the client's source IP address, Source Address Persistence routes traffic to the same server and supports both TCP and UDP. Because all connections seem to originate from a single IP address when traffic traverses a NAT or proxy device, source address persistence is limited in this scenario.

The Persistence Table is checked each time a client establishes a connection to a Virtual Server. Finding out if a BIG-IP F5 persistence record already exists for the same Client IP or Same IP Subnet is what this check is all about. F5 will send or direct traffic to the same pool member listed in the Persistence record if a match is detected.

In the event that there is no Persistence record that corresponds to the Client IP address, F5 will load balance the traffic based on the algorithm that is used for load balancing. Information that is contained in the Persistence Record is as follows:

Ø  Persistence Value:- IP address or range that is applicable to the Persistence feature

Ø  Persistence Mode:- The usage of the Persistence Method, which in this instance is the Source IP address

Ø  Virtual Server:- Regarding the virtual server that the persistence record is applicable to

Ø  Pool:- Is the name of the pool to which the member of the pool belongs

Ø  Pool Member :- IP address of the node and the service port it uses

Ø  Age:- For how long has the record of persistence been kept

The traffic will be directed to the same pool by f5 unless:-

Ø  The Persistence record has timed out

Ø  Health monitoring fails for a node or pool member

Ø  The node or pool member is currently in the forced offline state

Persistence Record Idle Timeout:-

Each and every Persistence Record is made accessible to the Persistence table for a predetermined period of time. If the Record is not utilized within the specified time frame, then the record is removed from the F5 Persistence table. The term "Persistence Record Idle Timeout" is used to refer to this time out.

The default Idle-Time Out is either 180 seconds or 300 seconds, depending on the method that is being utilized. When it comes to TCP, the idle-timeout value should be 300 seconds, whereas for UDP, it should be 60 seconds.

The age value of a Persistence record begins to increase once it has been created, and it continues to do so until the timeout number that has been defined is reached. If the value is the same, then the Persistence record in question is removed from the persistence table.

Usage of Mask Setting:-

In the event that we make use of the Source Address Persistence Method, the persistence record of mask 255.255.255.255 is generated by F5. The implication of this is that the IP addresses 141.141.141.141 and 142.142.142.142 will each have their exclusive persistence record.
When we use this, there is a possibility that there could be some performance issues on F5. Therefore, if we use a mask such as 255.255.255.0, then there will be just one persistence record present in the Persistence table.

Drawback of Source address affinity Persistence:-

When many clients connect to a virtual server using a proxy or a NAT device, all of the requests will appear to originate from the same source IP address. This will result in the creation of a single persistence record for all of the clients. This results in a very uneven distribution of load among the members of the pool. This can be shown in below diagram:-

ü  Cookie Persistence

The only protocol that enables cookie persistence is the HTTP protocol. It is not possible for the F5 BigIP to review cookies when the session is encrypted, which is the reason for this condition. Furthermore, it is important to note that in the event that

a)       The system clock of the client is wrong

b)      Cookies are disabled, it is possible that the cookies will not be transmitted from the client to BigIP.

There are 4 main modes of f5 cookie persistence:-

1.       Hash Mode :- When using hash mode, it is expected that the server will supply the cookie. After that, the system generates a hash using either a portion of this cookie or the entire cookie in order to construct a persistence record.

2.       Insert Mode :- When Insert Mode is activated, the F5 LTM will inject a unique cookie into the HTTP Response. The pool member and the pool names are included in this category.

3.       Rewrite Mode :- The F5 LTM rewrites the cookie after the web server has created a blank cookie. This allows the cookie to be read as a special cookie in the future and utilized for persistence purposes.

1.       Passive Mode :- To enable passive mode, the web server must first generate a cookie with a certain format that includes the node's IP and port number. After then, this cookie is handed along in a passive manner.

Cookie Validity Time:-

The cookie Validity is dependent on the type of method being used:-

·       Cookie Hash :- It has a default idle time of 180 seconds

·       Cookie Insert :- Only cookies that are valid for the duration of the current session will be retained. Rather than being stored on the client's disk, cookies are only kept in memory. Other than that, we also have the ability to configure the amount of days, hours, minutes, and seconds for which a cookie is valid.

·       Cookie Passive: - BIG-IP does not have any control over the presence of cookies or the content of cookies; they are both configured on the end server.

·       Cookie Re-write:- This cookie is only good for the current session. The client doesn't store cookies on its hard drive; they are only kept in memory. If not, we can also set the number of days, hours, minutes, and seconds that the cookie is valid for.

Configuring Cookie Persistence:-

Below steps need to be taken in order to configure cookie persistence.

a)       Make sure that the HTTP profile is configured within the Virtual Server it is running on.

b)      Navigate to Resources within the Virtual Server, and then choose Cookie from the list of Default Persistence Profiles.

 

ü  Destination Address Persistence

The Destination IP address of a connection is the focus of this method, which ensures that all requests from any client to a particular destination address are sent to the same pool member. This strategy is especially helpful when used in conjunction with wildcard Virtual Servers and cache, which allows several users to request the same material to be directed to the same cache.

Single Node Persistence