Irule issue

Can you try this iRule which should log all of the relevant details and reply with the anonymized log output:

  
  when HTTP_REQUEST {  
    
     log local0. "[IP::client_addr]:[TCP::client_port]: [HTTP::method] request to [HTTP::host][HTTP::uri]\  
        with CMS cookie [HTTP::cookie CMS]"  
    
      Check the requested URI  
     switch -glob [HTTP::uri] {  
        "/citsitdocumentation*" -  
        "/psoftdms*" -  
        "/cso*" {  
           pool CMS-http-pool member 10.103.42.100 80  
           log local0. "[IP::client_addr]:[TCP::client_port]: URI match, selecting specific member 10.103.42.100 80"  
        }  
        default {  
           pool CMS-http-pool  
           log local0. "[IP::client_addr]:[TCP::client_port]: No URI match, using pool"  
        }  
     }  
  }  
  when SERVER_CONNECTED {  
     log local0. "[IP::client_addr]:[TCP::client_port]: Connected to server [IP::server_addr]:[TCP::server_port]"  
  }  
  when HTTP_RESPONSE {  
     log local0. "[IP::client_addr]:[TCP::client_port]: status: [HTTP::status], CMS cookie: [HTTP::cookie CMS]"  
  }  
  

Thanks,

Aaron

(edited to add *'s to the last two URI checks)

Renith,

 

 

I had a similar problem a few weeks ago (sorry I never got a around to posting a followup here -- if not buried in snow, then I'm buried in work). I opened a ticket with F5 asking why specifying a node kills cookie persistence. I was told, "This is expected behavior...The general reasoning behind this, per my conversation with our engineering services team, is that if a customer decides to use an iRule to select a server, which supercedes all other LB functions on the box, they should be planning to deal with the additional items that the box would normally implement as well, such as persistence and checking pool member status."

 

 

In other words, once you select the node, the persistence profile will not function. More accurately (based on my observations) the persistence profile will not function until the BIGIP once again makes the load balancing decision. That's why you'll see the cookie when the browser connects to the "wrong" web server. The fix I used: set the cookie in the iRule to insure that the cookie is set on the first HTTP response. I might add that I did not include code to check pool member status because the code was written at the request of the web team to check specific web server functionality once they had been brought back up from maintenance. However, since your selection criteria is URI, you should be aware that the BIGIP won't honor the node status [if down] once you've manually selected the node (per F5 above). You might want to add a node check; see LB::status.

 

 

 

when RULE_INIT {

 

 

set ::bakecookie 0

 

set ::nodeTo ""

 

 

}

 

 

when HTTP_REQUEST {

 

if { [ findstr [string tolower [HTTP::query]] "node=" 5 2 ] != "" } {

 

log local0. "Found [ findstr [string tolower [HTTP::query]] "node=" 0 7 ]"

 

 

need to remove any stale cookies: lumwebprod, fos.web.server, fos.secure.web.server

 

if {[HTTP::cookie exists "fos.web.server"]} {

 

HTTP::cookie remove "fos.web.server"

 

}

 

if {[HTTP::cookie exists "fos.secure.web.server"]} {

 

HTTP::cookie remove "fos.secure.web.server"

 

}

 

if {[HTTP::cookie exists "lumwebprod"]} {

 

HTTP::cookie remove "lumwebprod"

 

}

 

if {[HTTP::cookie exists "fcspersistslider1"]} {

 

HTTP::cookie remove "fcspersistslider1"

 

}

 

if {[HTTP::cookie exists "JSESSIONID"]} {

 

HTTP::cookie remove "JSESSIONID"

 

}

 

if {[HTTP::cookie exists "UserAgentId"]} {

 

HTTP::cookie remove "UserAgentId"

 

}

 

if {[HTTP::cookie exists "runId"]} {

 

HTTP::cookie remove "runId"

 

}

 

 

switch [ findstr [string tolower [HTTP::query]] "node=" 5 2] {

 

01 { set ::nodeTo 192.168.100.2 }

 

02 { set ::nodeTo 192.168.100.5 }

 

03 { set ::nodeTo 192.168.100.8 }

 

04 { set ::nodeTo 192.168.100.11 }

 

}

 

 

HTTP::path "/"

 

pool Lum_prod_pool_80 member $::nodeTo 80

 

log local0. "Setting pool member node to $::nodeTo"

 

set ::bakecookie 1

 

 

}

 

}

 

 

 

when HTTP_RESPONSE {

 

 

if { $::bakecookie == 1 } {

 

scan $::nodeTo "%u.%u.%u.%u" a b c d

 

set cookie "[format %u [expr ($d<<24)|($c<<16)|($b<<8)|$a]].[expr 256*80].0000"

 

HTTP::cookie insert name "lumwebprod" value $cookie path "/"

 

All done for first response

 

set ::bakecookie 0

 

}

 

}

 

 

 

Regards,

 

Jason

Thanks Aaron \ Jason.

 

 

 

Renith

Hi Jason,

 

 

Thanks for the follow up. I think the case could be made that using the pool command to select a specific member along with explicitly calling the persist command should work. I'll try opening a case with F5 Support requesting this. Can you post your case number so I can reference it?

 

 

Also, in the code you posted, I think you'll want to replace all of the global variables with local ones, so one connection doesn't trample on the variable values from another connection:

 

 

 
 when CLIENT_ACCEPTED { 
  
    set bakecookie 0 
    set nodeTo "" 
 }  
 when HTTP_REQUEST { 
 ... 
 01 { set nodeTo 192.168.100.2 } 
 02 { set nodeTo 192.168.100.5 } 
 03 { set nodeTo 192.168.100.8 } 
 04 { set nodeTo 192.168.100.11} 
 ... 
 

 

 

Thanks,

 

Aaron

Aaron,

 

 

My case was C616842.

 

 

Thanks for the tip on the variable scoping. I had been looking for official documentation on variable scoping and found none. Now that you bring up it up, I searched in the forums and found previous postings from you on the subject.

 

 

Regards,

 

Jason