All, I have a scenario where I want to LB "pods" of servers using a Master VIP. I could have many nodes in each pool and do not want to disable each individual node when we take a "pod" offline. It would be a simple task to disable either the pool or the VIP as a whole rather than each individual node. iRule logic: In the iRule below, we round robin connections to a specific VIP (one defined for each pod). Once at the pool, we set a unique cookie and persist back to the pod as required (each VIP inserts a cookie "my_cookiePodx"). Question: Can I monitor the pool (or VIP) in the iRule for availability so if a pod is offline, the VIP won't send traffic to the disabled pod virtual? I was thinking of using when LB_Failed but the docs suggest fail detection between 9 and 45 seconds. My thoughts are if the VIP is offline, LTM would send a reset and the browser would simply retry. This seems faster but it also seems a little dirty. when RULE_INIT { set ::cnt 0 } when HTTP_REQUEST { set reqcookie [findstr [HTTP::cookie names] "my_cookie"] if { $reqcookie starts_with "my_cookie"} { set podcookie [findstr $reqcookie "my_cookie" 9 " "] set podvip [findclass "$podcookie" $::pod_vip " "] virtual $podvip } else { incr ::cnt if { $::cnt <= 3 } { set ::cnt 1 } switch $::cnt { 1 { virtual pod1 } 2 { virtual pod2 } 3 { virtual pod3 } } } }

If you know the pool name associated with the virtual server, you could use 'active_members pool_name' (Click here) to verify there is one or more pool member up before selecting the corresponding VIP for the request. Aaron

Thanks for the reply... I guess the best method is to disable "all nodes" in a pod_pool rather than disabling the VIP itself. I'll clean up the logic a little to include monitoring the pods and post the final iRule after testing.

Yep. There isn't a method for getting the state of a VIP in an iRule. As we've just recently gotten the ability to specify a virtual server for a request, this wasn't an issue before. If you'd like to see this functionality considered for addition, you could open a case with F5's support group (https://websupport.f5.com). Aaron

Aaron's exactly right here, as usual. There isn't much monitoring of VIP state in iRules yet, but I wouldn't be surprised if we saw more of that soon, as we're able to use virtuals as targets now in iRule logic. Definitely send in a case asking for this, though, if it's something that would be beneficial to you. Colin

We decided to modify the logic slightly... Instead of RR connections to the Pod VIP's we allow the first connection (no cookie set) to go to a "master pool" which includes all the nodes contained in each pod. We will use least connections (LB Algorithm) on this master pool to ensure the new request goes to not only the most available pod but also the server with the least connections. My thoughts are that once the logic sends this initial connection to the most available node, we can set a persist cookie on the reply. This cookie name/value is being set correctly based on server info in the podx_class but I need to include the proper persist value (Server:port) inside the cookie. Question: Can anyone tell me how to set the value of the cookie so when the return comes back, and the iRule logic sends the return request to the proper VIP, the cookie can be used to persist to the proper node inside the pod pool? Thanks, when HTTP_REQUEST { set reqcookie [findstr [HTTP::cookie names] "my_cookie"] if { $reqcookie starts_with "my_cookie"} { set podcookie [findstr $reqcookie "my_cookie" 9 " "] set podvip [findclass "$podcookie" $::pod_ip " "] virtual $podvip } else { pool master_pod_pool } } when HTTP_RESPONSE { if { [matchclass [IP::server_addr] equals $::pod1_class] } { HTTP::cookie insert name "pod1" value [IP::server_addr] } elseif { [matchclass [IP::server_addr] equals $::pod2_class] } { HTTP::cookie insert name "pod2" value [IP::server_addr] } elseif { [matchclass [IP::server_addr] equals $::pod3_class] } { HTTP::cookie insert name "pod3" value [IP::server_addr] } }