sticky sessions and proxy

can you provide persistence profile config of your big-ips?

hi, below the VIP config and a image from the cookie persistence profile

Code 
ltm virtual bn8745_http { 
destination 96.127.x.20:https 
fallback-persistence source_addr 
ip-protocol tcp 
mask 255.255.255.255 
persist { 
xm_ bn8745_cookie { 
default yes 
} 
} 
policies { 
asm_auto_l7_policy__vip_ bn8745_http { } 
} 
pool pool_ bn8745_http 
profiles { 
ASM_ bn8745https { } 
bn8745_wildcard_sha2_ssl { 
context clientside 
} 
websecurity { } 
xm_ bn8745_tcp-lan-optimized { 
context serverside 
} 
xm_ bn8745_tcp-wan-optimized { 
context clientside 
} 
xm_ bn8745_live_https_profile { } 
xm_oneconnect { } 
} 
rules { 
xm_ bn8745_clientip 
xm_https_header_replace 
} 
security-log-profiles { 
"Illegal and Attacks" 
} 
source 0.0.0.0/0 
source-address-translation { 
type automap 
} 
translate-address enabled 
translate-port enabled 
vs-index 46 
}

Ok, this is one big-ip only. 1) It is not clear if you you facing the issue on public vip only or on both of them. 2) The cookie is valid for session only. It means that, if you close your app on the client side, next time new session will use another pool member.

By telling "if we do some upload test from the same source, we always land on different web server. " do you mean you close the application, open it and upload again?

Per surgeon, perhaps you should just use source-address persistence instead of cookie and be done with it.

the issue is only on the web server pool. on the second VIP, we changed the persistence profile to source ip. wit the new setup: public VIP cookie, web server VIP source ip, the sticky session over the proxy are working now.

Could you answer my question I asked before?

hi surgeon no, we don't close the application. for testing we used a gallery application with an in-memory queue on each web server. the user uploads 16 picture at the same time, so all of the pictures have to land on the same web server.

Hi Dan, Can you check pool member status. Is there any monitor flap?

I do not see any issue with the config. If Monitor status is stable then maybe you need to open a case with support. Decrypted packet capture analysis is required.

hi surgeon, thanks for you help. we will open a support case.

"(contains a irule to redirect sub-domains to the f5 proxy pool and configured persistence profile with cookie01 and snat)"

Do you use the pool command, as that triggers a new load balance decision?

https://devcentral.f5.com/wiki/irules.pool.ashx

I did not understand which one is the virtual server that you have persistence problem. which one is?

If not the above one, can you provide that virtual server configuration? Can you provide also the iRule and oneconnect profile?