Persistence problem

is it possible to run httpwatch while reproducing the problem?

 

This can happen with one or more clients from the same address and usually effects everyone currently connected form that one customer's space.

 

 

 

Do you know if this is happening from a large IP Space (entire subnet or is the customer behind a NAT)?

 

 

The problem that you are having sounds very similar to one that I have seen before and was resolved the the use of the OneConnet Profile.

 

http://devcentral.f5.com/wiki/AdvDesignConfig.OneConnect.ashx

 

 

So far we haven't been able to get anyone technical on the other end to help us troubleshoot this issue. I'm sure we could figure it out rather quickly if we could get onto one of their machines. I'm not able to duplicate the issue.

The customer is NATing, so all clients have the same IP but different port s. I read about OneConnect but don't see how that would help. It looks like it's more of a resource saver and might make it worse, unless I'm reading it wrong. The site is really an application with many users other than the ones reporting problems.

If they Client is NAT'ing and appears to be coming from a single IP Address then the application of the OneConnect Profile should resolve your issue.

 

 

 

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 further translate. The OneConnect Profile will do a deeper inspection of each TCP Connection and handle them all as "different" connections in regards to persistence behavior. This should resolve your issue because each different connection is actually a different client rather than a different request from the same client.

 

 

The overview solution provides additional detail: Solution: SOL7208 - Overview of the OneConnect profile or http://support.f5.com/kb/en-us/solutions/public/7000/200/sol7208.html?sr=16914074

 

 

Pay particular attention to this area. It is the basis for my previous translation:

 

 

Content Switching

 

When a OneConnect profile is enabled for an HTTP virtual server, and an HTTP client sends multiple requests within a single connection, the BIG-IP system is able to process each HTTP request individually. The BIG-IP system sends the HTTP requests to different destination servers as determined by the load balancing method. Without a OneConnect profile enabled for the virtual server, the BIG-IP system performs load-balancing only once for each TCP connection.

 

 

Michael,

 

 

Thanks for the reply and the info. I think I understand what you're saying about the OneConnect, but I'm not sure that's my problem. I can see what look like exisitng sessions (unique IP/port ) sending persistence cookies, then for a few seconds stop sending persistence cookies, and then start again. As near as I can tell, these times when they fail to send their persistence cookie is when they have problems if they have problems, as they should if they get sent to another server. Do you have any idea what could be causing that and will the OneConnect maintain persistence whether or not they send the persistence cookie? I'm OK with everyone from that NAted IP going to the same physical server, as long as they can fail over to another if needed, so I'm trying not to staically set what server they hit.

 

 

Dave

Do you have any idea what could be causing that and will the OneConnect maintain persistence whether or not they send the persistence cookie?

Persistence will be set if it is not sent.

To say that OneConnect might solve your problem would be a total assumption based on the problem description. I would suggest a deeper investigation to determine if the connection that is not providing any persistence information is actually a new connection that looks like an existing connection, or if it is truly losing / not providing its persistence information.

A header logging iRule might help (I would only advise using this in a limited capacity for logging). This should help you determine if an existing connect or new connection is not providing a cookie (Search for the unique Client IP and Port Combinations).

 
when HTTP_REQUEST {
set LogString "Client [IP::client_addr]:[TCP::client_port] -> [HTTP::host][HTTP::uri]"
log local0. "============================================="
log local0. "$LogString (request)"
foreach aHeader [HTTP::header names] {
log local0. "$aHeader: [HTTP::header value $aHeader]"
}
log local0. "============================================="
}
when HTTP_RESPONSE {
log local0. "============================================="
log local0. "$LogString (response) - status: [HTTP::status]"
foreach aHeader [HTTP::header names] {
log local0. "$aHeader: [HTTP::header value $aHeader]"
}
log local0. "============================================="
}