Forum Discussion

pramod_71084's avatar
Icon for Nimbostratus rankNimbostratus
Oct 09, 2011

Data Centre site affinity and persistency

I have 2 data centers using GSLB for banking institution. I need to provide a solution for site persistence and affinity. The problem is as below:



During the process of establishing connections to the Internet Banking application a client will establish session persistence with a particular Proxy and Web Server in one of the available data center locations. A subsequent DNS request from a particular client may resolve to a different VIP address (i.e. second site), which would send the client to a BIG-IP LTM in a different site. This different resolution becomes a problem for the Internet Banking implementation and as a result a solution is required to ensure a client request is always routed to the data center in the original site as the initial request.



This is a common problem as large Internet Service Providers (ISP’s), and other organizations host a series of proxy servers that proxy client requests through to the ultimate destination (in this case my banking application). Some of those ISP’s can’t guarantee that client requests are ending up on the same proxy for the duration of a user sessions. Since each of those proxy servers will perform an independent query against the GTM when it comes to resolving the banking URL the same scenario as above could result i.e. a subsequent request is directed to the other site hence breaking affinity and ending the user’s session with banking application. If and how often this scenario could happen is hard to determine since it is dependent on proxy infrastructure and configuration of external companies.



To ensure all subsequent client requests are delivered to the original site, a location based cookies will be required as follows:



1. The client sends a lookup request for the online banking site to the DNS server.


2. The BIG-IP GTM server responds with the BIG-IP LTM VIP address of Site1


3. The client sends a GET request to the VIP address of Site1 with no cookie.


4. The BIG-IP injects the location cookie LOCATION=Sit1 to the response from the local server. Client-server interaction proceeds normally.


5. At some point in the future, the client sends another lookup request for online banking site to the DNS server.


6. This time the DNS server responds with the BIG-IP LTM VIP address of Site2.


7. The client sends a GET request to BIG-IP LTM VIP at Site2 with a location cookie of LOCATION=Site1. This cookie string matches the configured location cookie name (LOCATION), but not the cookie value (Site1). The BIG-IP LTM at Site2 searches through the list of location services checking the configured strings against the value in the cookie. In this case, a match is made on service Site1.


8. Service Site1 is configured as a destination service on the source group Site2. This service matches on the content rule configured on BIG-IP LTM at Site2. The BIG-IP LTM at Site2 forwards packets from the client to BIG-IP LTM at Site1.


9. Because the client already sent a cookie with the GET request in Step 7, there is no need to inject another cookie. Content rule processing continues with no changes. The server response goes back through BIG-IP LTM at Site1 to BIG-IP at Site2 to the client. The client is now stuck to the original site (online banking site) through BIG-IP LTM at Site2.




3 Replies

  • ckwok's avatar
    Icon for Nimbostratus rankNimbostratus
    That inspire me somehow, I also have a similar scenario but not sure if it is the same as you described here. I have a situation where client has to stick to the same backend node no matter what IP the GTM returns. The setup has a GTM WIDEIP which has one pool and a GTM pool round robin 2 members VIP -e.g LTM in locationA ( and another LTM in LocationB( Both sites have a VIP setup -e.g LocationA -, LocationB - and pool set up with 2 members -e.g., The client doesn't cache cookie. We tried to use src IP address affinity but it doesn't quite achieve 100% stickiness. Will oneconnect plus src IP persistence work ?
  • Sorry, for bumping this old thread, but does anyone know what the OP meant by these two statements:


    • "..the BIG-IP LTM at Site2 searches through the list of location services". What/where is the list of location services?


    • "Service Site1 is configured as a destination service on the source group Site2". Where would this be configured, LTM, GTM? What are source groups? Could anyone point me in the right direction?


    Also, are there any ways to do session affinity between data centers?


    Much appreciated.


    Thanks, VanBasten


  • Sorry for digging this old thread. We also have a similar requirement . But unfortunately, we couldnt prove it. From logs , could see that irule is forwarding the traffic to the other site if the traffic landed upon wrong site.Also after LB_SELECTED there are no traces for SERVER_CONNECTED in case of failure.

    Seeing few LB_FAILED events as well.


    What are factors to checked on F5 in terms of configuration?