The first irule is cheking some condition. How can I stop processing all further irules if a specific condition matches in the first irule for the virtual server?
25-Oct-201012:47 - last edited on 31-May-202315:53 by JimmyPackets
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
}
}
}
}
27-Dec-201009:55 - last edited on 31-May-202315:47 by JimmyPackets
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.
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.
