Forum Discussion
HTTP requests in persistent TCP connection routes traffic to the disabled server
Our Current Setup
We are using Cookie Insert method for session persistence. So LTM adds "BigipServer*" Cookie in the http response header with value as encoded IP address and port name. Subsequent requests from the client (in our case browser) will have this cookie in the request header and this helps LTM to send the request to same server. This LTM cookie's expiry is set to session, so this cookie will be cleared when we close the browser or we expire it using iRule.
Use case we are trying to achieve
We have set of servers configured as pool members serving traffic to users who are logged in. During release time, we will release the code to new set of servers and add those servers also to the LTM pool. LTM will now have servers with both old code as well as new code. We disable all servers which has the old code so that LTM routes only the requests which already has "BigipServer*" Cookie value pointing to those servers. This will not interrupt the users who are already logged in and doing some work. All new requests (new users) will be load balanced to any of the active servers which has new code. We will ask our already logged in users to logout and login back again once they are done with the current work. We have an iRule configured to expire the LTM cookie during logout, so our expectation is that users will be connected to new servers when they are logging in again.
Problem we are facing now
Even though iRule expires the LTM cookie during logout and the cookie is not present the request header of login, users are still routed to the same disabled server when they are logging in again. Ideally, LTM should have load balanced the request to any of the active servers.
Root Cause
Upon analyzing this further with network traffic, we found that, whenever the browser has a persistent TCP connection open with LTM after logout, browser uses that existing TCP connection for sending the login request. LTM routes this login request to the same disabled server which handled the previous request even though LTM cookie is not present in the request header. If we close the TCP connection manually after logout (using CurrPosts or some other tool), the browser establishes a new connection with LTM during login and LTM load balances this requests to any active server. One option for us is to send "Connection: close" in the response header during logout, but the browser may hold multiple persistent TCP connections (I have seen browser holding even three connections) and hence closing a single TCP connection will not help. Other option is to close the browser, but we don't have that choice for reasons I cannot explain here (trust me).
Question
Why LTM routes the traffic to disabled server even though LTM Cookie is not present? Doesn't it defeat the meaning of LTM Cookie? Is it a bug in LTM?
Is there a way to enforce LTM to not keep persistent connection when the request is served by a disabled server?
Is there a way to instruct browser to close all persistent connections to LTM (not just one)?
Is there a way for LTM to close all persistent TCP connections from an IP Address? What will happen to our users connecting via a proxy server?
Is there any other option available to solve our issue?
4 Replies
- Afro_158117
Nimbostratus
Is it a bug in LTM? No. cookie persistence does not utilize persistence table. pool member is encoded in the cookie value.
sol6917: Overview of BIG-IP persistence cookie encoding:
http://support.f5.com/kb/en-us/solutions/public/6000/900/sol6917.html
Is there a way to enforce LTM to not keep persistent connection when the request is served by a disabled server?
Use Forced Offline were only active connections are allowed. Disabled allows both persistence or active connections.
Is there a way to instruct browser to close all persistent connections to LTM (not just one)? Clear all cookies on browser.
- Mohan_P_250886
Nimbostratus
Thanks for your quick response Alfro. We are aware of how persistence works with Cookie Insert model and that is the reason we are manually clearing the cookie in iRule during logout request. But LTM routes the next login request to the same disabled server even though the cookie BigipServerMy_PoolName is not present in the login request. This behavior happens only when the login request in sent in the persistent TCP connection established on or before logout. If there is no persistent TCP connection available when we click on login, browser establishes a new connection to LTM and the request is properly load balanced to an active server. We want persistence connections to continue to go to disabled server till the user logs out and logs in back. Clearing cookies will not help as the behavior is dependent on persistent TCP connections and not due to cookies. We also have an iRule to clear cookies, but LTM is not considering that cookie (whether it is present or not) when the request is sent through a persistent TCP connection opened before clearing the cookie. Why the behavior is dependent on persistent TCP connection between the browser and LTM? How to enforce LTM to load balance the request if BigipServerMy_PoolName is not present in the request (irrespective of whether the request is made through a new TCP connection or an existing connection)?
- Vijay_E
Cirrus
Try using the following:
-
OneConnect Profile in VS with netmask of /32.
-
Action on Service Down in the Pool set to Reselect.
(1) will force the load balancing decision to be made for every HTTP request instead of the the default of lb decision being made only for the 1st HTTP request.
(2) will force the HTTP Request to be sent to a new pool member when the selected member is down.
-
Hi,
I think that you may need to add a OneConnect profile to your Virtual Server if it's not already the case.
This is a typical use case, where we need OneConnect to detach server side tcp connections.
Help guide the future of your DevCentral Community!
What tools do you use to collaborate? (1min - anonymous)Recent Discussions
Related Content
* Getting Started on DevCentral
* Community Guidelines
* Community Terms of Use / EULA
* Community Ranking Explained
* Community Resources
* Contact the DevCentral Team
* Update MFA on account.f5.com