Layer 7 load balancing on ACE 4710

[alleghieri]

I am successfully load-balancing to an HTTP serverfarm across the associated real servers.  Users can navigate to all pages on the websites.  But we have a new requirement; that users be able to open "micro-sites" within the main sites directly without using links on the main page to navigate.  For example, an end-user can currently navigate to http://www.atestsite.com and all links on that site.  Now the user must be able to access http://www.atestsite.com/subsite directly by typing the URL into the address field.  When I test this throug the ACE, everything behind the .com/ is removed and the user is redirected to the main site.

The sub-site is up and running properly, and can be accessed from within the subnet on which the web server resides.  It is only outside the ACE that we have problems.  I believe this requires a layer 7 policy, but am not familiar with this type of configuration.  Any assistance would be greatly appreciated.  A sanitized version of the config including the relevant parts follows:

access-list TEST_WEB line 24 extended permit tcp any any
access-list NAT_TEST_WEB line 3 extended permit tcp any host 10.64.74.41 eq https

rserver host RS_TEST_1

  ip address 10.64.64.41

  inservice

serverfarm redirect REDIRECT
  rserver http
    inservice

serverfarm host SF_TEST_1
  rserver RS_TEST_1 80
    inservice

parameter-map type ssl SSL_TERMINATION
  cipher RSA_WITH_RC4_128_MD5
  cipher RSA_WITH_RC4_128_SHA
  cipher RSA_WITH_3DES_EDE_CBC_SHA
  cipher RSA_WITH_AES_128_CBC_SHA
  cipher RSA_WITH_AES_256_CBC_SHA

sticky ip-netmask 255.255.255.0 address both STICKY_TEST_1
  timeout 600
  replicate sticky
  serverfarm SF_TEST_1

ssl-proxy service SSL_TEST_1
  key TESTkey
  cert TESTcert
  chaingroup TESTCHAIN
  ssl advanced-options SSL_TERMINATION

class-map match-any NAT_TEST_WEB
  2 match access-list NAT_TEST_WEB

class-map type http loadbalance match-all TEST_SUB_1
  3 match http url /sub

class-map match-any TEST_VIP_1
  description VIP for TEST 1
  2 match virtual-address 10.64.74.41 tcp eq https

class-map match-all VS_TEST
  description VIP for HTTP Redirect
  2 match virtual-address 0.0.0.0 0.0.0.0 tcp eq www

policy-map type loadbalance first-match LB_TEST_1
  description Load Balancing Policy for Web 1
  class TEST_SUB_1
    sticky-serverfarm STICKY_TEST_1
  class class-default
    sticky-serverfarm STICKY_TEST_1

policy-map multi-match TEST_WEB_POLICY
  class NAT_TEST_WEB
    nat dynamic 1 vlan 974
  class TEST_VIP_1
    loadbalance vip inservice
    loadbalance policy LB_TEST_1
    loadbalance vip icmp-reply active
    ssl-proxy server SSL_TEST_1

interface vlan 111
  description ***Front End VIP interface***
  ip address 10.64.74.254 255.255.255.0
  alias 10.64.74.252 255.255.255.0
  peer ip address 10.64.74.253 255.255.255.0
  access-group input TEST_WEB
  service-policy input TEST_WEB_POLICY
  no shutdown
interface vlan 222
  description ***Back End Server Interface***
  ip address 10.67.240.156 255.255.255.240
  alias 10.67.240.155 255.255.255.240
  peer ip address 10.67.240.157 255.255.255.240
  access-group input TEST_WEB
  nat-pool 1 10.67.240.158 10.67.240.158 netmask 255.255.255.240 pat
  no shutdown

[stmccabe]

In the trace we can see the server setting the location header to itself:

HTTP/1.1 301 Moved Permanently

Content-Type: text/html; charset=UTF-8

Location: http://12.130.236.60/hcc/

Server: Microsoft-IIS/7.0

X-Powered-By: ASP.NET

Date: Wed, 16 Mar 2011 21:05:20 GMT

Content-Length: 148

--- On the ACE you have the right idea, just need to modify the location header and rewrite the location from http://12.130.236.60/hcc to http://ACE_VIP_IP/hcc.  This will then force the client to send subsequent request to ACE versus bypassing the ACE and making connection directly to server:

Example config:

action-list type modify http REWRITE
  header rewrite request HCC header-value "12\.130\.236\.60/hcc" replace "10\.64\.64\.41/hcc/"

[alleghieri]

I want to thank everyone for their input.  Working with TAC, we finally found a solution, as follows:

1. Configure a new redirection rhost and serverfarm:

rserver redirect http-hcc
  webhost-redirection https://12.130.236.60/hcc/
  inservice

serverfarm redirect http-hcc
  rserver http-hcc
    inservice

2.  Configure a parameter map enabling persistance-rebalance:

parameter-map type http HCC
  persistence-rebalance

3.  Configure a class-map to match on the URL that requires the redirection:

class-map type http loadbalance match-all OCGB_HCC_2
  2 match http url /hcc*

4. Add the class-map to the load-balancing policy-map

policy-map type loadbalance first-match LB_OCGB_1
  class OCGB_HCC_2
    serverfarm http-hcc

5. Call the parameter-map in the multi-match policy-map

policy-map multi-match GSB_WEB_POLICY
  class OCGB_VIP_1
    loadbalance vip inservice
    loadbalance policy LB_OCGB_1
    loadbalance vip icmp-reply active
    appl-parameter http advanced-options HCC
    ssl-proxy server SSL_OCGB_1

The root cause of the problem is that the client did not include a trailing "/" behind the hcc.  The IIS is configured by default to send a courtesy redirect to add the trailing "/". The client, for some reason, cannot process the redirect properly and strips the hcc from the subsequent GET requests.

This configuration intercepts the first GET request and sends a redirect to the client.  The client then connects using the trailing "/".  The server sees the GET request with the trailing "/", so it does not send the courtesy redirect.

When this site goes into production, it will be necessary to change the URL in the rserver redirect portion to use the actual domain name rather than the IP address.

Special thanks to Willy Munoz at TAC for coming up with the solution.

Again, thanks to all who contributed to this thread.  I hope the solution helps others in a similar situation.