Forum Discussion
NimbostratusPersistence problem due to client using citrix
Hi,
We have an internal developed application which is load balanced using the F5 device across multiple pool members using different tcp ports. Within one day a user must stick to the same pool member, to do this we have just used source address persistence which has worked perfectly fine until now. One of our clients uses Citrix so once the traffic hits the F5 device we are presented with one source ip address for all sessions. Are there any other methods we can use to maintain persistence?
Thanks
Darren
What_Lies_Bene1Cirrostratus
Can you tell us what the traffic type/protocol being used is please?
Dazzla_20011Hi,
We just load balance across different TCP ports, the health monitor applied to the pools is TCP. Not sure about the traffic type or protocol but I will try and find out.
Thanks- Dazzla_20011Hi,
We just load balance across different TCP ports, the health monitor applied to the pools is TCP. Not sure about the traffic type or protocol but I will try and find out.
Thanks - What_Lies_Bene1OK, it might save time if you just post the Virtual Server and Pool configurations?
- Dazzla_20011Hi,
Config is very simple.
pool hmlpphs_bbg {
lb method least conn
action on svcdown reset
monitor all monitor_Jade
members {
10.72.0.34:63201 {}
10.72.0.34:63202 {}
10.72.0.34:63203 {}
10.72.0.34:63204 {}
10.72.0.34:63205 {}
10.72.0.34:63206 {}
10.72.0.34:63207 {}
10.72.0.34:63208 {}
10.72.0.34:63209 {}
10.72.0.34:63210 {}
10.72.0.34:63211 {}
10.72.0.34:63212 {}
10.72.0.34:63213 {}
10.72.0.34:63214 {}
virtual hmlpphs_bbg {
pool hmlpphs_bbg
destination 10.128.153.2:63201
ip protocol tcp
persist src-sticky-internal
monitor monitor_Jade {
defaults from tcp
interval 60
timeout 181
profile persist src-sticky-internal {
defaults from source_addr
mode source addr
timeout 43200
Thanks - Dazzla_20011Hi,
Config is very simple.
pool hmlpphs_bbg {
lb method least conn
action on svcdown reset
monitor all monitor_Jade
members {
10.72.0.34:63201 {}
10.72.0.34:63202 {}
10.72.0.34:63203 {}
10.72.0.34:63204 {}
10.72.0.34:63205 {}
10.72.0.34:63206 {}
10.72.0.34:63207 {}
10.72.0.34:63208 {}
10.72.0.34:63209 {}
10.72.0.34:63210 {}
10.72.0.34:63211 {}
10.72.0.34:63212 {}
10.72.0.34:63213 {}
10.72.0.34:63214 {}
virtual hmlpphs_bbg {
pool hmlpphs_bbg
destination 10.128.153.2:63201
ip protocol tcp
persist src-sticky-internal
monitor monitor_Jade {
defaults from tcp
interval 60
timeout 181
profile persist src-sticky-internal {
defaults from source_addr
mode source addr
timeout 43200
Thanks - Dazzla_20011Hi,
Config is very simple.
pool hmlpphs_bbg {
lb method least conn
action on svcdown reset
monitor all monitor_Jade
members {
10.72.0.34:63201 {}
10.72.0.34:63202 {}
10.72.0.34:63203 {}
10.72.0.34:63204 {}
10.72.0.34:63205 {}
10.72.0.34:63206 {}
10.72.0.34:63207 {}
10.72.0.34:63208 {}
10.72.0.34:63209 {}
10.72.0.34:63210 {}
10.72.0.34:63211 {}
10.72.0.34:63212 {}
10.72.0.34:63213 {}
10.72.0.34:63214 {}
virtual hmlpphs_bbg {
pool hmlpphs_bbg
destination 10.128.153.2:63201
ip protocol tcp
persist src-sticky-internal
monitor monitor_Jade {
defaults from tcp
interval 60
timeout 181
profile persist src-sticky-internal {
defaults from source_addr
mode source addr
timeout 43200
Thanks - What_Lies_Bene1OK, so definitely not HTTP traffic then and no SSL termination? If that's the case Hash persistence may be your only option, however, in order to use it you'll need to analyze the traffic to identify some sort of string in the payload that uniquely identifies each connecting host so it can be used to maintain persistence.
- Dazzla_20011Hi,
Would you mind explaining in simple terms how the hash persistence actually works? I've looked at the hash pesistenc profile but I'm not sure how I would set it up. I presume I would be interested in the hash start and end patterns but what is this? I will do more research into this so I can fully understand it.
Tahnks for your help.
Darren - What_Lies_Bene1
I've never actually used it but essentially (in this case) you can use the fields in the Hash persistence profile, or an iRule specified in the profile to identify a pattern/string within the packet payload/data that can be used to uniquely identify the client and thus persist connections from that client on the basis that the client data will always contain that pattern/string. If we just need the iRule, Universal persistence is also an option.
I'm not experienced in determining what the hash start and end patterns are or what an iRule for this might look like but I'm sure I can work it out, however, you'll need to analyse the application traffic (using tcpdump or something similar) and find a pattern or string in the payload that we can work with.