Hi, I have an LB with cookie persistence as persistence profile for a HTTPS re-encrypted LB.
When viewing some specific PDFs, we have an iRule that disables HTTP for a specific path, because due to a bug in the app, there is a mismatch in content length compared to what tht eapp says it sends, and what it sends, which violates the http standard, and the LB drops the data. As mentioned, this is solved by disabling HTTP for a specific path with an iRule. The problem is then that the LB fails to stick sessions based on cookies, and connection is lost for clients upon refresh, because they are loadbalanced to next hop.
My thought is that I could enable Source IP as a fallback method, however my concern is that since all connections are coming from the same source IP, ALL connections will be sent to the same server as soon as the fallback method kicks in. Even when not accessing the documents, because it has already been triggered.
We can not use SSL session ID persistence either, due to TLS 1.3 not supporting it. Any suggestions?
You're facing a complex issue where you need to maintain session persistence while dealing with an application bug and limitations of certain persistence methods. I understand your concern about using source IP as a fallback persistence method, as it could indeed result in all connections from the same source IP being sent to the same server.
You might want to consider using Universal Persistence, which allows F5 LTM to maintain persistence based on a variety of factors. Universal persistence uses a user-defined string (which can be part of the header, cookie, payload, etc.) to maintain persistence.
However, the effectiveness of this method would depend on whether there's a suitable parameter in your traffic that can be used for this purpose. Also, you would need to carefully configure the iRule to ensure it only triggers the Universal Persistence for the affected traffic.
Another option could be to use Destination Address Affinity persistence, which maintains persistence based on destination IP and port, rather than the source. However, this would only be suitable if your back-end servers have different IP addresses.