Forum Discussion

Lotfi_Bouhaddad's avatar
Lotfi_Bouhaddad
Icon for Nimbostratus rankNimbostratus
Feb 20, 2007

Persistence using IRule

Hi everyone,

 

 

I'm a newbie in irule programming and i need some help to do a persistence based on the http field X-Nokia-MSISDN.

 

 

how can i do to check the value of this field in the http header and depend to the value the F5 will make persistence.

 

 

her an example of the http header with X-Nokia-MSISDN having a value 33699999999

 

 

 

GET http://www.google.fr HTTP/1.1

 

user-agent: F5Ffff

 

X-Nokia-MSISDN: 33699999999

 

X-Up-Calling-Line-Id: 33699999999

 

Host: www.google.fr

 

Pragma: no-cache

 

Cache-control: no-cache

 

 

 

 

Thanks everyone for your help

 

 

Regards

 

 

Lotfi
  • You should be able to persist without setting the variable:

    
    when HTTP_REQUEST {
      if { [HTTP::header exists "X-Nokia-MSISDN"] } {
        persist uie [HTTP::header "X-Nokia-MSISDN"]
      }
    }
  • Hi ,

     

     

    Thanks a lot for your answers.

     

     

    so this mean that the F5 will extract the value from the X-Nokia-MSISDN field

     

     

    Is it a recogonised field in all ltm versions or do i have to worry about the version ??

     

     

    and if i want to say if the X-Nokia-MSISDN is nempty or does not exist then perssite on least connection.

     

     

    How can i do it

     

     

    Thanks again

     

     

     

    regards

     

     

    Lotfi
  • Yes, the value of the header will be the data in the persistence table. I believe HTTP::header is available in all 9.x versions.

    I'm not sure what you mean regarding persisting on least connections. Least connections is a lb method, not a persist method. The LB method on your pool settings will dictate the server, so if you don't have a valid value supplied in X-Nokia-MSISDN you can persist the connection in another way, such as client TCP port, or source address, destination address, etc. In the example below, the other conditions persist via the client's source address.

    
    when HTTP_REQUEST {
      if { [HTTP::header exists "X-Nokia-MSISDN"] } {
        if { [HTTP::header "X-Nokia-MSISDN"] != "" } {
          persist uie [HTTP::header "X-Nokia-MSISDN"]
        } else { persist source_addr }
      } else { persist source_addr }
    }
  • I know this is an old thread, but will persist uie also work in 10.x or would there be a new way of accomplishing the same?

     

     

    Also, I'd like to use an alternate pool when the URI matches to use a different algorithym...would this then be accurate?

     

     

    Using the same as example:

     

     

    when HTTP_REQUEST {

     

    if { [HTTP::header exists "X-Nokia-MSISDN"] } {

     

    persist uie [HTTP::header "X-Nokia-MSISDN"]

     

    pool alternate_pool

     

    }

     

    }
  • hoolio's avatar
    hoolio
    Icon for Cirrostratus rankCirrostratus
    Hi Jason,

    That should work find in 10.x. I'd suggest checking that the header value is not null. You should also set a timeout on the persistence record:

    when HTTP_REQUEST { 
       if { [HTTP::header value "X-Nokia-MSISDN"] ne ""} { 
          persist uie [HTTP::header value "X-Nokia-MSISDN"] 3600  
          pool alternate_pool
       }
    }
    

    Also, make sure to add a OneConnect profile if you're persistence based on a layer 7 property. If you're using SNAT on the serverside connections, you can use the default OneConnect profile. If you're not using SNAT, then create a custom OneConnect profile with a /32 source mask.

    Aaron
  • Can I handle the following then with the suggested persistency and OneConnect solution?

     

     

    I have a Virtual Server on 443.

     

    Behind it is a pool of web servers set as Observed (member) and handling regular requests.

     

    I want to apply an iRule that finds a URI path beginning "/stream" and then apply the persistency based on a header which changes the connection to a different pool with Least Connections defined.

     

     

    Can I set persistency/OneConnect on only a specific URI of a VIP and keep everything not matching the URI follow the default settings of the Virtual Server?

     

  • hoolio's avatar
    hoolio
    Icon for Cirrostratus rankCirrostratus
    Hi Jason,

     

     

    I think you need OneConnect for all requests if you want to switch pools based on something in each HTTP request. If you don't want to reuse serverside connections for one pool, you could use LB::detach to do this.

     

     

    http://devcentral.f5.com/wiki/default.aspx/iRules/lb__detach

     

     

    Aaron
  • Our app is stateless. We don't want to tie a user to one server unless OneConnect on all connections through the VIP is required.

     

    Our normal web traffic is stateless coming in to multiple virtual directories (ASP.NET applications) behind the same VIP...we are creating a new streaming handler that will get specific calls handed to it based on the URI that was sent to the handler-configured virtual directories.

     

    The streaming request we would like to tag/persist to one web server so when it gets cut and reconnects, we reconnect to the same server in the pool so that it's subscription keys of the feed are still valid to a down-stream server (without that down-stream server needing to be told a different web server to publish to for that key/subscriber)

     

     

    We use header based pool selection without OneConnect today (different VIP/app)...stateless requests...these requests pass a client identification header that we look at then look up a data group list value to determine which pool to send the request to, then the pool has Observed (member) as it's algorithym...we process well over 350 request/sec with less than 30ms latency on the networking gear (LB, switches, etc) so we're pretty happy with the iRule setup (without it using OneConnect).

     

     

    So, unless OneConnect is required for setting up server sticky/persistence, we'd rather not use it...we don't know much about it though (other than it pools sever-side connections) so I'm open to learn more about it if that's the solution we need to go with.