Forum Discussion
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
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_ParkerCirrus
In client accepted I'm not sure how you would have a value for [LB::server pool] as no load balancing decision has been made yet. I've always been under the impression LB_SELECTED has to fire before any LB variables will be populated.
- Brad_ParkerCirrusIt makes sense in your logging that it would be populated after you issue the pool command.
- Brad_ParkerCirrusMissed 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?
- 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
- CHofmann_213970NimbostratusThanks! That would have been my next question otherwise ;)
- You're welcome... ;-) Cheers, Kai
- Brad_ParkerCirrusI 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
- Brad_ParkerCirrusA.) 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^^
Recent Discussions
Related Content
* Getting Started on DevCentral
* Community Guidelines
* Community Terms of Use / EULA
* Community Ranking Explained
* Community Resources
* Contact the DevCentral Team
* Update MFA on account.f5.com