0

Our users currently access our interal website by typing in "ourwebsite". There is a DNS entry that maps ourwebsite to the ip address of a Cisco ACE 4700. The DNS name ourwebsite.ourcompany.org also maps to the ip address of the Cisco ACE 4700.

We want to have our users start using ourwebsite.ourcompany.org and decomission their ability to use "ourwebsite". For a period of time we want "ourwebsite" to still take them to our website.

We would like to know if it is possible to configure the Cisco ACE 4700 such that if a user types in http://ourwebsite that it immediately does a redirect to http://ourwebsite.ourcompany.org.

Is this possible? e.g. through a URL rewrite rule?

BestPractices
  • 183
  • 1
  • 2
  • 10

1 Answers1

3

I know this is an old question (related to when I'm answering) but I can say that this is something that the Cisco ACE can do using a few simple configuration directives.

Say that you have your site set up using a simple configuration similar to this:

rserver host HOST1
 ip address 1.2.3.4
 inservice
rserver host HOST2
 ip address 5.6.7.8
 inservice

serverfarm host OURWEBSITE
 probe <your-probe>
 rserver HOST1 80
  inservice
 rserver HOST2 80
  inservice

class-map match-all VIP-OURWEBSITE
 match virtual-address 1.1.1.1 tcp eq www

policy-map type loadbalance first-match LB-OURWEBSITE
 class class-default
  serverfarm OURWEBSITE

policy-map multi-match VIP-SERVICE-POLICY
 class VIP-OURWEBSITE
  loadbalance vip inservice
  loadbalance policy LB-OURWEBSITE
  loadbalance vip icmp-reply active

This is one of the more basic type of load balancing setup that you can configure on an ACE. All it does is simply reverse-proxy requests back to the real servers. The naming conventions are simply for example puroposes; you can choose to name them whatever you'd like.

What you're wanting to do is to match the host header that comes from the client -- if it is "ourwebsite" then the request should be sent to a redirect serverfarm that forces a HTTP 30x "ourwebsite.ourcompany.org" redirect to the client.

rserver redirect REDIRECT-OURWEBSITE
 webhost-redirection http://ourwebsite.ourcompany.org%p 301
 inservice

serverfarm redirect REDIRECT-OURWEBSITE
 rserver REDIRECT-OURWEBSITE
 inservice

The above sets up the redirection object. In the "webhost-redirection" directive, you'll notice a %p and a 301. The %p is a variable that takes the path from the client request and adds it to the redirect - that way if someone has, say, http://ourwebsite/somepage.html bookmarked, the redirect will automatically send them to http://ourwebsite.ourcompany.org/somepage.html rather than sending them to a statically-configured page. It's purely optional, so if you'd rather them be sent to a configured page rather than be automatically redirected, just leave of that %p variable and replace it with the URL you want to be redirected to. The 301 makes the redirect send a HTTP code 301 - which tells the requesting client that the page has "moved permanently" to this new address.

Now we'll move to setting up the object that matches host header requests for http://ourwebsite.

class-map match-all MATCH-OURWEBSITE
 match http header Host header-value "ourwebsite"

policy-map type loadbalance first-match LB-OURWEBSITE
 class MATCH-OURWEBSITE
  serverfarm REDIRECT-OURWEBSITE

The new class map will set up a matching class that looks for "ourwebsite" in the HTTP Host header. The matching rules use simple regular expressions so the above will not match "ourwebsite.ourcompany.org".

The second directive above, from the previously defined policy map LB-OURWEBSITE, inserts the new matching class into the load balancing policy. If the only class you have in a policy map is class-default, this new class will be inserted above that. If you already have one or more classes above class-default, you can insert this rule above any of them using class MATCH-OURWEBSITE insert-before and it will insert it above the class you specify.

Once that's all complete, it is usually a good practice to cycle the VIP by doing a no loadbalance vip inservice followed by a loadbalance vip inservice in the service policy:

policy-map multi-match VIP-SERVICE-POLICY
 class VIP-OURWEBSITE
  no loadbalance vip inservice
  loadbalance vip inservice

It isn't necessarily needed for the addition of a match into the load balancing policy map, but some other directives require a cycle of the VIP service policy so it is a good habit to get into.

The full configuration after setting this all up would look like this:

rserver host HOST1
 ip address 1.2.3.4
 inservice
rserver host HOST2
 ip address 5.6.7.8
 inservice
rserver redirect REDIRECT-OURWEBSITE
 webhost-redirection http://ourwebsite.ourcompany.org%p 301
 inservice

serverfarm host OURWEBSITE
 probe <your-probe>
 rserver HOST1 80
  inservice
 rserver HOST2 80
  inservice
serverfarm redirect REDIRECT-OURWEBSITE
 rserver REDIRECT-OURWEBSITE
 inservice

class-map match-all MATCH-OURWEBSITE
 match http header Host header-value "ourwebsite"
class-map match-all VIP-OURWEBSITE
 match virtual-address 1.1.1.1 tcp eq www

policy-map type loadbalance first-match LB-OURWEBSITE
 class MATCH-OURWEBSITE
  serverfarm REDIRECT-OURWEBSITE
 class class-default
  serverfarm OURWEBSITE

policy-map multi-match VIP-SERVICE-POLICY
 class VIP-OURWEBSITE
  loadbalance vip inservice
  loadbalance policy LB-OURWEBSITE
  loadbalance vip icmp-reply active

From there, depending on your decommission process, you could either disable the DNS entry after a time, or even modify the webhost-redirection directive to point to a page telling users to stop using the hostname to connect to the website. It's all up to your decommissioning policy.

Hope this helps!

haymaker
  • 1,242
  • 9
  • 9