Forum Discussion

Benoit_Durand_1's avatar
Benoit_Durand_1
Icon for Nimbostratus rankNimbostratus
Apr 15, 2015

iRule - Persistent Pool Selection by Source IP

Hi there,

 

Newbie to F5 and iRules so apologies if my questions seem too simple. Thank you in advance for your time and help. I skipped the traditional "Hello World" first program to try my hand at an iRule that will soon be needed in our environment. I need an iRule that consistently selects a server pool based on the source IP address of the client. I've tried the code below and although my first hit from source 192.168.3.10 gets me to the "CentOS_Cert_Svr" pool as desired, subsequent "Refresh" from the web browser brings me back to the default "CentOS_Pool". From what I read on "CLIENT_ACCEPTED", this iRule trigger only fires when the connection is created in the Big IP's connection table. I presume that the refresh uses that existing connection and thus does not go through the iRule again and gets sent to the default pool for that VS. Is this interpretation correct? I'm sure this could be solved by setting up persistence on the VS but I would not want the servers in the default pool to also be covered by the persistence settings. Is there a way to solve this using iRules only? Thanks.

 

  • Ben

 

APM
application delivery
design
devops
iRules
LTM
security

3 Replies

Sort By
  • 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