Forum Discussion
Pool Member disable/forced offline behaviour
Hi Guys, I have a scenario as below:
- Client tries to connect to Outlook and get a password prompt
- Found out the pool member health monitor is showing UP but actual server services (running MS Exch 2016 is down) hence the password prompt.
- Disabled the problematic pool member on F5
- Client clicks Reconnect from Outlook and from F5 sys conn table showing it hitting the pool member
- Did a delete sys conn cs-client-addr in F5 and still showing it hitting the pool member
- Forced offline the problematic pool member on F5and and from F5 sys conn table showing it hitting the pool member
- Remove the problematic pool member from the pool and from F5 sys conn table showing it hitting other pool members. User click Reconnect and no more prompt.
I would like to understand the below:
- When pool member is set to Disabled/Forced offline, any new connection requests will be RST. Any existing active/persistent connections will remain connected until time out? If so, the timeout will be from client or F5 perspective?
- By manually purging the sys connection "delete sys connection cs-client-addr ", does it entirely help to kill off all active/existing connection too? Does it really work and is it a clean way to purge?
- Another way to purge the active/existing connection would be to close the Outlook app and reopen. Then it will hit the F5 VIP and gets served to other working pool members.
Is my understanding correct on the above? I believe this is the way TCP/IP behaves.
Thanks.
David Saw
- Faruk_AYDINNimbostratus
Do you use cookie persistence?
- David_Saw_24368Nimbostratus
No persistence.
- David_Saw_24368Nimbostratus
Anyways, I just checked with F5 TAC and confirmed the below: 1. Disabled - allow existing and persistent connection until time out 2. Forced offline - allow existing/already established (already 3 WHS) 3. Down - should purge all connections including active/existing conn?
1. When pool member is set to Disabled/Forced offline, any new connection requests will be RST. Any existing active/persistent connections will remain connected until time out? If so, the timeout will be from client or F5 perspective?
First of, the difference between Disabled and Forced Offline:
Disabled:
When you set a node or pool member as disabled the following connections are still allowed to communicate:
- Active Connections
- Persistent Connections
When using disabled, the pool member or node will be slowly taken out of service ensuring the minimal impact of the clients. So long as the client has persistence to the pool member or node they can still access it which can sometimes be a problem. For instance, if the virtual server is configured with cookie persistence with an expiration of 7 days, it will take an entire week for all connections to time out and eventually end up at another pool member/node.
Forced Offline:
When a pool member or node is set to Forced Offline the following connections are still allowed to communicate:
- Active Connections
When you need to quickly take a pool member or node offline then the Forced Offline is a far better option. An example would be that you are experiencing a problem on the end-server as the service has crashed and will not come back online again. When this happen, you should set the pool member/node as Forced Offline.
When it comes to the Active Connections, these are based upon the connection table of the BIG-IP. So if you set the pool member/node to Forced Offline and delete all of its related connections in the connection table, it will surely not receive any additional traffic.
2. By manually purging the sys connection "delete sys connection cs-client-addr ", does it entirely help to kill off all active/existing connection too? Does it really work and is it a clean way to purge?
Absolutely, I do not know another way to purge connections other than the tmsh command. You can specify the cs-server-addr as well so you don't kill off all of the connections the client might have to the BIG-IP.
3. Another way to purge the active/existing connection would be to close the Outlook app and reopen. Then it will hit the F5 VIP and gets served to other working pool members.
I'm not sure how the Outlook App works, but if it kills the active connection then that would be a way around it as well. But it would be as easy for you to run the tmsh delete sys connection command than asking everyone to restart their Outlook App. :)
Hope this helps! Let me know if you have any further questions :).
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