Buy or Renew
Buy or Renew
cancel
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for 
Search instead for 
Did you mean: 
cancel
Start a conversation
1806
Views
0
Helpful
3
Replies

ACE HTTP to HTTPS Sticky

Cory Peterson
Level 5
Level 5

‎05-25-2011 03:46 AM

I am having problems getting this to work.

I am trying to laod balance a site that is both http and https.This is working fine.

When you are running the Web app at a certain point it switches to HTTPS. This causes the ACE to loadbalance the HTTPS Traffic, but most of the time it does not load balance to the same server so the information that is normally kept ont he server is not transfer to the new server. I need a way to keep the same sticky cookie for both http and https.

These are my current configs. They are not correct as I get a different cooke for both HTTP and HTTPS. Is it possible to use the same cookie for both?

probe https HTTPS_Probe3
  interval 10
  passdetect interval 10
  ssl version all
  request method get url https://www.TEST.com
  expect status 200 200
  open 1
probe http HTTP_Probe3
  interval 10
  passdetect interval 10
  request method get url http://www.TEST.com
  expect status 200 200
  open 1

rserver host WebPD01
  ip address 172.16.1.6
  weight 2
  inservice
rserver host WebPD02
  ip address 172.16.1.7
  inservice
rserver host WebPD03
  ip address 172.16.1.75
  inservice
rserver host WebPD04
  ip address 172.16.1.76
  inservice
rserver host WebPD05
  ip address 172.16.1.77
  inservice
rserver host WebPD06
  ip address 172.16.1.78
  inservice

serverfarm host WebPD_SF
  probe HTTPS_Probe3
  rserver WebPD01 443
    inservice
  rserver WebPD02 443
    inservice
  rserver WebPD03 443
    inservice
  rserver WebPD04 443
    inservice
  rserver WebPD05 443
    inservice
  rserver WebPD06 443
    inservice

serverfarm host WebPD_SF80
  probe HTTP_Probe3
  rserver WebPD01 80
    inservice
  rserver WebPD02 80
    inservice
  rserver WebPD03 80
    inservice
  rserver WebPD04 80
    inservice
  rserver WebPD05 80
    inservice
  rserver WebPD06 80
    inservice

parameter-map type ssl PM3
  session-cache timeout 300
  queue-delay timeout 1

sticky http-cookie TESTlb WebPD_sticky
  cookie insert browser-expire
  replicate sticky
  serverfarm WebPD_SF
sticky http-cookie TESTlb WebPD_sticky80
  cookie insert browser-expire
  replicate sticky
  serverfarm WebPD_SF80


ssl-proxy service SSL_CLIENT_PD
  ssl advanced-options PM3
ssl-proxy service SSL_SERVER_PD
  key TEST.pem
  cert TEST.pem
  ssl advanced-options PM3

class-map type http loadbalance match-all HTTP_PD
  2 match http url .*
class-map type http loadbalance match-all SSL_PD
  description SSL Layer 7 for Web PD
  2 match http url .*
class-map match-all WebPD_VS
  2 match virtual-address 172.16.2.20 tcp eq https
class-map match-all WebPD_VS80
  2 match virtual-address 172.16.2.20 tcp eq www
class-map type management match-any www
  201 match protocol snmp any
  202 match protocol telnet any
  203 match protocol ssh any
  204 match protocol icmp any
  205 match protocol https any
  206 match protocol http any

policy-map type management first-match www
  class www
    permit

policy-map type loadbalance first-match WebPD_VS-l7slb
  class SSL_PD
    sticky-serverfarm WebPD_sticky
    ssl-proxy client SSL_CLIENT_PD
policy-map type loadbalance first-match WebPD_VS-l7slb80
  class HTTP_PD
    sticky-serverfarm WebPD_sticky80

policy-map multi-match WebPD
  class WebPD_VS
    loadbalance vip inservice
    loadbalance policy WebPD_VS-l7slb
    loadbalance vip icmp-reply
    nat dynamic 1 vlan 302
    ssl-proxy server SSL_SERVER_PD
  class WebPD_VS80
    loadbalance vip inservice
    loadbalance policy WebPD_VS-l7slb80
    loadbalance vip icmp-reply
    nat dynamic 1 vlan 302

interface vlan 302
  ip address 172.16.2.4 255.255.255.0
  alias 172.16.2.5 255.255.255.0
  peer ip address 172.16.2.3 255.255.255.0
  fragment chain 112
  access-group input ACL
  nat-pool 1 172.16.2.200 172.16.2.201 netmask 255.255.255.0 pat
  service-policy input www
  service-policy input WebPD
  no shutdown

Labels:
0 Helpful
3 Replies 3

stmccabe
Cisco Employee
Cisco Employee

‎05-25-2011 05:27 AM

If you want to use sticky LB based on cookie, there are a couple of things to you can do, but ideally you would setup dynamic cookie learning and stick based on session cookie set on the webserver.  The server cookie will be set and maintained for this session and all client traffic (HTTP and HTTPS) presented with this server specific session cookie will be persisted on.  The only thing you will need to be careful of is if a subsequent response from server instructs the client to make a new HTTP request (i.e. location header, etc.). In this case you would need to work with your web/app folks to setup site specific redirects on the webservers themselves..

--Configuration guide on how to configure this option:

http://www.cisco.com/en/US/docs/interfaces_modules/services_modules/ace/vA2_3_0/configuration/slb/guide/sticky.html#wp1071193

Another possible option, and again this is without me knowing the application flow, would be to make all traffic SSL to a single VIP policy.. Meaning, setup a redirect for the site if a connection is first established via HTTP (this can be done via a redirect rserver) to redirect the client to HTTPS. If this is done, you will also want to ensure a server generated location header doesn't cause the client to try and make a new http connection, you can re-write the location header to be maintained as ssl (done via action-list command / to do ssl rewrite as server response comes back through -200ok) -

--Config guide for redirect:

http://www.cisco.com/en/US/docs/interfaces_modules/services_modules/ace/vA2_3_0/configuration/slb/guide/rsfarms.html#wp1046009

--Config Guide for ssl - rewrite:

http://www.cisco.com/en/US/docs/interfaces_modules/services_modules/ace/vA2_3_0/configuration/slb/guide/classlb.html#wp1040008

For both of the above options you will need to create a parameter map to instruct the ace to do persistence rebalance..

--Configuration Guide for Persistence rebalance:

http://www.cisco.com/en/US/docs/interfaces_modules/services_modules/ace/vA2_3_0/configuration/slb/guide/classlb.html#wp1062907

A less "granular" method would be to stick based on IP - this would work whether traffic is HTTP or HTTPS as the ACE creates a sticky entry based on clients source IP.  This has it's own caveats - e.g., mega proxy and/or proxy where multiple clients are represented by a single proxy IP - creates "clumping" ..

HTH.

0 Helpful

Cory Peterson
Level 5
Level 5
In response to stmccabe

‎05-25-2011 07:23 AM

Ok, I got this setup and started using a Session ID provided by the Server, I have ensured the cookies are the same, but it still loadbalances the connection to a different server when I switch to https.

The blelow sticky Databse shows the Stickys do not line up between HTTP and HTTPS

sticky group : WebPD_sticky80
type         : HTTP-COOKIE
timeout      : 720           timeout-activeconns : FALSE
  sticky-entry          rserver-instance                 time-to-expire flags  
  ---------------------+--------------------------------+--------------+-------+
  16654257725771741312  WebPD02:80                       37607          -
  17337303565750424621  WebPD02:80                       37702          -
  2959707193734522029   WebPD02:80                       37757          -
  17513740319438450763  WebPD02:80                       37826          -
  17314163098156928995  WebPD02:80                       37843          -
  15349963942543434403  WebPD02:80                       38166          -
  5111478708859931171   WebPD03:80                       38169          -
  12756813240786919277  WebPD04:80                       41136          -
  3020038815990512745   WebPD04:80                       41311          -
  16260417067658327613  WebPD03:80                       41394          -
  6643432373729599067   WebPD03:80                       41412          -
  5789217862541186996   WebPD04:80                       41476          -
  12732748354722635914  WebPD05:80                       41512          -
  10083444411992074718  WebPD06:80                       41763          -
  10756774743654344231  WebPD06:80                       41779          -
  13517627829347016284  WebPD02:80                       42913          -
  14694560347427331811  WebPD02:80                       42961          -
  14294973373842793914  WebPD03:80                       43154          -
sticky group : WebPD_sticky
type         : HTTP-COOKIE
timeout      : 720           timeout-activeconns : FALSE
  sticky-entry          rserver-instance                 time-to-expire flags  
  ---------------------+--------------------------------+--------------+-------+
  16654257725771741312  WebPD01:443                      37690          -
  17337303565750424621  WebPD02:443                      37712          -
  2959707193734522029   WebPD02:443                      37769          -
  17314163098156928995  WebPD02:443                      37887          -
  5111478708859931171   WebPD03:443                      38173          -
  16260417067658327613  WebPD03:443                      38220          -
  12756813240786919277  WebPD03:443                      41163          -
  3020038815990512745   WebPD03:443                      41327          -
  6643432373729599067   WebPD03:443                      41440          -
  12732748354722635914  WebPD04:443                      41527          -
  10083444411992074718  WebPD04:443                      41717          -
  10756774743654344231  WebPD04:443                      41802          -
  5789217862541186996   WebPD04:443                      42930          -
  14294973373842793914  WebPD01:443                      42985          -

0 Helpful

stmccabe
Cisco Employee
Cisco Employee
In response to Cory Peterson

‎05-25-2011 07:52 AM

The behavior you describe is a function of how the web server is setting session cookies.  The web application is instructing the client to setup a new *session* via HTTPS (new session = new session cookie).  The client browser will then present the new cookie and the ACE will learn the new cookie and make a new LB decsion. 

The function of maintaining site persistence with the client -> ace -> app (http/https) in the environment you apps are operating requires a session cookie set and managed by a 'single sign on' web plugin/app..  This is a common requirement for sites that require clients to maintain secured identity as well as application persistence as client is redirected to different app teirs in the web structure..

Reference for single sign on - I think you web app folks should be able to help you with this..

http://en.wikipedia.org/wiki/Single_sign-on

If SSO is possible by your webapplication, then levarging session cookie learning on the ACE will provide you the fucntionality and persistence required.

0 Helpful
Customers Also Viewed These Support Documents