Fallback Persistence Profile - how it works
Hi, I don't know if this is bug or correct behavior - tested on 11.2.0 Setup: VS with Default Persistence Profile: cookie insert Fallback Persistence Profile: source address Result: First request from client (without cookie): Set-Cookie header in response setting BIGipServer... cookie Persistence Record (PR) created - makes sense because there was no cookie in client request Second request from client Cookie send in request PR timeout refreshed - could be OK as PR exists matching client IP but because Cookie is provided why it's used? Third request - after PR was manually deleted Cookie send in request PR record created Why PR is recreated when cookie exists? Which persistence is in fact used - cookie or source address? Piotr
Source Address Affinity persistence timeout option
Hi F5 community, question is that : timeout (say, default 180s) starts ticking since connection was first time routed to specific server - is it reset back to default (180s) or preset value each time when connection from the same IP comes in in about 60 seconds, so that it has 180s to expire again? Or after 180s since initial time when connection was established persistence is expired anyway? What can you say based on your experience?
Persistence and Match Across
Hi, I did few test using Source Address persistence on v13. Outcome is a bit surprising for me. Scenario 1: Two Virtual Servers configured VS1 - IP1:80, persistence without Match Across enabled VS2 - IP2:8081, persistence with Match Across Virtual Servers Result: Client connecting to VS1 - Persistence Record (PR) created, ports listed for both Virtual Addr and Node Addr 80 Client connecting to VS2 - no new PR created, one created before used, same ports reported (tmsh show ltm persistence persist-records client-addr all-properties) as in point 1 PR deleted Connection to VS2 - PR created, ports listed 8081 Connection to VS1 - PR created, ports listed 80, another node can be selected, persistence behavior completely separate from VS2 Conclusion: Depending on the order of client connections persistence behavior is different. Basically it is working as described for Match Across Virtual Servers, but leads to quite unpredictable situations. Another issue is that there is no way to find out what actual connection refreshed Age, ports are not updated when connection do different VS with different port is established. It makes troubleshooting mutch harder. For me only VS-s with same persistence profile applied (with Match Across Virtual Servers) should be evaluated. That would create match more predictable setups. What do you think? Scenario 2: Two Virtual Servers configured VS1 - IP1:80, persistence with Match Across Virtual Servers, timeout 180s VS2 - IP2:8081, persistence with Match Across Virtual Servers, timeout 360s Result: Client connecting to VS1 - PR created, timeout set to 180s Client connecting to VS2 - existing PR used, Age refreshed, timeout NOT changed, still 180s used as timeout In opposite situation timeout will be set to 360s even if second connection is using timeout 180s Conclusion: Same for Scenario 1 - only VS-s with the same persistence profile should be evaluated for Match Across functionality. Another issues I noticed: There is no way (at least I am not aware) to check how long given PR will be valid. I can see Age but not timeout when using tmsh, can it be done via iRule? PiotrMatch across services and persistence profiles
This is probably a quick question, but I wanted to ask if I have two virtual servers with the same IP but different persistence profiles and service ports(with Match Across Checked) will this work? For example cookie hash and source addr? (with Match Across checked on both)Fallback Persistence Profile - how it works
Hi, I don't know if this is bug or correct behavior - tested on 11.2.0 Setup: VS with Default Persistence Profile: cookie insert Fallback Persistence Profile: source address Result: First request from client (without cookie): Set-Cookie header in response setting BIGipServer... cookie Persistence Record (PR) created - makes sense because there was no cookie in client request Second request from client Cookie send in request PR timeout refreshed - could be OK as PR exists matching client IP but because Cookie is provided why it's used? Third request - after PR was manually deleted Cookie send in request PR record created Why PR is recreated when cookie exists? Which persistence is in fact used - cookie or source address? Piotr