cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1735
Views
3
Helpful
4
Replies
Highlighted
Participant

Sticky cookie database problem

Hi All,

I'm having an intermittent issue showing up in an ACE implementation for the Company's ERP system. 

I've setup the ACE to loadbalance across 40 virtual servers (10 each are on 4 physical servers).  They are web servers.  The logical look of it is attached (For ACE VIP resolution2.jpg).  I've also attached the guts of the config (ace config.config).  The ACE is configured to do sticky loadbalancing using a cookie that the servers issue called JSESSIONID.  The ACE itself is a module and this is one context in that module, it isn't an appliance.  The ACE show version follows:

Software
   loader:    Version 12.2[120]
   system:    Version A2(3.2) [build 3.0(0)A2(3.2)]
   system image file: [LCP] disk0:c6ace-t1k9-mz.A2_3_2.bin
   installed license: ACE-08G-LIC ACE-SEC-LIC-K9

The basic flow of the environment is:

1.  The client goes to the ERP login page via a web browser (this is done via citrix, however for troubleshooting I've bypassed the citrix environment)

2.  client is presented with a login page (frames 1 to 324 in the attached capture)

  • client is given a cookie (see frame 29 in the capture).  This cookie makes an entry in the sticky database

BNESSB2ACE1/JDE_PROD_ENV# sh sticky data http-cookie 8Ts9NmTMLyD0pvTjrVC3WGR8RXsh2nJRRK81CCCK2RNHh4RpVV9L!-1876055778

sticky group : STICKY_COOKIE

type         : HTTP-COOKIE

timeout      : 120           timeout-activeconns : FALSE

  sticky-entry          rserver-instance                 time-to-expire flags  

  ---------------------+--------------------------------+--------------+-------+

  8381466903803585004   BNEORA03:9814                    7101           -

  • That cookie is sent to the server for each consequent request which is usual. 
  • In frame 88 of the capture, another cookie is sent from the server to the client, and again, it creates an entry in the sticky database (to the right server).

BNESSB2ACE1/JDE_PROD_ENV# sh sticky data http-cookie GSsRNmTM8vykdRgsn8ZwDC6B02NPwb8Tw2L8QPzB73vcqJKhVyCf!-1568921065

sticky group : STICKY_COOKIE

type         : HTTP-COOKIE

timeout      : 120           timeout-activeconns : FALSE

  sticky-entry          rserver-instance                 time-to-expire flags  

  ---------------------+--------------------------------+--------------+-------+

  11103266344847118252  BNEORA03:9814                    6866           -

  • The client then uses that cookie for subsequent GET requests, which is usual, all the way through to frame 332 of the capture.
  • In frame 352 of the capture, the server sends a new cookie to the client.  This cookie DOES NOT get an entry in the sticky database

BNESSB2ACE1/JDE_PROD_ENV# sh sticky data http-cookie r3QPNmTR84v6jGhCfvLmJtyl2QQBGpmJFnv5j6sdDp6D8VbvxT2h!-1876055778

BNESSB2ACE1/JDE_PROD_ENV#

  • The client, as usual, uses the new cookie for all of the subsequent requests however because there is no sticky entry, the user can’t get past the login screen.

Do any of you helpful people out there have any idea why the ACE would not put that last cookie into the sticky database?

Thanks for any help, and I’ll be sure to rate posts!

Brad


1 ACCEPTED SOLUTION

Accepted Solutions
Highlighted

Hi.

This is a form of best practice, i don't have time to search on the internet right now (I have to go to work :-) ) but the reason is pretty simple to explain. Cookies inserted by the application servers are related to user's sessions in the application.

What you need is not to track sessions but to remember the server that was selected by the LB algorithm. There's a 1-to-1 mapping between all the services in your serverfarm and the value of the cookie inserted by the ACE. That's all

The logic is not the same, also inserting a cookie on the ACE consumes near no resource as oposed to track all user's sessions going through the ACE.

Ce message a été modifié par: Surya ARBY

View solution in original post

4 REPLIES 4
Highlighted
Enthusiast

Maybe a bug, I don't know why the ACE flushes the sticky table, but your application seems to be browser-based according to the User-Agent. The right persistance method for browser-based applications is to insert a cookie (not to learn it) with a timeout of 0 (browser expire)

Try this :

ACE-1/routed(config)# sticky http-cookie ACE-p web-sticky
ACE-1/routed(config-sticky-cookie)# cookie insert browser-expire
ACE-1/routed(config-sticky-cookie)# replicate sticky
ACE-1/routed(config-sticky-cookie)# serverfarm JDE_PROD_ENV_SVRS

The persistance cookie will be named ACE-p

Highlighted

Hello there and thanks for your reply!

I'll give what you suggest a shot.  I also notice that there's a new version of code for the hardware so I'll upgrade that first to see if anything changes.

In relation to the "right persistance method for browser-based applications", do you have a link or something that explains this?  I was under the impression (false maybe?) that the insert cookie thing was to be done if the server itself doesn't set-cookie, so it needed the ACE to.  Is that incorrect?

Thanks again for replying!

Brad

Highlighted

Hi.

This is a form of best practice, i don't have time to search on the internet right now (I have to go to work :-) ) but the reason is pretty simple to explain. Cookies inserted by the application servers are related to user's sessions in the application.

What you need is not to track sessions but to remember the server that was selected by the LB algorithm. There's a 1-to-1 mapping between all the services in your serverfarm and the value of the cookie inserted by the ACE. That's all

The logic is not the same, also inserting a cookie on the ACE consumes near no resource as oposed to track all user's sessions going through the ACE.

Ce message a été modifié par: Surya ARBY

View solution in original post

Highlighted

Hi again,

I've changed the config to match what you suggest, so far it looks good.

Thanks a lot for your kind help, it is very much appreciated!

Brad