F5 BIG_IP persistence iRules applied but not affecting selected member

Question

I have a virtual server. I have 2 iRules (see below) assigned to it as resources.

From the server log it looks like that the rules are running and they select the correct member

from the pool after persisting the session (as far as I can tell based on my log messages), but the requests are ultimately directed to somewhere else.

Here's how both rules look like:

when HTTP_RESPONSE {

  set sessionId [HTTP::header X-SessionId]

  if {$sessionId ne ""} { 

    persist add uie $sessionId 3600 

    log local0.debug "Session persisted: <$sessionId> to <[persist lookup uie $sessionId]>"

  }

}



when HTTP_REQUEST {

  set sessionId [findstr [HTTP::path] "/session/" 9 /]

  if {$sessionId ne ""} {

     persist uie $sessionId

     set persistValue [persist lookup uie $sessionId]

     log local0.debug "Found persistence key <$sessionId> : <$persistValue>"
  }
}

According to the log messages from the rules, the proper balancer members are selected.

Note: the two rules can not conflict, they are looking for different things in the path. Those two things never appear in the same path.

Notes about the server: * The default load balancing method is RR. * There is no persistence profile assigned to the virtual server.

I'm wondering if this should be adequate to enable the persistence, or alternatively, do I have to combine the 2 rules and create a persistence profile with them for the virtual server?

Or is there something else that I have missed?

Edit: as it turns out, I have missed something. Keep-alive connections interfere with the rules, so as this support case suggested, I've modified the rules a bit:

when HTTP_REQUEST {

  set sessionId [findstr [HTTP::path] "/session/" 9 /]

  if {$sessionId ne ""} {
     # added this line:
     LB::detach

     persist uie $sessionId

     set persistValue [persist lookup uie $sessionId]

     log local0.debug "Found persistence key <$sessionId> : <$persistValue>"
  }
}

score 3 · Accepted Answer · answered Oct 05 '12 at 17:01

So when you're looking at the log entries you're seeing the expected information, but the traffic is still ending up somewhere else? Where is it ending up? Also, why two persistence entries for the same session? That may be confusing the system.

You shouldn't need a persistence profile assigned to the Virtual, the iRule should override that anyway, if you have persistence set up there. What do your log entries look like? Also, have you posted to DevCentral yet? More people with F5 experience may see it there. - http://devcentral.f5.com

Have you tried changing the names of the variables? You're using "sessionID" as the variable name in both cases. Variables within iRules are session based, meaning that for the duration of your session with the system the variables remain pinned in memory. If you have both of those iRules executing you'll be over-writing the same variable name with data for both the request and response, which could make your logic checking to see if the sessionID is empty useless. Meaning, if the sessionID gets set on request, but not response, but the response runs the code checking to see if it's empty...it's not going to fail the way you want it to. Different variable names are a good thing.

Other than that, though, your syntax is correct, and unless that issue is causing the confusion it looks like the issue is not with the iRules themselves but with the way the persistence is interacting with the requests.

Colin

Turns out that the the rules were working properly, but Apache was misconfigured. Still, it's good to know about the scope of the variables. It could cause rad to reproduce issues later. — zoli, Oct 06 '12 at 16:54

score 1 · Answer 2 · answered Mar 01 '15 at 17:57

In this situation, on the very first HTTP request, you will never log the correct persistence entry based on the above iRules. The reason for this is that persistence is set in another event later on because the F5 has not yet decided which pool member this request will be load balanced to. Since this decision has not been made, it is impossible to create the persistence entry yet. This means that during the life of the entire HTTP_REQUEST event, you will never be able to retrieve the persistence value. You can only do this AFTER the HTTP_REQUEST event has completed and the next event fires. This is why it was working, even though you were not seeing the expected debug data. Instead, try checking it in LB_SELECTED. You will see the entry has been created in that event.

F5 BIG_IP persistence iRules applied but not affecting selected member

2 Answers2