cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
5503
Views
10
Helpful
6
Replies

ACE header rewrite with loadbalancing

edgarfc254
Level 1
Level 1
6 Replies 6

chrhiggi
Level 3
Level 3

Hello,

Can you clarify what you are asking for me just a bit?

ACE can actually add/delete/modify a any header or URL in an HTTP request as it passes through the loadbalancer.  What you are asking sounds more like you want to do a redirect than a rewrite.

Example of a redirect:

A client makes a connection and asks for http://www.url1.com

ACE sends a 302 redirect to either url https://www.server1.com or https://www.server2.com

Example of a rewrite:

A client makes a connection and asks for http://www.url1.com/images/cisco.jpg

ACE rewrites the url to http://www.url1.com/pictures/cisco.jpg and sends the request to a server within the serverfarm.

Is it either of those, or something else?

Regards,

Chris

If I understand you well, it seems to be a case of redirection if the Virtual IP address is considered as a different server.

The client makes a connection to a Virtual IP of a serverfarm, depending on the url making the connection (for staffonline - gets redirected to TCP port 483 and studentsonline - redirected to port 443) sign-on pages.

My understanding of redirection is from one server to another (in this case the servers are loadbalanced, the VIP will do the redirection). From your example, rewrite seems to imply that the request is still going to the same server but being pointed to a different location.

If its the case, then my situation might seem to be requiring both redirection and rewriting, if that is possible. My first assumption was that redirecting and rewriting was the same thing.

You can send a redirect to anything/anywhere you like, generally speaking, you would send a redirect back to the same vip on a different port as you were noting initially.

Config Example:

The second redirect is a static redirect, meaning we don't care what the url or domain was, we are just sending the client to a specific place.

rserver redirect REDIRECT-TO-HTTPS

webhost-redirection https://%h:9999%p 301

inservice

rserver redirect REDIRECT-TO-HTTPS-2

webhost-redirection https://www.cisco.com/images/cisco.jpg 301

inservice

rserver host SERVER_01

  ip address 10.10.10.20

  inservice

rserver host SERVER_02

  ip address 10.10.10.21

  inservice

action-list type modify http REWRITE

  ssl url rewrite location .* sslport 443 clearport 80

serverfarm redirect REDIRECT-SERVERFARM

rserver REDIRECT-TO-HTTPS

inservice

serverfarm redirect REDIRECT-SERVERFARM-2

rserver REDIRECT-TO-HTTPS-2

inservice

serverfarm host REAL_SERVERS

  probe HTTP-KEEPALIVE

  rserver SERVER_01 80

    inservice

  rserver SERVER_02 80

    inservice

ssl-proxy service SSL_SERVICE

  key mykey.pem

  cert mycert.pem

class-map match-all HTTP-VIP

  2 match virtual-address 172.21.162.178 tcp eq http

class-map match-all HTTP-VIP-2

  2 match virtual-address 172.21.162.178 tcp eq 81

class-map match-all HTTPS-VIP

  2 match virtual-address 172.21.162.178 tcp eq 9999

policy-map type loadbalance first-match REDIRECT-PM

  class class-default

    serverfarm REDIRECT-SERVERFARM

policy-map type loadbalance first-match REDIRECT-PM-2

  class class-default

    serverfarm REDIRECT-SERVERFARM-2

policy-map type loadbalance first-match LOAD-BALANCE-PM

  class class-default

    serverfarm REAL-SERVERS

    action REWRITE

policy-map multi-match WEB-TRAFFIC

  class HTTP-VIP

    loadbalance vip inservice

    loadbalance policy REDIRECT-PM

  class HTTP-VIP-2

    loadbalance vip inservice

    loadbalance policy REDIRECT-PM-2

  class HTTPS-VIP

    loadbalance vip inservice

    loadbalance policy LOAD-BALANCE-PM

    loadbalance vip icmp-reply active

    ssl-proxy server SSL_SERVICE


This example has 2 different parts - a redirect that catches the client's initial request, and a rule to catch the redirected request.

The first part is in either purple or red.

If a client comes in on port 80, they will hit this rule: webhost-redirection https://%h:9999%p 301

If a client comes in on port 81, they will hit this rule: webhost-redirection https://www.cisco.com:9999/images/cisco.jpg 301

Both redirects send the client off to a new location which is HTTPS specifically, but they are different about how they do so.

The first redirect url makes use of a copy/paste function within our code. %h will look at the client host header and %p copies the url.  the "301" at the end of the string is the HTTP response code type (301 permenant, or 302 moved)

Exmple:

The client sends this:

GET /cisco/rules.html

Host: www.cisco.com

Connection: Keep-Alive

Cookie: JSESSION-ID=123456789abcd

ACE sends a 301 redirect to the url:

https://www.cisco.com:9999/cisco/rules.html

Exmple:

The client sends this:

GET /cisco/rules.html

Host: www.cisco.com

Connection: Keep-Alive

Cookie: JSESSION-ID=123456789abcd

ACE sends a 301 redirect to the url:

https://www.cisco.com:9999/images/cisco.jpg

Either way, the redirect will point the client back to the https vip listening on port 9999.  The difference is whether or not you want to keep the client's initial url, or send them directly to 1 url no matter what request they were making.

One sidenote that is not directly related - The SSL rule above that has an "action list" that re-writes a 302 from the server.  If ACE is decrypting SSL, this is VERY important because the server is unaware of the fact that the client on a different port on the front end of ACE.  For that reason - if the server sends a 302 to ACE, the url in it will be http://www.something.com. The purpose of the action list is that ACE will re-write the http:// to https:// as the packet goes through it.  The means the client would see a 302 for https://www.something.com , and would thus open a new connection securely to the vip instead of insecurly.

Let me know if this is what you were looking for.

Regards,

Chris Higgins

Thanks Chris, that is what I was looking for.

May you clarify one thing for me, regarding class-default.

In my configs, I had three "policy-map type loadbalance " statements all having different classes (i.e. class-default and two other classes I created, say class_one and class_two). For some reasons things were not working for those with the other two classes (class_one and class_two).

When I changed the configs to class-default in all policy-map loadbalance statements, everything worked fine.

What puzzles me now is, do all policy-map statements need to use the same class-default (which does not make sense to me)? If not, under what conditions should it (or not) be implemented this way?

Kind regards,

Edgar

Thank you for clarifying. I would have to see the configuration that you had and a few statistics to be sure of what was occuring - But the direct answer to your question would be no. Class class-default is a place holder to match all traffic.

If you wanted to direct all traffic to one specific serverfarm whenever a client was requesting www.cisco.com/images/cisco/pic1.jpg, you would need to have a non class class-default under the policy map type loadbalance. Here is an example:

class-map type http loadbalance match-all cisco_match

2 match http url images./cisco./pic1.jpg

policy-map type http loadbalance first-match MyWebsite

class cisco_match

serverfarm cisco

class class-default

serverfarm notcisco

In the above circumstance, if the URL was www.cisco.com/images/cisco/pic1.jpg, the traffic would go to serverfarm cisco. If any other url was requested, the traffic would go to serverfarm notcisco. If you did not have the class-class default, and instead only had this:

class-map type http loadbalance match-all cisco_match

2 match http url images./cisco./pic1.jpg

policy-map type http loadbalance first-match MyWebsite

class cisco_match

serverfarm cisco

Whenever a URL was not www.cisco.com/images/cisco/pic1.jpg, the ACE would send a reset back to the client since there was no other class that matched the traffic.

This generally brings up an interesting question at this point. What if you had this:

class-map match-any X

2 match virtual-address 172.16.35.10 tcp eq https

policy-map type http loadbalance first-match MyWebsite_Cisco

class cisco_match

serverfarm cisco

policy-map type http loadbalance first-match MyWebsite_NotCisco

class class-default

serverfarm notcisco

policy-map multi-match VIPS

class MyVIP

loadbalance vip inservice

loadbalance policy MyWebsite_Cisco

class MyVIP

loadbalance policy MyWebsite_NotCisco

loadbalance vip inservice

interface vlan 172

ip address 172.16.35.88 255.255.255.0

access-group input everyone

service-policy input VIPS

no shutdown

When traffic comes into vlan 172, ACE will check if there are any VIPS that apply to the destination IP of a SYN packet. Traffic can only match one loadbalance vip. Since we have 2 vips with the class "MyVIP", if traffic were to be sent to 172.16.35.10 on port 443, ACE would match the first vip listed in the internal configuration. (note that this is generally the first class under the policy from the top down that matches the ip and port, but that is not always true across all versions of software on ACE.) So, if ACE matched the first class listing, all traffic would be sent to "MyWebsite_Cisco" where ACE is only going to loadbalance traffic if the url is www.cisco.com/images/cisco/pic1.jpg, So any traffic not to the URL would be reset.

The reason is simply that this is a mis-configuration. The correct way to send traffic to 1 IP/Port and look for different URLs/headers/etc. is to devide up the matching in a class under the policy map type loadbalance as with the first example:

class-map type http loadbalance match-all cisco_match

2 match http url images./cisco./pic1.jpg

policy-map type http loadbalance first-match MyWebsite

class cisco_match

serverfarm cisco

class class-default

serverfarm notcisco

I hope this was clear, please let me know if you have the configuration and I can take a look at it, or if you have any question on what I wrote above.

Regards,

Chris

Thanks for the response. The conf is like this,

rserver host server001

   ip address 10.10.10.10

   probe PING

   inservice

rserver host server002

   ip address 10.10.10.13

   probe PING

   inservice

serverfarm host server

   description server SLB

   probe HTTP-PPS

   rserver server001

      inservice

   rserver server002

      inservice

class-map match-all server-VIP

   10 match virtual-address 10.10.10.19 tcp eq www

policy-map type loadbalance first-match L7SLBTesting_Pol

   class class-default

      serverfarm server

!----- the redirection stuff

rserver redirect server001_students

   description server001 students redirection

  webhost-redirection http://server001.test.org/students/signon.html 301

   inservice

rserver redirect server002_students

   description server002 students redirection

   webhost-redirection http://server002.test.org/students/signon.html 301

   inservice

serverfarm redirect STUDENTSONLINE

   description studentsOnLine SLB redirection

   rserver server001_students

      inservice

   rserver server002_students

      inservice

class-map type http loadbalance match-any L7CLSS-STUDENTSONLINE

   2 match http url http://studentsonline.test.org/*

class-map match-all STUDENTSONLINE-VIP

   2 match virtual-address 10.10.10.8 tcp eq www

policy-map type loadbalance first-match L7SLB-STUDENTSONLINE

   class class-default

      serverfarm STUDENTSONLINE

rserver redirect server001_staff

   description server001 staff redirection

  webhost-redirection https://server001.test.org:483/staff/signon.html 301

   inservice

rserver redirect server002_staff

   description server002 staff redirection

   webhost-redirection https://server002.test.org:483/staff/signon.html 301

   inservice

serverfarm redirect STAFFONLINE

   description staffOnLine SLB redirection

   failaction reassign

   rserver server001_staff

      inservice

   rserver server002_staff

      inservice

class-map type http loadbalance match-any L7CLSS-STAFFONLINE

   2 match http url http://staffonline.test.org/*

class-map match-all STAFFONLINE-VIP

   2 match virtual-address 10.10.10.9 tcp eq www

policy-map type loadbalance first-match L7SLB-STAFFONLINE

   class class-default

   serverfarm STAFFONLINE

policy-map multi-match CLIENT-server-VIPS

   class server-VIP

      loadbalance vip inservice

      loadbalance policy L7SLBTesting_Pol

      loadbalance vip icmp-reply active

   class STAFFONLINE-VIP

      loadbalance vip inservice

      loadbalance policy L7SLB-STAFFONLINE

      loadbalance vip icmp-reply active

   class STUDENTSONLINE-VIP

      loadbalance vip inservice

      loadbalance policy L7SLB-STUDENTSONLINE

      loadbalance vip icmp-reply active

____________________________________________

On doing some testing, loadbalancing works well in all cases, but when one server becomes unavailable, the serverfarm keeps trying to use it (i.e. on the redirection). I thought the command "failaction reassign" under the serverfarm redirect statement would take care of that since probes are not configurable.


Must be a way of doing it better than what I am doing at the moment.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: