Forum Discussion
Tim_Pearson_917
Nimbostratus
NimbostratusOne HTTPS virtual to several HTTPS pools
I am trying to write an iRule to take traffic from an HTTPS virtual (SSL terminated on the F5) and distribute the traffic to the correct pool based on the URI information. Currently, there are only 2 apps that are used, more to be added soon. I have actually tried a couple of different ways of doing this but each one just sends the traffic to one pool, repeatedly.
when HTTP_REQUEST {
switch [HTTP::uri] {
"/passwordreset" {
log local0. "passwordreset"
[HTTP::uri] "/nps/imanager.html"
pool passwordResetSSL }
"/nps" {
log local0. "passwordreset"
pool passwordResetSSL }
"/webmail1" {
log local0. "webmail1"
HTTP::uri "/"
pool webMailSSL }
"/servlet/webacc" {
log local0. "webmail1"
pool webMailSSL }
}
}or this way, of course the above URI information is in a data group for this one.
when HTTP_REQUEST {
if { [matchclass [HTTP::uri] starts_with $::passwordreset_Strings] } {
pool passwordResetSSL }
elseif { [matchclass [HTTP::uri] starts_with $::webmail_strings]} {
pool webMailSSL }
else {pool ChildrensWWW}
}Depending on which app I hit first is the one that I keep getting sent to, it is with either iRule. Any ideas?
Thanks,
Tim
- Try enabling a OneConnect profile on the virtual server.
Without OneConnect enabled, only the first request in a Keep-Alive connection is parsed for persistence data, so if multiple requests are sent on the same clientside Keep-Alive connection, LTM will persist them all to the same destination as the first.
OneConnect configured with the default mask of 0.0.0.0 will result in the most efficient connection pooling, allowing any idle serverside connection to be re-used for any new clientside request, significantly reducing the number of serverside connections. However, re-used serverside connections retain the source IP of the original client, which results in some very misleading server log entries unless you are also SNATing all connections.
A OneConnect profile with host mask (255.255.255.255) will allow parsing of all requests and serverside connections will only be re-used for the same client. Without SNAT, OneConnect with a host mask (255.255.255.255) keeps the source address info in the server logs consistent with reality.
OneConnect with any mask will be more efficient than none at all, since handshake overhead for your servers will be reduced (unless all your clients are using Keepalives,in which case it's a wash).
HTH
/deb - Deb, I just wanted to clarify something you've said several times now.Without OneConnect enabled, only the first request in a Keep-Alive connection is parsed for persistence data, so if multiple requests are sent on the same clientside Keep-Alive connection, LTM will persist them all to the same destination as the first.This is not entirely accurate. In fact, the BIG-IP parses all requests as long as the HTTP profile is on the virtual (and not disabled). However, the serverside connection is maintained unless either OneConnect is enabled or a new pool is picked. So, in this case, I would have expected it to change pool assuming the uri changed to one of the other values. This is often confused with the issue that the default pool is not automatically re-selected when there is no "else" clause.
Here are some similar posts from a long time ago explaining the details of enabling/disabling OneConnect and pool selection:
(Click here) http://devcentral.f5.com/Default.aspx?tabid=28&view=topic&forumid=5&postid=1636
(Click here) http://devcentral.f5.com/Default.aspx?tabid=28&view=topic&forumid=5&postid=5336
(Click here) http://devcentral.f5.com/Default.aspx?tabid=28&view=topic&forumid=5&postid=6751
Robert_47833Altostratus
yeah,I have one vip which only has http profile ,but it can do content switching for multiple http requests in a single tcp connection without one connect profile enabled is this as expected?
- Yes, you got it!
As for this case, the first example using a switch does not include a default case (the equivalent of the else). So, I'm not sure whether that was influential - maybe he didn't completely test the second example, or maybe it'd didn't get loaded or something... 
Tim_Pearson_917Just to clarify, I did not test the whole second rule. The else was just a catch all at the end, I really don't see it ever being hit. I was just more focused on the other sites. Thanks again for all the help and advice
