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

Filter by:
  • Solution
  • Technology
Answers

iRule to hit a specific webserver instance directly

I'm creating an iRule to allow the Ops guys to hit a specific webstore instance directly, by appending a query string to the first page hit, which will then set the proper session cookie to persist on that instance. The request will come in looking like this: http://FQDN/shop/index.jsp categoryId=2255956&server=01_03. We want to strip the query string, and assign a pool member based on the value passed [01_03 = app01, instance03]. Rather than map server numbers to IP addresses, we could just as easily pass the IP and port in the query string too.

I prefer to http://FQDN/shop/index.jsp?categoryId=2255956&server=10.48.162.16:7101 This would avoid having to modify the rule as you add and remove pool members, and it could even be applied to different VIPs. We're looking for something easier to manage. But not sure on what this iRule would look like? Any idea's?

Trying to avoid this, in a cleaner smaller version:

when HTTP_REQUEST { switch -glob [string tolower [HTTP::uri]] { "_server=01_01" { HTTP::uri [string map -nocase {"&server=01_01" ""} [HTTP::uri]] pool lvs2prdtc3-10.48.172.120.7300 member 10.48.162.16:7101 } "_server=01_02" { HTTP::uri [string map -nocase {"&server=01_02" ""} [HTTP::uri]] pool lvs2prdtc3-10.48.172.120.7300 member 10.48.162.16:7102 } "_server=01_03" { HTTP::uri [string map -nocase {"&server=01_03" ""} [HTTP::uri]] pool lvs2prdtc3-10.48.172.120.7300 member 10.48.162.16:7103 } "_server=02_01" { HTTP::uri [string map -nocase {"&server=02_01" ""} [HTTP::uri]] pool lvs2prdtc3-10.48.172.120.7300 member 10.48.162.17:7101 } "_server=02_02" { HTTP::uri [string map -nocase {"&server=02_02" ""} [HTTP::uri]] pool lvs2prdtc3-10.48.172.120.7300 member 10.48.162.17:7102 } "_server=02_03" { HTTP::uri [string map -nocase {"&server=02_03" ""} [HTTP::uri]] pool lvs2prdtc3-10.48.172.120.7300 member 10.48.162.17:7103 } default { pool lvs2prdtc3-10.48.172.120.7300 } } }

here is exactly what we need:

1) request comes in with IP:port appended as query string: http://trus-lvs2prd.gsipartners.com/shop/index.jsp?categoryId=2255956&server=10.48.162.16:7103

2) we parse the query string and store the IP:port as a variable set target_member = 10.48.162.16:7103

3) pool will always be the same, so set that as a variable too set my_pool = lvs2prdtc3-10.48.172.120.7300

4) we strip the query string, then assign pool and member, with something like this

switch -glob [string tolower [HTTP::uri]] { "*server=$target_member" { HTTP::uri [string map -nocase {"&$target_member" ""} [HTTP::uri]] pool $my_pool member $target_member }

My syntax is wrong, and I don't know if we can use variables in the switch and string map. That's where I need help

1
Rate this Question

Answers to this Question

placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER

Hi,

you can try this one:

when CLIENT_ACCEPTED { 
    set default_pool [LB::server pool]
}

when HTTP_REQUEST {
    set target_member [URI::query [HTTP::uri] server]
    if {!($target_member eq "")} {
        pool $default_pool member $target_member
        HTTP::uri [tring map -nocase [list "&server=$target_member" "" ] [HTTP::uri]]
    }
}
0
Comments on this Answer
Comment made 16-Oct-2015 by Reginald Sibley 236
Please explain the " ". What will happen in this logic?
0
Comment made 16-Oct-2015 by Stanislas Piron 10106
In if {!($target_member eq "")}, if there is no target member, the variable is blank.
0
Comment made 27-Oct-2015 by Reginald Sibley 236
Thanks you very much for your assistance. It worked perfectly!
0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER

I had a similar need and solved it with a slightly different solution.

Developers need to update a set of web servers that are in a pool but want to perform a final test before making it available to production. Typically we take pool members offline for maintenance by lowering their priority so that requests won't go to them (they go to the higher priority pool members and as long as there are members available at a higher priority, load balancing will select them).

There is also persistence (in our case cookie, but I don't think it matters) on the virtual server. That made the solution fairly straightforward.

The tester who wants to verify one of these 'offline' members can select that specific member and then persistence will retain that member for the duration of their browser session (until they close their browser).

The selection is made via a specific URI from the browser by specifying the IP address of the member at the end of the string ( hostname/path/F5/select/IPaddress_of_member ).

when LB_SELECTED {
   if {[URI::decode [HTTP::uri]] contains "/F5/select/"} {
      LB::reselect pool [LB::server pool] member [string range [HTTP::uri] [expr [string last / [HTTP::uri]] +1] end]
   }
}
0