Forum Discussion

Simon_83666's avatar
Simon_83666
Icon for Nimbostratus rankNimbostratus
Jan 12, 2009

LB::reselect based on HTTP response code

Hi,

I've created the following irule in trying to direct the http traffic from one node to another if a 5xx http response is encountered, however, it seems the request wuold always go back to the original node agaian. There are only 2 nodes in the pool and I'm using a cook-insert profile to persist the connection.

I'm sure there's a simple explanation to the issue but since I don't have much experience with iRule, any help is appreciated.

Thanks

 
  
 when CLIENT_ACCEPTED { 
 set retries 0 
 } 
  
 when HTTP_REQUEST { 
 set client_ip [IP::client_addr] 
 set http_method [HTTP::method] 
 set http_host [HTTP::host] 
 set http_uri [HTTP::uri] 
 set http_request [HTTP::request] 
  
 } 
  
 when HTTP_RESPONSE { 
 set http_status [HTTP::status] 
 if { [matchclass $http_status equals $::ebus_dg_http_error_code] } { 
 incr retries 
 log local0. "$http_status error caught: retry $retries out of 10, Client IP - $client_ip , $http_method $http_host$http_uri" 
 if { $retries < 10 } { 
 HTTP::retry $http_request 
 } 
 }  
 } 
  
 when LB_FAILED { 
  set current_server [LB::server name] 
  log local0. "$current_server seems to be having a problem..." 
  log local0. "HTTP request is $http_request" 
 } 
  
 when LB_SELECTED { 
   if { $retries >= 1 } { 
 set current_pool [LB::server pool] 
 LB::mode rr 
     LB::reselect pool $current_pool 
 log local0. "Reselected: LB_server is [LB::server name]" 
   }  
 } 
  
 

7 Replies

  • I think you can disable persistence in LB_SELECTED using 'persist none' to prevent the cookie persistence from forcing the request back to the original pool member. I'm not certain on this, but I think you would need to re-enable persistence using 'persist add cookie insert $cookie_name' once the request has been successfully handled. Perhaps you could do this in HTTP_RESPONSE if 'if { [matchclass $http_status equals $::ebus_dg_http_error_code] }' if false.

     

     

    Aaron
  • I'm stuck with same problem: I have 2 active nodes, but 'LB::reselect' keeps selecting the same node for each request.

     

     

    Tried 'persist none' and/or 'LB::detach' right before reselect, but it did not help.

     

    BTW, I'm using persistence of type 'uie' (instead of 'cookie'), and running LTM version 9.4.4+HF1.

     

     

    when LB_SELECTED {

     

    log local0.info "svr=[LB::server] poolSize=[active_members $myPool]"}

     

     

    LB::mode rr

     

    persist none

     

    LB::detach

     

    LB::reselect pool $myPool

     

    }
  • Would it be more logical to use the " LB::down " to mark the node down once an error is detected ? My question is how to re-enable it once it's back online as the stand http monitor doesn't seem to do that.
  • Deb_Allen_18's avatar
    Deb_Allen_18
    Historic F5 Account
    @sh710: The standard monitor should indeed mark the pool member back up if the expected response is rec'd, although another connection traversing the iRule may immediately mark it back down based on the iRule logic.
  • deb: hmm...what I found is quite different - while the monitor seems to mark the node up ( I can tell by the green status on the pool member) , the priority group status was "inactive" . And one would need to select the node and press the "enable' button to re-activate the node. Could this be caused by a misconfiguration somewhere ?
  • Deb_Allen_18's avatar
    Deb_Allen_18
    Historic F5 Account
    Perhaps.... i'd say open a case on that. We depend for some protocols/apps on this form of passive monitoring (using iRules to mark down then monitor to mark back up) and I haven't heard any reports of that behaviour before.

     

     

    /d

     

     

     

  • In regard to the "LB::down" command, if I just use "LB::down" instead of the format "LB::down pool member " then whoudl that be a possible cause for the above behavior where the node is inaccessible even after the monitor has marked it up ?