Forum Discussion

Dazzla_20011's avatar
Dazzla_20011
Icon for Nimbostratus rankNimbostratus
Oct 08, 2012

Persistence 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

 

10 Replies

  • Hi,

     

     

    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
  • Hi,

     

     

    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
  • Hi,

     

     

    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

     

     

  • Hi,

     

     

    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

     

     

  • Hi,

     

     

    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

     

     

  • OK, 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.
  • Hi,

     

     

    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
  • 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.