Learn F5 Technologies, Get Answers & Share Community Solutions Join DevCentral

Filter by:
  • Solution
  • Technology
Answers

Election Hash rule

I'm trying to implement the election hash rule on v9.0.5 and discovered it requires v9.4.2+. First, does anyone know what about the rule requires the later version of TMOS and secondly will a normal loop or static array instead of the enumeration of the active members list work? In other words, is there a way to implement this on an earlier version if the customer is not ready to upgrade until after holiday season, but wants to try this type of rule.

Here's the rule I'm trying to implement on v9.0.5

# Election Hash iRule
# Compute Hash - MD5
#
# MD5 calculation of Server + URI
# Rule selects Server that scores highest
#
# S = Current high score
# N = Node being evaluated
# W = Winning node
#
when HTTP_REQUEST timing on {
set S ""
foreach N [active_members -list <pool>] {
if { [md5 $N]HTTP::uri[] > $S } {
set S [md5 $N]HTTP::uri[]
set W $N
}
}
pool <pool> member [lindex $W 0] [lindex $W 1]
}
0
Rate this Question

Answers to this Question

placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER
Hi

The -list switch on the active_members is not available until after v9.4.2

Yes it's possible to create static array and loop through the array to determine the good nodes list.

something like

 
.
.
.
set GOOD_NODES {}
set NS {10.10.12.13 10.10.12.14 10.10.12.15}
foreach N $NS {
if { [LB::status pool <pool> member $N 80] eq "up" } {
lappend GOOD_NODES $N
}
}
.
.
.


Hope this helps
#CB


0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER
Thanks very much for the reply. Will give it a try.
0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER
Nice idea, CB.

mharris, you might try adding that pool check loop to CLIENT_ACCEPTED so it runs once per TCP connection instead of running it for every HTTP request in HTTP_REQUEST. I imagine there might be a significant overhead in doing this even for every TCP connection. The downside to running it just once per TCP connection is that for very long clientside TCP connections, the pool state might be wrong.

It would be a good idea to use timing (Click here) to check how much CPU time this rule would use.

Aaron
0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER
Would you agree that this is the way to insert the static array in the original election hash rule?

when HTTP_REQUEST timing on {
set GOOD_NODES {}
set NS {192.168.1.7 192.168.1.10 192.168.1.11}
foreach N $NS {
if { [LB::status pool <pool> member $N 80] eq "up" } {
lappend GOOD_NODES $N
}
set S ""
foreach N [GOOD_NODES]{
if { [md5 $N]HTTP::uri[] > $S } {
set S [md5 $N]HTTP::uri[]
set W $N
}
}
pool <pool> member [lindex $W 0] [lindex $W 1]
}
}
0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER
In case anyone was interested, here's the final solution for versions prior to v9.1.x

when HTTP_REQUEST timing on {
set NS {172.16.1.1 172.16.1.2 172.16.1.3}
set S ""
set port "80"
if { [active_members pool_name] < 3 } {
log local0. "Hash Election disabled, one or more nodes down"
pool backup_pool_name
}
else {
foreach N $NS {
if { [md5 $N[HTTP::uri]] > $S } {
set S [md5 $N[HTTP::uri]]
set W $N
}
}
pool default_pool_name member [lindex $W 0] $port
# if you would like to log the node that is selected:
# log local0. "lindex is [lindex $W 0], lindex2 is $port"
}
}
0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER
Hi Mark,
You can also add this to the current code share.

#CB
0