Rewrite for another Virtual Server (Cookies and Sessions)

Yeah, the only thing common between the requests from VS1 that go to pool2 and VS2 that go to pool2 will be the source and destination IP address. Source address will be the client IP and out of the two options would be the better one for persistence. Destination address persistence works better for load balancing outbound caching servers or links.

 

 

I assumed you needed to use cookie persistence for this. If you do need to use cookie persistence, I think you'd need to redirect the client from site1/apa_core to site2. You could then use the Proxypass iRule to rewrite /apa_core to /apa if this is a requirement.

 

 

Aaron

I'm going to shoot this pass the developers to see if we can change from default cookie persistence/fallback source_addr to default source_addr/fallback cookie. Sorry to say since site1 is a different domain we can not do a redirect to site2, we have to do a rewrite. As I have it, once a user request www.site1.com/apa_core and is "redirected" to www.site2.com the jboss app throws an exception. Utimately we're trying to prevent building a jboss instance for site1 and another for site2.

The only valid fallback persistence method is source address, so you won't be able to do primary source address and fallback cookie. Also, if you do use source address persistence, you'll want to use the match across virtuals option:

 

 

SOL5837: Match Across options for session persistence

 

https://support.f5.com/kb/en-us/solutions/public/5000/800/sol5837.html

 

 

Aaron

Hot dang, I love devCentral! F5 forever! Thanks Aaron!

Aaron,

 

 

I'm back. I created a source_addr persistence profile and assigned the profile to the vs2 virtual server. Persistence is still breaking on the rewrite to vs2 (pool2).

 

 

From our persistence records:

 

172.16.1.1Source Address Affinityvs3pool3172.16.1.3346 seconds

 

172.16.1.1Source Address Affinityvs2pool3172.16.1.339 seconds

 

172.16.1.1Source Address Affinityvs2pool2192.168.1.22:809 seconds

 

172.16.1.1Source Address Affinityvs1pool2192.168.1.23:803 seconds

 

172.16.1.1Source Address Affinityvs1pool1172.16.1.314 seconds

 

 

When the client connects to pool2 we need them to connect to the same pool member during a session. I'm lost, I thought I had something going.

That's odd. Do you have match across virtuals enabled on the source address persistence profile? If so, which LTM version and platform are you running? You can run 'b version |head' and 'b platform|head' to get this info.

 

 

Thanks,

 

Aaron

Kernel:

 

Linux 2.4.21-9.4.8.355.0smp

 

Package:

 

BIG-IP Version 9.4.8 355.0

 

Final Edition

 

 

Enabled Features:

 

QoS and ToS Tagging

 

Connection Limits

 

OneConnect - Switching and Pooling

 

BIGpipe parsing error:

 

01020058:3: Error writing to a file.

 

 

PLATFORM INFORMATION --

 

| Marketing Name: BIG-IP 6400

 

| BIOS Rev: AMIBIOS(C)2003 American Megatrends, Inc. BIOS Date: 01/22/08 11:50:10 Ver: 08.00.10 TYAN Thunder K8S/K8S-D Pro BIOS vF5-41 OBJ-0226-03 REV. B

 

| base MAC: 00:01:D7:7B:4D:40

 

| PVA Version: 2

 

+-> SYSTEM INFO

 

| Type: D63a

 

| Chassis serial: bipxxxxxxxs Level 200 part: 200-0258-16 REV C

 

| Switch board serial: PCA0101M0CC0 part: PCA-0101-03 REV G

 

| Host board serial: TY8FB12A0124 part: MOB-0018-06 REV A

 

 

 

 

Aaron,

 

 

I posted my BigIP version and such. Following that I opened a support case the F5 who is also stuck on this one. I've escalated the case since the virtual servers are due to go live on Sunday. We have tried source address affinity on all the virtual servers involved yet when the write takes place, persistence is still being lost.

 

 

One suggestion F5 support made was to modify the ProxyPass irule to look up entries in the persistence table and if they exist, set the destination to the one marked in the table, rather than just setting the pool. You have any ideas on this?