Two 'Default' Gateways for Production and Test

This would be simple to do if you can dictate that the test clients access LTM from a different VLAN than the standard user. If that's possible, you could defined your two 0.0.0.0/0 VIPs on separate VLANs and use separate iRules.

 

 

If the test and production clients are on the same ingress VLAN, you could potentially use the virtual command (Click here) in an iRule to select a second test VIP for the specific clients you want to go to the test VIP. I haven't tried the virtual command with a forwarding network VIP though, so I'm not sure whether/how this will work.

 

 

Aaron

I imagine in the latter case I could try a test like the following:

 

 

when RULE_INIT {

 

set ::g_prod_var 113

 

log local0. "RULE_INIT production_rule initialized: $::g_prod_var"

 

}

 

 

when CLIENT_ACCEPTED {

 

log local0. "CLIENT_ACCEPTED VirtualServer [virtual] from [IP::client_addr]:[TCP::client_port]: to [IP::local_addr]:[TCP::client_port]"

 

}

 

 

when HTTP_REQUEST {

 

if { [IP::client_addr] == "174.47.71.225" } {

 

Send request to a new virtual server "test_irule", for iRULE testing

 

log local0. "HTTP_REQUEST switching from VirtualServer [virtual] to VirtualServer \"iruletest\""

 

virtual iruletest

 

}

 

log local0. "HTTP_REQUEST production_rule on VirtualServer [virtual]"

 

 

do something ....

 

 

}

 

 

However looking at the help on "virtual" I see that is says "In order to make this functionality work, one must precede the virtual command with an LB::reselect command if a pool member has already been selected" - how do I know if a pool member has been selected, does it hurt to blindly just stick the "LB:reselect" in (as you can tell I do not know too much about the F5 configuration).

 

 

Jon

 

 

Hi Jon,

 

 

You don't need LB::reselect in CLIENT_ACCEPTED or HTTP_REQUEST as a load balancing decision hasn't been made yet.

 

 

For a standard TCP VIP with an HTTP profile, you'll see these events triggered

 

 

Request events:

 

---------------------------------------------

 

CLIENT_ACCEPTED - clientside - triggered when LTM receives and accepts a connection from a client

 

HTTP_REQUEST - clientside - triggered when an HTTP profiles

 

HTTP_REQUEST_DATA - clientside - triggered if HTTP::collect was called in HTTP_REQUEST

 

LB_SELECTED - clientside - triggered when a node has been selected per the load balancing algorithm

 

SERVER_CONNECTED - serverside - triggered when a connection is established with the node

 

HTTP_REQUEST_SEND - serverside - triggered when LTM sends the HTTP request to the node

 

CLIENT_CLOSED - clientside - triggered when the client connection is closed

 

 

Response events:

 

---------------------------------------------

 

HTTP_RESPONSE - serverside - triggered when LTM receives the HTTP response from the node

 

HTTP_RESPONSE_DATA - serverside - triggered if HTTP::collect was called in HTTP_RESPONSE

 

SERVER_CLOSED - serverside - triggered when the server connection is closed

 

 

iRule events wiki page

 

http://devcentral.f5.com/Wiki/default.aspx/iRules/events

 

 

iRule events (as part of IP:: questions)

 

http://devcentral.f5.com/Default.aspx?tabid=53&forumid=5&tpage=1&view=topic&postid=1018710235

 

 

Aaron