Stickiness between http and https

Unanswered Question
Apr 24th, 2010
User Badges:

Hi,


I have a two new VIPs created ( http and https )


VIP 1 = 10.10.20.15 80      ( Real Servers 192.168.10.45 and 192.168.10.55 listing on port 80 )

VIP 2 = 10.10.20.15 443    ( Real Servers 192.168.10.45 and 192.168.10.55 listing on port 443 )


I would like to maintain stickness across these two VIPs. Is this possible?


For example: User is using a web browsers and types http://10.10.20.15 the user is directed to VIP 10.10.20.15 80 and then to real 192.168.10.55:80 (based on the predictor method) After browing a few http pages, there is a re-direct on the http page to https://10.10.20.15/idbi/index.htm


My understanding is that the browser sends a new request to VIP 10.10.20.15 443 and there is a 50-50 chance that the connection comes back to the 192.168.10.55:443


How can i ensure that the https connection comes back to the same server?


I have tried source ip stickiness. But no luck.


My config is as follows



serverfarm host HTTP-10.10.20.15
  rserver 192.168.10.45 80
    inservice
  rserver 192.168.10.55 80
    inservice


serverfarm host HTTPS-10.10.20.15
  rserver 192.168.10.45 443
    inservice
  rserver 192.168.10.55 443
    inservice

  


     sticky ip-netmask 255.255.255.255 address source vip-10.10.20.15-http
     timeout 30
     replicate sticky
     serverfarm HTTP-10.10.20.15   


     sticky ip-netmask 255.255.255.255 address source vip-10.10.20.15-https
     timeout 30
     replicate sticky
     serverfarm HTTPS-10.10.20.15


Regards


Jack

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 4 (1 ratings)
Loading.
UHansen1976 Sun, 04/25/2010 - 09:28
User Badges:
  • Bronze, 100 points or more

Jack,


My guess is, that because you have two class'es that matches incoming traffic, two sticky-configs and two serverfarms, any subsequent traffic that is matchet against a different class, will be re-loadbalanced towards a different serverfarm. And different stickies will be applied to the https-portion of the flow.


Since you're not translating the dst.port for your traffic, one serverfarm and one sticky-config should be sufficient. I've done this myself for traffic, for which I'm not translating the dst.port and it works fine. Basically, you remove the port parameter and simply configure the ip-address of your rservers, as shown below:


serverfarm host [something]

  rserver 192.168.10.45

    inservice

  rserver 192.168.10.55

    inservice


And one sticky-config:


sticky ip-netmask 255.255.255.255 address [source/destination/both] vip-10.10.20.15

  timeout 30

  replicate sticky

  serverfarm [something]


Then, use the same stickyconfig in both your classes under your multi-match policy. If this doesn't do the trick, plz let me know. Another option would be cookie-based stickyness, although there's a few more things that has to be considered. I would probably use the 'both' parameter in sticky-config, as the sticky would be based on both the src. and dst. address.


hth


/Ulrich

dorsenjack Sun, 04/25/2010 - 14:34
User Badges:

Ulrich,


Thanks for your reply. Was very Helpful. I will try this and get our developers to do their test.


Theoritically I believe your solution will work.


Just out of interest, I have one questionsto ask (for future reference)


How to use the cookie-based stickiness in my scenario?


Jack

UHansen1976 Sun, 04/25/2010 - 23:45
User Badges:
  • Bronze, 100 points or more

Basically, just replace your current sticky config with something like this:


sticky http-cookie [cookie-name] [sticky-group-id]

  cookie insert browser expire

  timeout [seconds]

  replicate sticky

  serverfarm [name]


The 'browser expire' is optional, but simply allows for the browser to determine the expiration of the cookie.


ACE assign a unique cookie-value for each of your rservers by calculating a hashed value based on the rserver ip.addr and port and inserts that value into the database. You can display the content of the database with 'sh sticky cookie-insert group sticky-group-id. The result would be something like this:


   Cookie          |        HashKey               |           rserver-instance
  ------------+----------------------+-------------------+------------------------------------------------------+
  R3055599550 | 7033142962938655715  | serverfarm/realserver:port


This value is inserted into the http-header of the clients request and used for stickyness. However, unless you configure 'persistence rebalance', the ACE will only loadbalance based on the first request. Any subsequent requests will simply be packet-switched to the same rserver, until the end-of-flow or the rserver is taken out of rotation/fails. If you need to inspect your http-header at each request, you need to configure an http-parameter-map with persistence-rebalance.


Additionally, you can assign your own cookie values, rather than using a hashed value. Simply configure the following under your sticky-config:


static cookie-value value rserver rserver-name.


hth


/Ulrich

Actions

This Discussion