Forum Discussion
NimbostratusUniversal persistence using header values for multiple client IPs.
Hello all,
I require universal persistence based upon a XFF header value, but for any source IP. The scenario is that an initial client connection hits the F5 and is load balanced to node A (the F5 need to persist to a member in poolA using XFF value received or inserted). Then a back end server makes a connection to the F5 and sends the XFF value that was originally received from the client, targets the same VS but a different poolB. This connection must persist to the same node A as in the separate connection from the client. Is this possible using persist lookup functions?
11 Replies
- Kai_Wilke
MVP
Hi ajohnson,
Match across services will not work as the client is not the same and therefore the target pool member selection and resultant persistence entry will be completely independent.
The
method isn't aware of the client. It will create/query persistence information based on a free-text values which would in your case either the[persist uie]
-string value if a client connects, or the[IP::client_addr]
-string value if the backend system connects. This approach WILL team the connections accordingly even if the underlying connection is comming from different SRC_IPs.X-Forwarded-For=[IP::client_addr]The
option is mandatory in your specific case and allows LTM to resolve persistence entries in a X.X.X.X:any style, so that an existing persistence record for poolA:1.2.3.4:994 can be reused to persist request to poolB:1.2.3.4:499.Match across servicesIf you've doubts, then build a lab environment, apply the
iRule at the buttom of this thread and check if the persist information for 1.2.3.4:994 (entry will be shown in the persist table) will be reused for acces to 1.2.3.4:499 (no additional entry will be shown in the persist table). In addition perform failovers as needed and notice that (for an example) a connection to poolA:1.2.3.4:994 will create a persist entry for poolA:1.2.3.4:994 and that this entry will become overwritten (via Force Offlines of poolB:1.2.3.4:499) to poolB:1.2.3.5:499 and which will cause the initial connection to poolA:1.2.3.4:994 to automatically fail over to poolA:1.2.3.5:994.[persist uie]Client makes a connection to the F5, the F5 sets a persistence record to a pool member based upon XFF or another header I insert (maybe containing the selected pool member). Then when the server makes it's connection the F5 will see either the preserved XFF value (or the headre value for the selected pool member in the first connection) and will target the same IP.
See the
iRule at the buttom of this thread. It does exactly what you've asked for... 😉[persist uie]Cheers, Kai
