Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

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>"
  }
}
share|improve this question
add comment

1 Answer 1

up vote 3 down vote accepted

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

share|improve this answer
    
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 6 '12 at 16:54
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.