Forum Discussion

Richard__Harlan's avatar
Richard__Harlan
Historic F5 Account
Apr 15, 2015

There are a few way you can do what you are looking for. I am guessing you also have Oneconnect enabled, this causes each HTTP request to be evaluated and LB and not treated as a stream.

 

You can add a persist statement in the if statment this will only create a persist entry if the pool is CentOS_Cert_Svr like the code below

 

if { [IP::addr [IP::client_addr] equals 192.168.3.10] } {
   log local0. "Cert Pool"
   pool CentOS_Cert_Svr
   persist source_addr
   }

You can also get around this by changing the Event to when HTTP_REQUEST this will fire on each request from the client. Either method should fix the issue.

 

  • dragonflymr's avatar
    dragonflymr
    Icon for Cirrostratus rankCirrostratus
    Apr 16, 2015
    Hi, I am as well newbie, so would like to figure out this better. I am quite surprised that persistence is necessary to keep pool selection for subsequent connections. I can understand that persistence is necessary to direct request (or TCP connections in this case?) to the same member of the pool but why to keep pool selection? What is order of events in this configuration? My guess is: 1. Client connects to VS, after 3WH CLIENT_ACCEPTED even fires 2. Client IP is evaluated and based on that pool chosen - as far as I understand this is not related to HTTP requests at all, just to TCP connection 3. LB is performed and pool member in the pool selected before is chosen 4. Entry in connection table is created, I guess this entry will contain at least src.IP:port - dst.IP:port tuple 5. For subsequent packets they should be directed to the same pool member as initial packet - Am I wrong. This still has nothing to do with HTTP requests, this is L4 related. If HTTP uses Keep-Alive then all HTTP request still are transferred using same TCP connection. In case of OneConnect used - I am a bit lost here - OneConnect is assigned at the VS level, pool selection is based on iRule assigned to the same VS, but actual pools (or at least one of the two) is not assigned to VS via VS config but only on runtime via iRule - so how OC is handled then? Server side connections are created and reused to pool members from both pools specified by iRule, or just to the pool assigned directly to VS (if at all). First option seems a bit strange to me as it will create quite a mess - even if given pool is selected, existing connection to member from another pool can be reused? 6. When connection is closed (because of HTTP initiated Connection: Close, or because of Idle Timeout expired) it's removed from connection table 7. Then new connection is coming (transporting new HTTP transaction/s) and is again processed by CLIENT_ACCEPTED - so should land in the same pool as previous TCP connection (if the same src.IP is present). Sure it can be LB to another pool member but WITHIN same pool - Am I wrong here? Question suggested that subsequent HTTP requests were directed to different pool not different member of the same pool - so it make me lost a bit :-( Piotr