Forum Discussion

CHofmann_213970's avatar
CHofmann_213970
Icon for Nimbostratus rankNimbostratus
Feb 02, 2016

LB::server pool returns empty string

I need to switch between two different pools, based on the url. I found the following pattern in several answers:

 

 

when CLIENT_ACCEPTED {
    set default_pool [LB::server pool]
}

when HTTP_REQUEST {
    if { ... } {
        pool $default_pool
    } else {
        pool other_pool
    }
}

 

 

However, LB::server pool always returns an empty string. I have configured a default pool and the behavior appears if a oneconnect profile is set as well as when no oneconnect profile is set.

I am on version 11.5.3.

Edit In response to Kai Wilke

 

: 1 - LB::server_pool =
: 1 - $default_pool =
: 2 - LB::server_pool = /Common/DefaultPool
: 2 - $default_pool = /Common/DefaultPool

 

When I attach an OneConnect profile, the pool is not reset to the default one. Resetting it to the default would solve the problem though. Independently of a OneConnect profile being present I have to reset the pool explicitly to the default one.

Edit based on the assumptions by Brad Parker

I changed the code to this pattern:

 

 

when CLIENT_ACCEPTED {
    set default_pool ""
}

when LB_SELECTED {
    if { $default_pool == "" } {
        set default_pool [LB::server pool]
        log local0.debug "1 - LB::server_pool = [LB::server pool]"
        set default_pool [LB::server pool]
        log local0.debug "1- \$default_pool = $default_pool"

        pool DefaultPool

        log local0.debug "2 - LB::server_pool = [LB::server pool]"
        set default_pool [LB::server pool]
        log local0.debug "2 - \$default_pool = $default_pool"   
    }
}

when HTTP_REQUEST {
    if { $redirect } {
        pool EMDRA
    } else {
        pool $default_pool
    }
}

 

 

The behavior remains the same: [LB::server pool] returns an empty string as long as I haven't set a pool explicitly by calling pool some_pool

14 Replies

  • Hi CHofmann,

    The [LB::server pool] command should normaly output the currently selected pool, either using the "default pool" or the last selected [pool]. This should work independently of your [ONECONNECT] profile settings.

    OneConnect enable Virtual Servers will just behave little differently, since they would automatically revert to the "default pool" on each HTTP_REQUEST. And OneConnect-less Virtual Server would always stick to the last selected virtual server...

    To troubleshoot your environment, you may add some additional code to your iRule...

     

    when CLIENT_ACCEPTED {
    
        log -noname local0.debug "1 - LB::server_pool = [LB::server pool]"
        set default_pool [LB::server pool]
        log -noname local0.debug "1- \$default_pool = $default_pool"
    
        pool YOUR_DEFAULT_POOL_NAME
    
        log -noname local0.debug "2 - LB::server_pool = [LB::server pool]"
        set default_pool [LB::server pool]
        log -noname local0.debug "2 - \$default_pool = $default_pool"
    
    }
    
    
    when HTTP_REQUEST {
        if { ... } {
            pool $default_pool
        } else {
            pool other_pool
        }
    }
    

     

    Cheers, Kai

    • Brad_Parker's avatar
      Brad_Parker
      Icon for Cirrus rankCirrus
      It makes sense in your logging that it would be populated after you issue the pool command.
    • Brad_Parker's avatar
      Brad_Parker
      Icon for Cirrus rankCirrus
      Missed the key part of why it should be working as Kai says, "If no server was selected yet or all servers are down, returns default pool name." What version are you running?
    • Kai_Wilke's avatar
      Kai_Wilke
      Icon for MVP rankMVP
      Yep, its should normaly work like the OP has implemented the code, but it doesnt. Even SOL9800 is recommending an alike iRule for non-OneConnect Virtuals. So [LB::server pool] dont require a LB decision, but [LB::server addr] does... Cheers, Kai
  • Site note: It seems that OneConnect enabled Virtual Servers wouldn't reset the current pool selection and revert to the default pool for each HTTP_REQUEST. I've posted the observed behavior here... https://devcentral.f5.com/s/feed/0D51T00006aEjMCSA0 Cheers, Kai
  • I have confirmed the expected behavior in v12 exists. The default pool is being populated in client accepted. Has a case been opened yet? Also, what hotfix are you on? I'm going to try to replicate your observed behavior in my lab.
  • Hi Brad, I guess you're refering to the strange [LB::server pool] behavior, right? Are you also able to repro the observed SOL9800 bug? Cheers, Kai
  • A.) SOL9800 is not a bug, it describes behavior. 2.) I just tried the irule with the logic to log above in client accepted and got the expected results in 11.5.3 base image. I can try the hotfix that the behavior is being observed in if you provide it. Rule /Common/dc : 2 - $default_pool = /Common/pool2 Rule /Common/dc : 2 - LB::server_pool = /Common/pool2 Rule /Common/dc : 1- $default_pool = /Common/pool2 Rule /Common/dc : 1 - LB::server_pool = /Common/pool2
  • Yep SOL9800 describes a behavior. But somehow the explained behavior cant be observed in v11.3, v11.5.3 and v12. Well, at least for the OneConnect enabled Virtual Server part of the article... I can't judge if this is documantation bug or even a product bug. But its somehow a bug related to the infomation provided in this SOL^^