Forum Discussion
Max_Q_factor
Mar 17, 2015Cirrocumulus
Piotr,
When you disable a pool member that is part of a virtual server with a persistence profile of any type the virtual server still reviews the persistence information, whether the information is maintained on the F5 in a table, is on a client as a cookie, or is calculated on a per-IP or per-connection basis like a hash.
Once the F5 validates the persistence using one or more of the persistence methods then it makes a decision on where to send the new connection.
I am sorry that this answer sounds so general but it seems like a general question.
- dragonflymrMar 17, 2015CirrostratusI should think twice before asking. Thanks for pointing me in the right direction. Piotr
- Max_Q_factorMar 17, 2015CirrocumulusIt's cool. That is just my prospective and there are other people on devcentral that might have another prospective on this. General questions are not bad but sometimes it makes it difficult to give a specific response.
- dragonflymrMar 17, 2015CirrostratusMy question was probably two questions in one, and second was cleverly hidden :-) I figured out how LTM can always find out if new connection should be processed. What I am a bit not sure is what is the exact process for statefull and stateless persistence or rather when LTM can decide to not pass any connections to disabled node. 1. If there are Persistence Records present LTM should accept new connections until all records will expire, then should not accept any new connections - Am I right? 2. If stateless persistence is used (cookie or CARP) then LTM has to accept new connections as long as there is any active connection in connection table. When there is no active connection and LTM has no info about persistence (as this info is only contained in packet, like cookie) then there is no reason to keep member available for new connections. Or I am completely wrong and LTM will always pass new connection if based on info in packet given disabled member is target of connection? My assumption was that after some time there should be no connection to the disabled member and it could be safely turned off (so for example http service stopped for maintenance). Piotr
- Max_Q_factorMar 17, 2015CirrocumulusI beleive that you are right on number 1. Number 2 is a bit more complicated depending on the type of persistence. For cookie persistence, from what I understand, the LTM will read the session cookie and the expiration time from the client so that takes care of that. I am not sure about calculated persistence (like CARP) and disabling a node member. I did some look ups and could not find anything that I considered definitive.
- dragonflymrMar 22, 2015CirrostratusIt makes perfect sense now, so actually disabled pool member is never switching to "no new connections accepted" state for persistent connections. If cookie persistence has very long timeout and connection with cookie arrives (even after let's say few hours) it still will be accepted. There is no easy way to judge if member is really idle (will not process any new connection) or it still can be necessary to process some persistent connections. Especially when cookie Expiration is set to Session cookie. Piotr