persistency on this irule

Hi Chris,

Unfortunately, I think this is expected. See these two related posts for more info:

http://devcentral.f5.com/Forums/tabid/1082223/asg/50/showtab/groupforums/aff/5/aft/1167826/afv/topic/Default.aspx1167901

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

If you want to keep a client going to one node regardless of the rest of the conditions, I think you'd need to track this yourself. You could do this with cookies if it's HTTP traffic or using the client IP in the session table. Here's an untested example of the latter:

when CLIENT_ACCEPTED {

    Check if client IP is in session table
   set node_info [session lookup uie [IP::client_addr]] 
   if {$node_info ne ""}{

       Use the IP and port from the session table entry
      scan $node_info {%s %s} ip port 
      node $ip $port

   } else {
      if { [matchclass [IP::remote_addr] equals ::opt-client] and [active_members unison] > 1 } {

          Select the node and record the selection in the session table for 1 hour
         node 10.129.60.2 80
         session add uie [IP::client_addr] [list 10.129.60.2 80] 3600

      } elseif { [matchclass [IP::remote_addr] equals ::noopt-client] and [active_members unison] > 1 } {

          Select the node and record the selection in the session table for 1 hour
         node 10.129.60.66 80
         session add uie [IP::client_addr] [list 10.129.60.66 80] 3600

      } elseif { [active_members unison] < 1 } {
         virtual forwarding_TCP_vs
      }
   }
}

Aaron

Hello Aaron

 

Thanks v much for this rule you supplied. For information I tried it also another way but without success, I tried to create 2 pools just with one server in each pool, and it seemed to fail i.e. this rule:

 

 

when CLIENT_ACCEPTED

 

{

 

if { [matchclass [IP::remote_addr] equals ::client_ip_list] } {

 

pool pool_optimized

 

} else {

 

pool pool_unoptimized

 

}

 

}

 

 

Its strange though as we have another configuration elsewhere with one pool (test pool) and we sent all this traffic to the one test pool without problems. Perhaps it could be we either have 2 pools, or in my case I am testing on version 10. (the other ltm viprion has v9.6.1) .The irule you supplied worked, but for some reason (still need to investigate) the customer noticed performance issues with some websites when we applied the rule. Since we have to put the traffic live on monday morning I wont be using it for now, but will have the opportunity to re-test. Sorry cant supply more info on this.

 

Cheers

If you're testing on v10, you should remove the :: prefix from the datagroup name. You can check the persistence records using 'b persist all show all' to see what records are being added with the iRule in use.

 

 

Aaron

Thanks again Hoolio. I saw your other post regarding this and using the new classmatch command. Now it seems to work great!