stop processing further irules on condition match

You'd probably want to use the "event" command.

 

 

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

 

 

You can also set a local variable in one rule and check for it in subsequent rules. This avoids the need to disable events for the duration of the TCP connection. That approach can be problematic for handling subsequent HTTP requests on the same TCP connection.

Here's an example using the variable $snatted to determine if an initial rule has enabled SNAT and therefore not take any subsequent action.

Aaron

 rule 1
when CLIENT_ACCEPTED {
 
    Apply a SNAT based on some connection criteria
 
    Check if the client IP is in the 10.0.0.0/8 subnet
   if {[IP::addr [IP::client_addr] equals 10.0.0.0/8]}{
 
       Apply SNAT automap for this connection
      snat automap
 
       Set a variable that tracks we've applied SNAT
      set snatted 1
   }
}
 
 --------------------------------------------------------------------------
 rule 2
when CLIENT_ACCEPTED {
 
    Check if $snatted exists and is set to 1
   if {[info exists snatted] && $snatted==1}
 
       We've already SNAT'd this connection so don't select a new pool
 
   } else {
 
       We haven't SNAT'd this connection, so select a pool
       based on the client's destination port
      switch [TCP::local_port] {
         "80" {
             Select the corresponding pool for port 80
           pool port_80_pool
        }
         "443" {
             Select the corresponding pool for port 80
           pool port_443_pool
        }
         default {
             No match for the destination port, so take some default action
           pool default_pool
        }
      }
   }
}

Hi Aaron

 

 

Is this the only way to control processing further irules?

 

I mean I have a lot of them :-)

 

 

Isn't there another way to do it?

 

 

 

Kind regards

 

Andy

Hi Bigbrother.,

 

As Chris Miller mentioned you can use the EVENT command Click Here.

 

 

I hope this helps

 

Bhattman

You could use an iRule like this to detect if a prior iRule has changed the pool from the virtual server's default pool or issued an HTTP redirect (using HTTP::redirect) or response (using HTTP::respond):

when CLIENT_ACCEPTED priority 1 {
 
    Ensure this event runs first to save the VS's default pool name
   set default_pool [LB::server pool]
}
when HTTP_REQUEST priority 999 {
 
    Ensure this event runs after any iRules which should take precedence over this one
    Check if the currently selected pool has changed or an HTTP redirect/response has been triggered already.
   if { ([LB::server pool] ne $default_pool) or [catch {HTTP::payload replace 0 0 {}}] } {
      set already_responded 1
   } else {
      set already_responded 0
   }
 
   if {$already_responded == 0}{
 
       Do something like select a pool or redirect the client
   }
}

Or if you don't care about pool changes and just want to detect a redirect/respond, you could simplify the iRule:

when HTTP_REQUEST priority 999 {
 
    Ensure this event runs after any iRules which should take precedence over this one
    Check if an HTTP redirect/response has been triggered already.
   if { [catch {HTTP::payload replace 0 0 {}}] } {
      set already_responded 1
   } else {
      set already_responded 0
   }
 
   if {$already_responded == 0}{
 
       Do something like select a pool or redirect the client
   }
}

Both examples attempt to insert nothing in the request payload. If a redirect/response has already been sent in an iRule, catch traps a runtime error and a variable is set to track it.

Aaron

Thanks hoolio! event statement is really dangerous when you use something like Akamai, will disable all further Request using the same connection. Be careful with that.