Forum Discussion

mistergreg_6218's avatar
mistergreg_6218
Icon for Nimbostratus rankNimbostratus
Apr 20, 2011

iRule persistance based on HTTP header

I'm new to the F5 and am trying to persist HTTP requests based on an HTTP header. Basically, we have a custom app that is sending HTTP requests with a particular HTTP header that identifies the "device" that the data originated from. Due to how we process these requests, we want to load balance devices across the nodes in the pool (i.e. we want all requests from a particular device to "stick" to the same node in the pool for a period of time). In addition, the custom app that is sending these requests may send requests from different devices over the same persistent connection.

 

 

After reading the F5 doc, this seemed simple enough:

 

I created a universal persistence profile with the following rule:

 

 

 

when HTTP_REQUEST {

 

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

 

persist uie [HTTP::header "X-DeviceKey"]

 

}

 

}

 

 

 

 

Then I created a virtual server with this persistence profile, the default http profile, and a OneConnect profile. The pool itself is set up for Round Robin load balancing.

 

 

 

But it doesn't seem to be working. When I send HTTP requests for different devices from a single client, I am seeing all these requests sent to the same node in the pool (via "persist show all"). This is not what I expected. I'm testing with a small pool with 2 nodes and was expecting to see at least one device "stick" to a different node in the pool than the others.

 

 

 

What am I missing here?

 

 

 

Thanks in advance for any advice you can give me.

 

 

 

--Greg Williams

 

application delivery
dev
devops
iRules

5 Replies

Sort By
  • hooleylist's avatar
    hooleylist
    Icon for Cirrostratus rankCirrostratus
    Apr 20, 2011
    Hi Greg,

     

     

    That config looks good.

     

     

    Are you seeing all requests sent to the same pool member? What does the 'b persist all show all' output show? Can you post a sanitized copy of the output? Do you have a fallback persistence method specified on the VS?

     

     

    Aaron
  • mistergreg_6218's avatar
    mistergreg_6218
    Icon for Nimbostratus rankNimbostratus
    Apr 21, 2011
    Yes. I am seeing all of these requests going to the same pool member. For my testing, I am sending a small number of requests from different devices on the same persistent connection. Given that my pool has 2 members in it and is configured as Round Robin, I expected that I would see these different requests spread across both members.

     

     

    One thing to note is that the nodes in my new pool also belong to another pool that is being used by a different VS at the same time. The other VS is for any TCP traffic and uses source addr persistence, where as my VS is only capturing HTTP traffic on port 80. In addition, the other VS does not have a OneConnect profile whereas my VS does. Could that other VS be affecting how my VS is processing traffic?

     

     

     

    My VS is using source address persistence as the fallback persistence method. However, when I send 4 requests from different devices and do "persist all show all", I see 4 universal entries in addition to other entries for requests to the other pool.

     

     

     

    I've attached a small file with the "persist all show all" output for the nodes in my pool. You'll see other source addr entries for these nodes in there, due to these nodes being actively used by another pool. Before I ran "persist all show all", I had just send 4 requests with different device ids on the same connection. In this output, you can see 4 universal entries that correspond with those requests. So that makes me think that my persist rule is triggering correctly. However, they are all mapped to the same member.

     

     

     

    Thanks.

     

     

     

    --Greg W

     

     

     

     

     

  • hooleylist's avatar
    hooleylist
    Icon for Cirrostratus rankCirrostratus
    Apr 22, 2011
    Hi Greg,

     

     

    Thanks for the detailed explanation. Do you have any 'match across' options enabled on the source address persistence profile? Are you using the same source address persistence profile on both virtual servers?

     

     

    Can you try using separate source address persistence profiles and retest to see if the issue continues? If so, can you try removing the fallback source address persistence profile from the new VS you're setting up as a test?

     

     

    It might be helpful to open a case with F5 Support to get a more detailed review of your configuration.

     

     

    Aaron
  • mistergreg_6218's avatar
    mistergreg_6218
    Icon for Nimbostratus rankNimbostratus
    Apr 25, 2011
    Hi Aaron,

     

     

    There are no "match across" option enabled on any of the persistence profiles I'm using. But I was using the same source address persistence profile on both virtual servers.

     

     

     

    So I created a different source address persistence profile for my virtual server and set it as the fallback persistence profile. I still saw the same behavior as before.

     

     

     

    However, the good news is that when I set the fallback persistence profile to None on my virtual server, then it started working as I expected it to. 2 of my 4 test requests went to one node and the other 2 went to the other.

     

     

     

    I guess I don't understand why it is working this way. I thought the fallback persistence profile only took effect if my iRule did not match. Is there something I need to do in my iRule to prevent it from using the fallback persistence profile?

     

     

     

    Thanks.

     

     

     

    --Greg

     

  • mistergreg_6218's avatar
    mistergreg_6218
    Icon for Nimbostratus rankNimbostratus
    Apr 26, 2011
    Aaron,

     

     

    Seems like I should be able to get the equivalent of what I intended by choosing None for the fallback persistence profile and then updating the rule to this:

     

     

    when HTTP_REQUEST {

     

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

     

    persist uie [HTTP::header "X-DeviceKey"]

     

    }

     

    else {

     

    persist source_addr

     

    }

     

    }

     

     

    This appears to be working for me now.

     

     

    Thanks for all your help.

     

     

    --Greg