Forum Discussion
Luke_Lehman
Employee
EmployeeContent Based Routing via iRule
Hey all,
We've implemented an iRule for an application's VIP that parses the HTTP URI and based on the contents, the iRule LBs to one of 12 pools of servers.
switch -glob $lowerURI {
"*/s1/*" {
pool $pool1
if { $log_value > 1 } {log local0. "$log_prefix: s1: setting poolname as: $pool1"}
STATS::incr $stats_profile slot_slot1
}
"*/s2/*" {
pool $pool2
if { $log_value > 1 } {log local0. "$log_prefix: s2: setting poolname as: $pool2"}
STATS::incr $stats_profile slot_slot2
}
"*/s3/*" {
pool $pool3
if { $log_value > 1 } {log local0. "$log_prefix: s3: setting poolname as: $pool3"}
STATS::incr $stats_profile slot_slot3
}
etc.
Where we are running into a problem (it seems), is when a single clientside TCP connection passes multiple requests to the LTM. For example, the first HTTP request on the clientside is for Pool1 ( /s1/ ). The LTM builds the serverside TCP connection to the pool 1 member.
Then, via the already established clientside TCP connection, the client sends another HTTP request that needs to be LB'ed to Pool2 ( /s2 ).
From the traces, it "looks" like the LTM closes the serverside TCP connection to the pool 1 member and initiates a new serverside TCP connection to the pool 2 member.
At this point, that all makes sense. We wouldn't want LTM to have one clientside TCP connection and multiple serverside TCP connections.
The behavior that I am trying to understand is in the situation where multiple requests are hitting the VIP and subsequently the iRule for the same pool.
Will the LTM close a connection to Pool 1 pool member, only to re-open it for the exact same member?
We have a firewall in between the LTM and the pool members (PCI Zone) and it seems that the close and immediate re-open of the exact same connection is causing the firewall to drop traffic.
The firewall thinks it is a duplicate connection because when the initial connection is closed, lets say TCP Source 61489 to TCP Dest 80. When the LTM re-initiates the connection, it has to use the same source port (the clienside connection is still up), the firewall sees Source 61489 to Dest 80. It then interprets that as a dupe connection and drops.
Please let me know if you have any insight on how the LTM would manage serverside TCP connections under an iRule of this nature
Mohamed_LrhaziAltocumulus
Do you have "Port Translation" disabled on the VS? The client side source port and server side one need not be kept the same.
If possible, I'd test with "one connect" enabled, to see how it behaves.
I believe the decision about whether to close connections after a request depends on the client and the server HTTP protocol.. the server might decide it wants it closed. You should take a capture of a full conversion, client side and server side, and inspect the packets.
Thanks,
Mohamed.
hoolioCirrostratus
I agree with Mohamed that adding a OneConnect profile to the virtual server should improve this.
Aaron- Luke_LehmanThanks guys! I will say that I've been doing numerous captures of the conversations. We also opened a support case and the tech also recommended OneConnect.
From what I was able to see, at peak, there are only 20 connections or so per pool member. The calling clients are in a LAN environment, so I was thinking about using a /32 mask. Does that seem reasonable? With that few concurrent connections, will OneConnect still be effective to prevent this behavior?
Thanks again. - Luke_LehmanAlso, to answer Mohamed's question - we have "Preserve" configured for "Source Port." I've never used anything but the default, Preserve. Would this be a second option if OneConnect doesn't work out?
- Mohamed_LrhaziThe behavior is odd, and I would think F5 should help you at least understand it, before you permanently change your setup, such as by using OneConnect....
Can you show the HTTP conversation between client and VIP, then VIP and server? preferably one that went wrong... specifically the HTTP version and the Connect header...
The client should say something like:
> GET / HTTP/1.1
Server:
< HTTP/1.1 301 Moved Permanently
< Connection: keep-alive
Maybe your clients request keep alive (HTTP 1.1), while your backend server is always requesting that every connection be closed?
Please ignore what I said about "Port translation" I misspoke and I am not sure I understand that option or the probably more relevant "Source Port" 
Michael_YatesNimbostratus
@Mohamed
I'm sure that they explained it if they suggested it in an open case. I've always had a really good experience with F5 Tech Support when I ask questions. The OneConnect Wiki Page explains more about how it works as well.
Your question about keep-alives is covered in the second paragraph.
Without OneConnect enabled, persistence data is examined only in the first request of a Keep-Alive connection, 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 unless a OneConnect profile is applied (even if logic contained in an iRule dictates otherwise).
To allow HTTP/1.0 clients to re-use backend connections, apply a OneConnect profile and an http profile with OneConnect transformations enabled (enabled in default http profile). With OneConnect transformations enabled, requests from HTTP/1.0 clients will be transformed into HTTP/1.1 requests using keepalives, allowing them to use OneConnect's HTTP/1.1 Keep-Alive connections as if they were v1.1 clients.
Clientside keepalives are not managed by OneConnect. LTM accepts keep-alive connections default and keepalive negotiation is managed by the client. The Max Requests option in the LTM http profile defaults to 0, allowing unlimited re-use of existing connections.
When using a OneConnect profile with an HTTP profile, if a pool member is marked down by a monitor and the pool setting for 'action on service down' is set to the default of none (no action taken), on the next HTTP request LTM will send a TCP reset to the client. Without both a OneConnect profile and an HTTP profile, LTM will allow client(s) to continue re-using the TCP connection for subsequent requests after the pool member has been marked down.
