uri redirect

a couple things...

you could consolidate into one class by mapping each uri to the appropriate node:

consolidated_class {

"/nosso/* 66.33.14.10"

"/xRV144991/* 66.33.14.10"

"/5.2_rv950007/* 66.33.14.11"

"/5._RV950048/* 66.33.14.11"

"/dev_5.2/* 66.33.14.11"

}

then your rule is reduced to:

 
 when HTTP_REQUEST { 
   if { [matchclass [string tolower [HTTP::uri]] contains $::consolidated_class] } { 
     pool myPool member [findclass [string tolower [HTTP::uri]] $::consolidated_class " "] port myPort 
   } 
 } 
 

You'll note that I moved your example away from the node command and instead used the pool command. THis is important if you want the statistics at the pool level. This is untested, I don't have a resource right now, but should get you going.

I should also note that with this rule, you can specify the default node in an isolated pool with only member 66.33.14.12 and attach it to the virtual, that way it gets all the traffic not matched by the above rule. You could also add an else statement...

Thanks for your recommendations. I will test and let you know outcome.

So we have a datagroup called LB_test_data_group which contains

 

"/RCLweb1/ 66.31.13.45"

 

 

Then we applied the irule:

 

when HTTP_REQUEST { if { [matchclass [string tolower [HTTP::uri]] contains $::LB_test_data_group] } { pool LB_test_web_pool member [findclass [string tolower [HTTP::uri]] $:: "LB_test_data_group "] port myPort } else pool LB_pool_web_default } }

 

 

We were not able to pull up a webpage for the uri specified.

 

 

What am I missing?

myPort needs to be the tcp port of your pool member

Matchclass matches on the whole class entry, not just the first field, so you can't use matchclass with the suggested consolidated class. For this approach to work, you will need to have 2 classes, one for matching, another for grabbing the related pool:

 

   
   class UriMatch {    
     "nosso"    
     "xRV144991"    
     "5.2_rv950007"    
     "5._RV950048"    
     "dev_5.2"    
   }    
      
   class DestMap {    
     "nosso 66.33.14.10"    
     "xRV144991 66.33.14.10"    
     "5.2_rv950007 66.33.14.11"    
     "5._RV950048 66.33.14.11"    
     "dev_5.2 66.33.14.11"    
   }    
   

 

Then you can use the matchclass command using the first class to condition a findclass lookup in the second.

 

 

Definitely you need to delete the the trailing * in the UriMatch class entries. That would be necessary in any case since matchclass performs a literal string match, no wildcards. The starts_with operator can be used to emulate a trailing wildcard. However, since we can just pull the first directory (looks like all but ops*) to make the match, and we need a discrete value anyway for the lookup in the 2nd class (findclass doesn't support operators, rather makes full match against the first field), I'm going to suggest using the directory name only for both so it's a bit more intutive. Class values have been modified to match, and this code extracts the dir name:

 

   
   [getfield [string tolower [HTTP::uri]] "/" 2]   
   

 

 

Resulting iRule looks like this:

 

when HTTP_REQUEST {   
     set FirstDir [getfield [string tolower [HTTP::uri]] "/" 2]   
     if {[matchclass $FirstDir equals $::UriMatch]}{   
       pool myPool member [findclass $FirstDir $::DestMap " "]   
     }   
   }   
   

 

The ops* case would need to be specifically handled, along with any other exceptions to the first-directory-match algorithm.

 

 

If you vary the length of path you are matching on, you can get into a sticky wicket doing iterative matches, longest first, since you don't have the flexibility of specifying an operator & need to extract just that bit for the match. (I've done it, have the code somewhere, but it's far from optimal.) However, in this case since all of your conditions but one (/ops*) are matches of the first directory in the path, you can use getfield to extract just that first directory name.

 

 

Def agree that pool command is better than node. Along those lines, it might make sense to build a pool for each server, even though they would only have a single member, rather than specifying a specific member of one pool. That way you can add redundancy later by just adding pool members. You'd just change the class to include the poolnames instead of IP's, then change the pool command to:

   
       pool [findclass $FirstDir $::DestMap " "]   
   

 

hth

 

/deb

 

 

ps

 

Look for major improvements to the class management commands in an upcoming release. Will make all this a walk in the park, comparatively speaking...

(hmmmm, anybody else find it exceedingly annoying that code blocks are not protected from smiley macro expansion...?)

 

 

changed the name of the variable to something not starting with P...

Yes, definitely annoying...and thanks for picking up my scraps :-)

Thanks Deb. I will have this tested and let you know the results.

 

The previous suggestion from Citizen_elah unfortunately didn't work but we appreciate his time and guidance.

Hi Deb,

 

 

Could you exaplin this a bit more:

 

 

If you vary the length of path you are matching on, you can get into a sticky wicket doing iterative matches, longest first, since you don't have the flexibility of specifying an operator & need to extract just that bit for the match.

 

 

Thanks,

 

Naman