Forum Discussion
Ramesh_Polarapu
Nimbostratus
NimbostratusLoad Balancer to forward the traffic when the Pool is down
In our setup we have a Virtual server MM1-Traffic and it has an iRule associated with it namely "Vantrix-v7.0". The purpose of this iRule is to differentiate the POST/GET in the HTTP requests and redirect the traffic to the pools Van-Get and Van-Post accordingly. Till now we have no issues as the traffic is going smooth and fine.
The customer have asked to implement redirection if any pools Van-Get or Van-Post are down redirect the traffic to another server/pool. I created Pool called MM1-Redirect, then created the iRules POST-Redirect & GET-Redirect and added this iRules to the MM1-Traffic virtual server but I am not able to see that the F5 redirecting the traffic if Van-Get or Van-Post pools are down.
Kindly advice and let me know if you need more information.
3 Replies
hoolioCirrostratus
Hi,
Can you post your rule and a sample of the ltm log file for a failure?
Thanks,
Aaron
Ramesh_PolarapuHi Aaron,
Thanks for your reply. Check the below details. I do not have any log in the F5 as they were cleared. I will try to redo the test by getting the permission from customer as it will effect the traffic.
iRule to differentiate POST/GET --- Vantrix-v7.0
when HTTP_REQUEST {
switch [HTTP::method] {
"GET" {
pool Van-Get
}
"POST" {
pool Van-Post
}
}
}
iRule to forward the traffic when Van-Get pool is down --- GET-Redirect
when CLIENT_ACCEPTED {
if { [active_members Van-Get] == 0 } {
pool MM1-Redirect
}
}
iRule to forward the traffic when Van-Post pool is down ---POST-Redirect
when CLIENT_ACCEPTED {
if { [active_members Van-Post] == 0 } {
pool MM1-Redirect
}
}
Regards
Ramesh- hoolioHi Ramesh,
If you set the pool in CLIENT_ACCEPTED and then set it to the GET or POST pools in HTTP_REQUEST in the second rule, the last rule's setting will override the first as the HTTP_REQUEST event is triggered after the CLIENT_ACCEPTED event. To fix this, you could either combine the rules or to set a flag in one rule which checks if the pool was specified in a previous rule. Here is an example of the first option:when HTTP_REQUEST { Select a pool based on the HTTP method switch [HTTP::method] { "GET" { log local0. "[IP::client_addr]:[TCP::client_port]: GET request to [HTTP::host][HTTP::uri]" Check if the selected pool has available members if {[active_members Van-Get]}{ log local0. "[IP::client_addr]:[TCP::client_port]: using Van-Get pool" pool Van-Get } else { log local0. "[IP::client_addr]:[TCP::client_port]: using MM1-Redirect pool. Van-Get pool is down" pool MM1-Redirect } } "POST" { log local0. "[IP::client_addr]:[TCP::client_port]: GET request to [HTTP::host][HTTP::uri]" Check if the selected pool has available members if {[active_members Van-Post]}{ log local0. "[IP::client_addr]:[TCP::client_port]: using Van-Post pool" pool Van-Post } else { log local0. "[IP::client_addr]:[TCP::client_port]: using MM1-Redirect pool. Van-Post pool is down" pool MM1-Redirect } } default { Do something for non-GET/non-POST requests? If nothing is done, the request will go to the default pool on the VIP if one is configured. log local0. "[IP::client_addr]:[TCP::client_port]: Request method [HTTP::method] to [HTTP::host][HTTP::uri] was not GET or POST. " } } }
Aaron
