Forum Discussion

vvskaladhar_488's avatar
vvskaladhar_488
Icon for Nimbostratus rankNimbostratus
Feb 04, 2015

irule for implementing hash persistency

HI All,

 

I have configured Hash persistency as primary and source address as fall back persistency ..and on the pool I have round robin . But I am seeing all the load is being sent to single server instead of load sharing. it seems hash persistency is not working as expected because I am seeing persistence stats showing as source address for all the incoming traffic .please see the out put below. And Hash value is 0. btw the vs is configure with port 443 and pool is http 99. Can some one please let me know what is the irule I can add to insert Hash and how to add it

 

Sys::Persistent Connections hash 0 10.74.34.32:443 10.254.192.21:99 (tmm: 0) source-address 166.173.59.119 10.74.34.32:443 10.254.192.21:99 (tmm: 0) source-address 71.223.52.88 10.74.34.32:443 10.254.192.21:99 (tmm: 0) source-address 108.202.106.223 10.74.34.32:443 10.254.192.21:99 (tmm: 0) source-address 75.4.224.45 10.74.34.32:443 10.254.192.21:99 (tmm: 0) source-address 24.252.200.112 10.74.34.32:443 10.254.192.21:99 (tmm: 0) source-address 71.15.39.235 10.74.34.32:443 10.254.192.21:99 (tmm: 0) source-address 204.77.41.130 10.74.34.32:443 10.254.192.21:99 (tmm: 0) source-address 68.57.182.242 10.74.34.32:443 10.254.192.21:99 (tmm: 0) source-address 70.195.203.202 10.74.34.32:443 10.254.192.21:99 (tmm: 0) source-address 71.177.217.72 10.74.34.32:443 10.254.192.21:99 (tmm: 0) source-address 168.137.100.28 10.74.34.32:443 10.254.192.21:99 (tmm: 0) source-address 71.123.131.35 10.74.34.32:443 10.254.192.21:99 (tmm: 0) source-address 99.4.174.66 10.74.34.32:443 10.254.192.21:99 (tmm: 0) source-address 73.10.155.100 10.74.34.32:443 10.254.192.21:99 (tmm: 0) source-address 198.239.178.118 10.74.34.32:443 10.254.192.21:99 (tmm: 0) source-address 24.126.117.245 10.74.34.32:443 10.254.192.21:99 (tmm: 0) source-address 162.199.163.16 10.74.34.32:443 10.254.192.21:99 (tmm: 0) source-address 108.72.82.207 10.74.34.32:443 10.254.192.21:99 (tmm: 0) source-address 24.5.31.159 10.74.34.32:443 10.254.192.21:99 (tmm: 0) hash 0 10.74.34.32:443 10.254.192.21:99 (tmm: 3) source-address 71.223.52.88 10.74.34.32:443 10.254.192.21:99 (tmm: 3) source-address 108.202.106.223 10.74.34.32:443 10.254.192.21:99 (tmm: 3) source-address 50.83.34.179 10.74.34.32:443 10.254.192.21:99 (tmm: 3) source-address 73.197.48.232 10.74.34.32:443 10.254.192.21:99 (tmm: 3) source-address 24.252.200.112 10.74.34.32:443 10.254.192.21:99 (tmm: 3) source-address 71.15.39.235 10.74.34.32:443 10.254.192.21:99 (tmm: 3) source-address 204.77.41.130 10.74.34.32:443 10.254.192.21:99 (tmm: 3) source-address 73.195.77.154 10.74.34.32:443 10.254.192.21:99 (tmm: 3) source-address 184.96.5.186 10.74.34.32:443 10.254.192.21:99 (tmm: 3) source-address 69.253.209.32 10.74.34.32:443 10.254.192.21:99 (tmm: 3) source-address 168.137.100.28 10.74.34.32:443 10.254.192.21:99 (tmm: 3) source-address 70.45.195.196 10.74.34.32:443 10.254.192.21:99 (tmm: 3) source-address 24.18.162.213 10.74.34.32:443 10.254.192.21:99 (tmm: 3) source-address 24.16.70.65 10.74.34.32:443 10.254.192.21:99 (tmm: 3) source-address 99.4.174.66 10.74.34.32:443 10.254.192.21:99 (tmm: 3) source-address 174.46.219.1 10.74.34.32:443 10.254.192.21:99 (tmm: 3) source-address 73.10.155.100 10.74.34.32:443 10.254.192.21:99 (tmm: 3) source-address 173.25.143.50 10.74.34.32:443 10.254.192.21:99 (tmm: 3) source-address 174.109.98.3 10.74.34.32:443 10.254.192.21:99 (tmm: 3) source-address 65.50.56.8 10.74.34.32:443 10.254.192.21:99 (tmm: 3) source-address 24.5.31.159 10.74.34.32:443 10.254.192.21:99 (tmm: 3) source-address 50.174.202.30 10.74.34.32:443 10.254.192.21:99 (tmm: 3) source-address 66.87.132.66 10.74.34.32:443 10.254.192.21:99 (tmm: 3) source-address 108.199.244.76 10.74.34.32:443 10.254.192.21:99 (tmm: 3)

 

13 Replies

  • Hi,

    on what criteria do you want to build a hash value?

    An example about implementing hash based persistence is described in the "F5 Local Traffic Manager Concepts Guide" and a sample iRule (i.e. based on a specific header) is provided as follows:
    when HTTP_REQUEST {
        persist hash [HTTP::header myheader]
    }
    

    Thanks, Stephan

  • Thnaks a lot Stephan,

     

    it really helps . let me get in touch with Application team and get the required info.

     

    I will contact you in case i need any other help after the information provided by application team.

     

  • HI Stephan,

     

    Application responded as below

     

    Unique Identifier value is “1” on both the servers WEB07 & WEB08 and there is no header value configured.

     

    So in this case if I add below irule will it work for Hash?

     

    when HTTP_REQUEST { persist hash [HTTP::header "1"] }

     

    • StephanManthey's avatar
      StephanManthey
      Icon for MVP rankMVP
      Hi vvskaladhar, you can use a webbroswer plugin (i.e. FireFox > Tools > WebDeveloper > Network) to track traffic between your browser and the servers. I guess you will find http-headers with session specific values. This value will be unique for a session on application layer and can be used for persistence. Now you simply take the name of the header to persist on. Alternatively you can just use the cookie insert mode as primary persistence profile. This will be the easiest solution but requires SSL-termination on the virtual server and a http-profile. Thanks, Stephan
    • StephanManthey's avatar
      StephanManthey
      Icon for MVP rankMVP
      Hi vvskaladhar, there is nothing specific in the response. I would expect i.e. a cookie-header with an ASP session ID or whatever. But as you are using an application to be accessed via web browser it would be fine to use a cookie persistence profile. You can create a new customized cookie persistence profile (mode "insert", cookie name i.e. "LB-COOKIE") and assign it as persistence profile to your virtual server. Thanks, Stephan
    • vvskaladhar_488's avatar
      vvskaladhar_488
      Icon for Nimbostratus rankNimbostratus
      OK sure stephan, i will talk with application team and ask to test with Cookie ,not sure they are always keen on hash persistence. but it was not working as expected with out an irule
  • Hi Stephan,

     

    One quick question

     

    HTTP Cookie Insert method

     

    If you specify HTTP Cookie Insert method within the profile, the information about the server to which the client connects is inserted in the header of the HTTP response from the server as a cookie. By default, the cookie is named BIGipServer, and it includes the encoded address and port of the server handling the connection. The expiration date for the cookie is set based on the timeout configured in the persistence profile. HTTP Cookie Insert is the default value for the Cookie Method setting.

     

    Just wanted to understand if I use this will F5 insert cookie ? as you know the application is not using any header in the browser/

     

    • StephanManthey's avatar
      StephanManthey
      Icon for MVP rankMVP
      Hi, if you assign the default cookie persistence profile (as just described) it will insert the cookie named exactly this way and containing the encoded information about pool and poolmember. This information can be encrypted and you can give the cookie a custom name (make sure it´s not a name used by one of your applications). It´s also recommended to use OneConnect (assigned by profile as well) to make sure cookie persistence works properly in case of clientside connection pooling (typically caused by proxies). Thanks, Stephan
  • HI stephan,

     

    Just got another hurdle , please find below mail

     

    This is the solution given to end user

     

    HI Robert ,

     

    We don;t need to modify anything on client or server level for configuring cookie persistency. We required those information only if we insists to Use Hash persistency which we are currently using and not working as expected.

     

    If we use cookie persistency F5 will insert cookie in client browser . and there is no need of any modification on client or server end. Please find below information about cookie insert method. This will make sure the user will be sent to same server as long as his session is valid . For new incoming traffic load balancing will work based on load balancing method ( roundrobin) .

     

    HTTP Cookie Insert method If you specify HTTP Cookie Insert method within the profile, the information about the server to which the client connects is inserted in the header of the HTTP response from the server as a cookie. By default, the cookie is named BIGipServer, and it includes the encoded address and port of the server handling the connection. The expiration date for the cookie is set based on the timeout configured in the persistence profile. HTTP Cookie Insert is the default value for the Cookie Method setting.

     

    Regards, Kaladhar

     

    Reply 1

    I agree, this would probably work for users accessing the website using web browsers.

     

    But web service client (SOAP) applications will not necessarily read the cookie header and/or pass the cookie back. Existing applications will almost certainly need to be updated to specifically do this.

     

    Reply 2

    ? Wouldn’t the web services not need persistence at all? The only sites we have that need to worry about the cookies would be the ones that use that report control.

     

    Reply3

    No, that's correct. The web services don't need persistence at all. We WANT those requests to be distributed across both web servers.

     

    But we need a mechanism that DOES accomplish the load distribution without the use of cookies. Since our web services don't use cookies.

    Can we add an irule that users hitting vip via browser should use cookie insert and all other request should use Source address persistence ?

     

    if yes please let me know if u have any similar irule handy

     

  • HI stephan,

     

    Just got another hurdle , please find below mail

     

    This is the solution given to end user

     

    HI Robert ,

     

    We don’t need to modify anything on client or server level for configuring cookie persistency. We required those information only if we insists to Use Hash persistency which we are currently using and not working as expected.

     

    If we use cookie persistency F5 will insert cookie in client browser . and there is no need of any modification on client or server end. Please find below information about cookie insert method. This will make sure the user will be sent to same server as long as his session is valid . For new incoming traffic load balancing will work based on load balancing method ( roundrobin) .

     

    HTTP Cookie Insert method If you specify HTTP Cookie Insert method within the profile, the information about the server to which the client connects is inserted in the header of the HTTP response from the server as a cookie. By default, the cookie is named BIGipServer, and it includes the encoded address and port of the server handling the connection. The expiration date for the cookie is set based on the timeout configured in the persistence profile. HTTP Cookie Insert is the default value for the Cookie Method setting.

     

    Regards, Kaladhar

     

    Reply 1

    I agree, this would probably work for users accessing the website using web browsers.

     

    But web service client (SOAP) applications will not necessarily read the cookie header and/or pass the cookie back. Existing applications will almost certainly need to be updated to specifically do this.

     

    Reply 2 ? Wouldn’t the web services not need persistence at all? The only sites we have that need to worry about the cookies would be the ones that use that report control.

     

    Reply3 No, that's correct. The web services don't need persistence at all. We WANT those requests to be distributed across both web servers.

     

    But we need a mechanism that DOES accomplish the load distribution without the use of cookies. Since our web services don't use cookies.

    Can we add an irule that users hitting vip via browser should use cookie insert and all other request should use Source address persistence ?

     

    if yes please let me know if u have any similar irule handy

     

  • Hi vvskaladhar,

     

    you can use "cookie insert" as standard persistence mode and "source address affinity" as fallback. You will find this setting in the virtual server´s resource section.

     

    Persistency can be maintained service specific.

     

    So one virtual server is using cookie insert. Another one source address. A third virtual has no persistence applied or uses a default and fallback method.

     

    Thanks, Stephan