Persist only specific IPs destined for a VS

I believe that this is the general iRule structure that you will probably need, but I'm not sure exactly what you are looking for with the description that you have given, so I have included other options that are commented out.

You can find specific information on the perisit option used here:

http://devcentral.f5.com/wiki/default.aspx/iRules/persist.html

 
when CLIENT_ACCEPTED {
if { ([matchclass [IP::remote_addr] equals $::TestDataGroup ]) } {
persist cookie insert
Specific Pool
pool Your.Pool.Name
Specific Pool and Specific Pool Member
pool Your.Pool.Name member 10.10.10.10 80
}
}

If you are going to use a matchclass you might want to read SMP and Hoolio's thread about the differences between v9 matchclass and v10 class match:

Thread Name: v9 matchclass and v10 class match iRule commands

http://devcentral.f5.com/Community/GroupDetails/tabid/1082223/asg/50/afv/topic/aft/1172225/aff/5/showtab/groupforums/Default.aspx

Cool, that's where I was going with it. Do you know if "if" is a cleaner way to do this vs setting the variable "hostip"? Setting the host variable leave the option to do something else with the info in the future..

 

 

when CLIENT_ACCEPTED {

 

set hostip { [matchclass [IP::client_addr] equals $::phsIPs]

 

Check if there was a match

 

if {$hostip ne ""}{

 

persist source_addr 28800

 

pool mypool

 

} else {

 

pool mypool

 

}

 

}

 

 

 

Yep I'm using ver 9.x, I've seen the command change a bit in 10x. Thanks for the reference thread, good info..

It should be more efficient to do a qualifying compare and an action if it meets your criteria.

 

 

If client IP Address is in the matchclass data set, do this....

 

 

Your code is doing a variable set and then a compare.

 

 

Set hostip variable if the clients IP Address is in the matchclass data set.

 

Then

 

If the hostip is not equal to nothing / null, do this....

 

 

iRule efficiency is generally sacrificed for readability, but if this iRule has to be processed a couple of hundred times per second, it could add up to some processing latency.

 

 

I would try this. It does the compare and either applies the persistence or releases the traffic to the pool of the Virtual Server it is applied to:

 

when CLIENT_ACCEPTED {
    if { ([matchclass [IP::remote_addr] equals $::TestDataGroup ]) } {
        persist source_addr 28800
    }
}

Gotcha, so it will always default to the pool applied to the virtual server, correct?

 

 

What if I put an else with some logic after the persist, would I have to specify the pool after the persist or would it still default to the default pool?

 

 

Thanks man

Tested and yes it defaults to the pool attached to the VS, and no if there's an else you don't need to specifiy the pool after the command above.