For more information regarding the security incident at F5, the actions we are taking to address it, and our ongoing efforts to protect our customers, click here.

Forum Discussion

yoshijo_100578's avatar
yoshijo_100578
Icon for Nimbostratus rankNimbostratus
Feb 11, 2008

Issue about Session Persistence Problem

I'm trying to deploy LTM 9.4.1 Build 29.2 clustering mode, and my environment like this...

 

 

VIP 192.168.100.1:80 SNAT automap

 

VIP 192.168.100.1:443 SNAT automap

 

 

and pool

 

 

Pool HTTP member 192.168.100.3:80, 192.168.100.4:80 round robin method

 

Pool HTTPS member 192.168.100.3:443, 192.168.100.4:443 round robin method

 

 

I use source address persistence with "Match Across Services" and "Mirror Persistence"

 

 

and Web Pages procedures like

 

 

Index[HTTP] = login page

 

when user login, It's check with HTTPS pages

 

then back to Index[HTTP] with logon information.

 

and use content with HTTP and HTTPS

 

 

....Some of client have a problem about after they login, HTTPS can remember that persistence connection, but HTTP is disconnected. I think it may be a problem about source persistence, but very few clients have a problem, So I'm don't sure its about source persistence problem. Can I know a root causes of problem?

 

 

Thanks for advanced,

 

 

yoshijo
config
design

1 Reply

  • hoolio's avatar
    hoolio
    Icon for Cirrostratus rankCirrostratus
    Feb 11, 2008
    Hello,

     

     

    Intermittent persistence failure can be caused by a pool member being marked down. Also, you might find that you need a OneConnect profile, if multiple HTTP requests from different clients are being made over the same TCP connection to the virtual server.

     

     

    You can write out the persistence table records using the following command (all on one line):

     

     

    while true; do echo "--------------------"; date; b persist all show all; sleep 1; done | tee -a /var/tmp/b.persist.all.out

     

     

    If you're able to reproduce the failure, you could log the persistence table output to a file to see what the BIG-IP sees when the failure occurs. It might also help to capture a tcpdump while testing.

     

     

    Aaron