ACE header rewrite with loadbalancing
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
08-12-2010 06:03 AM
How do you configure two VIPs to redirect http traffic from a client destined to two different https pages on different ports (443 and 483)
For example;
http://staffonline.com - VIP#1
to
https://rserver1.com:483/staff/signon.html
https://rserver2.com:483/staff/signon.html
and
http://studentsonline.com - VIP#2
to
- Labels:
-
Application Networking
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
08-12-2010 01:09 PM
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
08-13-2010 12:05 AM
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
08-13-2010 10:21 AM
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
08-17-2010 06:54 AM
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
08-18-2010 10:45 PM
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
08-20-2010 03:05 AM
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.
