Layer 7 load balancing on ACE 4710

alleghieri · ‎03-15-2011

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

sachinga.hcl · ‎03-15-2011

Hi Miachel,

Instead of using

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

Please try

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

Use the following URL for further information:

http://docwiki.cisco.com/wiki/Cisco_Application_Control_Engine_(ACE)_Module_Troubleshooting_Guide,_Release_A2(x)_--_Troubleshooting_Layer_7_Load_Balancing#Overview_of_ACE_Layer_7_Load_Balancing

HTH

Sachin

alleghieri · ‎03-16-2011

Sachin,

Thanks for the suggestion, but the change was not successful. When I try to connect to http://www.testsite.com/sub, the /sub is removed from my browser and I am redirected to the main page.

Let me know if you have any other suggestions. I'll be glad to give them a try. :-)

Michael

alleghieri · ‎03-16-2011

PS: Here is the output of a show service-policy detail command:

    class: TEST_VIP_1
      ssl-proxy server: SSL_TEST_1
     VIP Address:    Protocol: Port:
     10.64.74.41     tcp        eq    443
      loadbalance:
        L7 loadbalance policy: LB_TEST_1
        Regex dnld status    : SUCCESSFUL
        VIP ICMP Reply       : ENABLED-WHEN-ACTIVE
        VIP State: INSERVICE
        Persistence Rebalance: ENABLED
        curr conns       : 1         , hit count        : 288
        dropped conns    : 55
        client pkt count : 18886     , client byte count: 1727808
        server pkt count : 17528     , server byte count: 21926545
        conn-rate-limit      : 0         , drop-count : 0
        bandwidth-rate-limit : 0         , drop-count : 0
        L7 Loadbalance policy : LB_TEST_1
          class/match : TEST_HCC_1
            LB action: :
               sticky group: STICKY_TEST_1
                  primary serverfarm: SF_TEST_1
                    state:UP
                  backup serverfarm : -
            hit count        : 3
            dropped conns    : 0
            compression      : off
          class/match : class-default
            LB action: :
               sticky group: STICKY_TEST_1
                  primary serverfarm: SF_TEST_1
                    state:UP
                  backup serverfarm : -
            hit count        : 32
            dropped conns    : 0
            compression      : off
      compression:
        bytes_in : 0                          bytes_out : 0
        Compression ratio : 0.00%
                Gzip: 0               Deflate: 0
      compression errors:
        User-Agent : 0               Accept-Encoding    : 0
        Content size: 0               Content type       : 0
        Not HTTP 1.1: 0               HTTP response error: 0
        Others      : 0

Surya ARBY · ‎03-16-2011

please send a wireshark or live http headers trace. It seems that your web servers send 301 or 302 redirections.

is it in production in the internet ? Can we check the applciation behavior ?

alleghieri · ‎03-16-2011

As it is a test site, there is no domain name; you need to use the IP address as follows:

https://12.130.236.60/hcc

You wil notice that when you enter that address in the browser, the /hcc will be stripped and you will be sent to the main page.

Because it is https, a packet capture from the end host will not reveal much. I have attached a dump from the ACE. The action begins at packet number 20. That is the GET request from the client with the /hcc at the end of the url. In packet 21, the server sends a response type 301; moved permanently message. In packet 27, the host sends another Get request with the /hcc extension. In packet 29, it appears that the ACE sends a 301 response with a close code. In packet 33, the client closes the connection, then re-opens it and sends a GET request without the /hcc extension.

Cheers,

mb

Surya ARBY · ‎03-16-2011

Hi. The site is not accessible from my location.

As I read your config, the ACE is not configured to send any redirection, I guess it comes from the web servers itself. Can you send a pcap file of the capture ?

alleghieri · ‎03-16-2011

Attached is a wireshark capture from the server. All of the action takes place in packets 4-7. You will see the original GET request, a 301 response, then the new GET request minus the /hcc.

Any suggestions?

Surya ARBY · ‎03-16-2011

Hi.

The /hcc site is not configured on the web server (IIS) or maybe ther's a policy applied somewhere, it's not the ACE which send the redirection but the web server itself.

alleghieri · ‎03-16-2011

Yes, the hcc site is configured on the server. A browser on another server on the same subnet can reach the site without any problems. The ACE should simply pass the request on to the server. I don't know why the client removes the /hcc on the next attempt.

Surya ARBY · ‎03-16-2011

Can you try to reach the server directly from another subnet, but not by hitting the VIP bound on the ACE ?

alleghieri · ‎03-16-2011

Yes, but not easily. It would require changes to a production firewall, and that must go through the change management process. We could arrange it, but it will take some time.

Surya ARBY · ‎03-17-2011

Can you check the IIS logs with the server guys to be sure that the redirect is sent by the server ?

alleghieri · ‎03-18-2011

Yes, the redirect is being sent by the server.

I've been trying a different approach: using an http header rewrite to ensure the header that reaches the server is correct. Because the name is not yet registered with DNS, we rely on IP addresses to make the connection. I've tried multiple header rewrite combinations, but I'm not certain of the correct syntax. Below is an example:

parameter-map type http HCC_REWRITE
persistence-rebalance
header modify per-request

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

class OCGB_VIP_1
    loadbalance vip inservice
    loadbalance policy LB_OCGB_1
    loadbalance vip icmp-reply active
    appl-parameter http advanced-options HCC_REWRITE
    ssl-proxy server SSL_OCGB_1

Any suggestions?

Surya ARBY · ‎03-18-2011

I doubt you'll fix the issue on the ACE, the issue is related to the web front end, you have to check why IIS is sending this redirection which is unexpected. maybe it's related to your source nat