Forum Discussion

rongriffin_2708's avatar
rongriffin_2708
Icon for Nimbostratus rankNimbostratus
Mar 28, 2017

Get current default pool name in an iRule?

Is it possible to query the current value of the default pool on a virtual server in an iRule so that it can be compared to the connection's [LB::server pool] value?

 

Thanks.

 

EDIT

Thanks for the replies, but that's not exactly what I'm asking, so I'll attempt to clarify.

 

I can grab the connection's server pool name on CLIENT_ACCEPT. However, if a tcp connection is long lived, it's possible that we may have changed the default pool on the virtual server during the connection's lifetime.

 

Subsequent calls to [LB::server pool] will return the pool name that requests on that connection will load balance to, but I need to be able to grab the current default pool on the virtual server on, say, HTTP_REQUEST.

 

Is there a way to inspect the properties on a virtual server in an iRule?

 

4 Replies

  • You can query the default pool name before the LB decision is made:

    when CLIENT_ACCEPTED {
       Save the name of the VIP's default pool
      set default_pool [LB::server pool]
    }
    
    LB::server pool

    Returns the pool of the currently selected member. If no server was selected yet or all servers are down, returns default pool name.

    https://devcentral.f5.com/wiki/iRules.LB__server.ashx

  • HI

     

    you can try this

     

    code
    when CLIENT_ACCEPTED {
     Save the name of the VIP's default pool
    set default_pool [LB::server pool]
    }
    
    when HTTP_REQUEST {
        if { ([string tolower [HTTP::uri]] contains "/123/") } {
            pool POOL_A
        }
        elseif {([string tolower [HTTP::uri]] contains "/456/") } {
            pool POOL_B
        }
        else {
        pool $default_pool
        }
    }

    have a good day!

     

  • I went through LB and virtual and I don't see anything that would get the real time configuration of a virtual server.

     

    It looks like most examples are related to setting pool is based on information on the http request (file type, path, etc).

     

    I have a scenario where I want to flip the default pool between a "blue" server pool and a "green" server pool as part of an application deployment. Pooled tcp connections can have long lifetimes which leave them connected to the "off" server pool. I need a way to gracefully route traffic to the new pool without forcing the connection closed.

     

    Is this possible in an iRule?

     

    Something similar to this:

     

    when CLIENT_ACCEPTED {
        set original_pool [LB::server pool]
    }
    
    when HTTP_REQUEST {
        pseudo code
        set current_pool [SOME_HOW_GET_THIS_INFO_FROM_THE_VIRTUAL_SERVER]
        if ($current_pool <> $original_pool) {
            pool $current_pool
        }
        pseudo code
    }
  • ​First a few things.  I know I am resurrecting an older thread, but I felt since the original question was never satisfied, I should toss in my two cents.

    The OP asked for a way to track what the currently assigned pool is under the theory that they (or some iRule associated to this VS) changed it on the fly and wanted to know what it is now.   That can be done rather simply by keeping track of the change in the first place when your iRule is making those decisions:

    when CLIENT_ACCEPTED {
    set default_pool [LB::server pool]
    set current_pool [LB::server pool]
    }
     
    when HTTP_REQUEST {
      switch -glob [ string tolower [HTTP::uri]] {
        "/images*" {
          set current_pool pl_images
          pool pl_images
        }
        "/reports*" {
          set current_pool pl_reports
          pool pl_reports
        }
        default { pool $default_pool }
      }
    }

    The simpler approach is to simply map out your actual changes ahead of time.  In the case of URI pool changes, capture the default pool before you do any custom changes so you know the pool name to use when you want to 'revert' back to the default.  It's the same as above but you simply don't care to track what your current selection was  because each pass through HTTP_REQUEST will examine where the pool selection needs to go for the current request.