Forum Discussion
Simon_83666
Nimbostratus
Jan 12, 2009LB::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]"
}
}
- hoolio
Cirrostratus
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. - Arik_Barzilay_6
Nimbostratus
I'm stuck with same problem: I have 2 active nodes, but 'LB::reselect' keeps selecting the same node for each request. - Simon_83666
Nimbostratus
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_18Historic 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.
- Simon_83666
Nimbostratus
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_18Historic F5 AccountPerhaps.... 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.
- Simon_83666
Nimbostratus
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 ?
Recent Discussions
Related Content
DevCentral Quicklinks
* Getting Started on DevCentral
* Community Guidelines
* Community Terms of Use / EULA
* Community Ranking Explained
* Community Resources
* Contact the DevCentral Team
* Update MFA on account.f5.com
Discover DevCentral Connects