Forum Discussion
dennypayne
Employee
Oct 13, 2006Match across services persistence w/rule
I have read in several threads that you cannot directly call "match across services" from a persist command in an iRule.
I have converted a v4 configuration that had several rules that ended up like this:
when CLIENT_ACCEPTED {
if { [server_port] == 6366 } {
use pool sftp-ics11.6366
}
elseif { [server_port] >= 6367 and [server_port] <= 6415 } {
use pool sftp-ics11.0
}
else {
discard
}
}The previous config had globally enabled match across services so that any connections to those multiple ports would be sent to the same node.
On the virtual that uses this rule, if I enable a default persistence profile inheriting from source_addr, with Match Across Services checked, will that still take care of traffic that is processed through this rule? If not I need to take care of this within the rule somehow.
I tried this:
when CLIENT_ACCEPTED {
if { [server_port] == 6366 } {
use pool sftp-ics11.6366
}
elseif { [server_port] >= 6367 and [server_port] <= 6415 } {
persist SFTP1800
use pool sftp-ics11.0
}
else {
discard
}
}where SFTP1800 is the same profile I selected as default, and I get an error saying the persist command must be one of cookie, source_addr, etc. So if I can't call a profile and I can't do match across within the rule, how can I solve this if the default profile won't handle it?
Thanks,
Denny
4 Replies
- dennypayne
Employee
I think the OTCU hosed me here....
Trying the previously referenced rule with both server_port and TCP::server_port, I'm getting from /var/log/ltm:Oct 15 05:30:57 tmm tmm[1058]: 01220001:3: TCL error: Rule SFTP_ICS.rule - Error: No serverside connection established (line 1) invoked from within "server_port" Oct 15 05:30:57 tmm tmm[1058]: 01220001:3: TCL error: Rule SFTP_ICS.rule - Error: No serverside connection established (line 1) invoked from within "TCP::server_port"
I'm guessing the correct operator would be TCP::client_port (but why did this work on 4.x then?)
Denny - hoolio
Cirrostratus
Hi Denny,
If the BIG-IP is acting as a full proxy, then during the initial connection set up with the client (which the CLIENT_ACCEPTED event is for), there isn't a server connection built yet.
If this did work in 4.x, I would guess that it's because server_port referred to the VIP as the server and you were getting the VIP's port.
If you want to get the client's source port, you can use TCP::remote_port in the clientside context or TCP::client_port which is just clientside { TCP::remote_port }. To get the client's destination port (or the VIP's port) you can use TCP::local_port.
We had a bit of discussion on context for events in this post (Click here).
Hope this helps with the rest of your rule.
Aaron - dennypayne
Employee
Well, let me add that the rule is tied to a port 0 VIP, but TCP::local_port should still return the port that the client is actually asking for, correct?
Denny - unRuleY_95363Historic F5 AccountHey Denny,
Yes, just putting the persistence profile with "match across services" enabled on the virtual should enable that behavior regardless of what you do in the iRule. If you don't want persistence for some pools, then you'll need to explicitly disabled it with "persist none" in the iRule.
Help guide the future of your DevCentral Community!
What tools do you use to collaborate? (1min - anonymous)Recent Discussions
Related Content
DevCentral Quicklinks
* 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
Discover DevCentral Connects