post about how to modify default pool behaviour

Simply add a "default" statement at the end of the rule.

default { pool default_pool }

Just to clarify Chris' answer: assuming you're using a switch statement to check the URI you would add a default case to the switch to select a different default behavior than using the default pool:

 

 

http://devcentral.f5.com/wiki/default.aspx/iRules/switch

 

 

Aaron

I really should reread my posts to ensure good english before I post!(How embarrassment)

 

 

OK. Yes I'm using a switch statement to the URI direction and I know the end statement has to be a default behaviour and the behaviour I wish is to drop/discard the traffic and I can see in the examples that I can easily do that. So thank you both.

 

 

One more thing, on the VIP there has to be a pool configured but I don't ever want traffic ending up on the server unless it has a correct URI (SECURITY!!) so what does one do here?

 

 

Oh and one more thing (good one Columbo) the behaviour of the switch statement is it will drop out at the first match? So put the more specific URI at the top of the statement with less specific at the bottom correct?

 

 

Oh and one final question, is there a better way. I'm mean I'm already half blind just typing this thing and on going maintenance will be painfull. Can one achieve the same result more elegantly than a switch statement and 30 different pools all on 1 VIP sitting on 2 different servers, without spending money that is!!! Couldn't possibiliy drop a couple of thou for some more certs and have 5 or 6 VIPs, NOOO I must go blind and half crazy and never make a mistake that breaks this thing.

 

 

Sorry got a little frustrated at the end there.

 

Thanks

 

David.

Hi David,

 

Is it possible to post your code. It might make it easier for us to guide you to your answers.

 

 

Thanks,

 

Bhattman

Some elements have been removed to protect the innocent.

 

This is a migration from a single proxy with cert with no load balancing to an GTM/LTM implementation with all the benefits.

 

So 2/3 of the apps are on 1 node (and consequently 2/3 of the pools) and the remainder on another.

 

I'm trying to assist the web developers (insert expletive) to have more control over how they do work on a particular app and not take down the whole house of cards by setting up different monitors for each of the apps.

 

 

I think it might really be false economy.

 

 

David.

 

 

when HTTP_REQUEST {

 

Check the requested path (set to lowercase)

 

-glob: allow string pattern matching

 

switch -glob [string tolower [HTTP::path]] {

 

/apps/applytojoin {

 

log local0. "Matched applytojoin pool for /apps/applytojoin"

 

pool lpl_site1_https_applytojoin

 

}

 

/apps/applytonotjoin {

 

log local0. "Matched updatedetails pool for /apps/applytonotjoin"

 

pool lpl_site1_https_applytonotjoin

 

}

 

/apps/applytomightjoin {

 

log local0. "Matched updatedetails pool for /apps/applymightjoin"

 

pool lpl_site1_https_applytomightjoin

 

}

 

/apps/contactme {

 

log local0. "Matched updatedetails pool for /apps/contactme"

 

pool lpl_site1_https_contactme

 

}

 

/apps/applycontactthem {

 

log local0. "Matched updatedetails pool for /apps/contactthem"

 

pool lpl_site1_https_contactthem

 

}

 

---SNIP--- remove 25 pools

 

}

 

default {

 

log local0. "dropped traffic for [HTTP::uri]"

 

drop

 

}

 

}

 

}

 

Okay, to answer some of the questions:

 

 

If you don't want traffic going to a default pool, just make sure the default action in your logic case (switch, if/else, whatever) is to drop, and you'll never get things sent to the default pool. The only time the default pool is used is when there is no explicit balancing decision made within the iRule.

 

 

Yes, switch matches from the top down.

 

 

Yes, there is a better way, assuming you are going to end up with LOTS of matches. If you put these into a class you can write the logic once, and expand the class as needed with new URI/pool pairs without ever modifying the code.

 

 

It'd look something like this:

 

 

when HTTP_REQUEST {
  set myPool ""
  set myPool [class search -value myClass starts_with [string tolower [HTTP::path]]]
  if {$myPool ne ""}
    pool $myPool
  } else {
    drop
  }
}

 

 

With a class that looks like:

 

 

class myClass {
"/apps/applytojoin" := "lpl_site1_https_applytojoin"
"/apps/applytonotjoin" := "lpl_site1_https_applytonotjoin"
...
etc.

 

 

This way as you get new path/pool combos, you just add them to the class and the logic stays the same. Make sense?

 

 

Colin

 

 

 

 

Thank you Colin.

 

Your solution looks like a winner.

 

Now what if I want to also have an IP Address check to restrict access some of the URIs?

 

 

I would need some other global variable that can be read to denote a URI that has an extra check associated and then given that to perform the check for IPAddress.

 

So standing on the sholders of giants is my logic/syntax OK here?

 

 

when HTTP_REQUEST {

 

set myPool ""

 

set myURI_Restricted ""

 

set myClassIPAddressCheck ""

 

set myPool [class search -value myClassURI starts_with [string tolower [HTTP::path]]]

 

set myURI_Restricted [class search -value myClassURI_Restricted starts_with [string tolower [HTTP::path]]]

 

if {$myPool ne ""} and {myURI_Restricted ne ""}

 

if { ([class search -value myClassIP_Restricted equals [IP::client_addr]]} {

 

log local0. "Allowing [IP::client_addr] to $mypool pool"

 

pool myPool

 

} else {

 

drop

 

}

 

} elseif {$myPool ne ""}

 

pool $myPool

 

} else {

 

drop

 

}

 

}

 

 

class myClassURI {

 

"/apps/applytojoin" := "lpl_site1_https_applytojoin"

 

"/apps/applytonotjoin" := "lpl_site1_https_applytonotjoin"

 

"/apps/restricted" := "lpl_site1_https_restricted"

 

 

class myClassURI_Restricted

 

"/apps/restricted" := "Yes"

 

 

class myClassIP_Restricted

 

"66.102.11.0/24"

Bugger!

 

why do my code posts never retain the formatting!!!

 

 

 

Maybe an Array would be more appropriate, do we have arrays in tcl?

 

I guess I'd better look!

 

 

David.

Hello Colin,

 

Yeah but no but yeah but no but yeah but no!

 

 

There will be instances of multiple IP address/subnet restrictions for a single path rather, than a 1:1 relationship like URI to Pool and so only having 2 classes wouldn't work for that, would it?

 

 

Thanks again for your assistance helping the feeble minded who don't code (remember to please give generously when we call at your door!).

 

 

David.

Posted By RACQ on 01/06/2011 04:19 PM

 

Hello Colin,

 

Yeah but no but yeah but no but yeah but no!

 

 

There will be instances of multiple IP address/subnet restrictions for a single path rather, than a 1:1 relationship like URI to Pool and so only having 2 classes wouldn't work for that, would it?

 

 

Thanks again for your assistance helping the feeble minded who don't code (remember to please give generously when we call at your door!).

 

 

David.

 

You could have as many URI:Blocked IP relationships as you wanted inside the class.