Buy or Renew
Buy or Renew
Cisco + Splunk: It’s a new day for your data. Learn more.
 
cancel
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for 
Search instead for 
Did you mean: 
cancel
Start a conversation
2125
Views
5
Helpful
6
Replies

ACE sorry server and sticky

Go to solution
sebastianvandijk
Level 1
Level 1

‎12-18-2007 08:44 AM

I have configured 3 different serverfarms with including realservers

2 of them are with websites, the other 1 is with webservices

I also have configured a sorry server farm and the including rserver.

On the sorry rserver i have configured 2 maintenance websites, listening to an unique hostheader.

So for serverfarm A & B i have configured a seperate maintenance website.

Now when i take rservers from serverfarm A or B down, the sorry server will get active for the needed farm.

However i can only reach 1 maintenance website. And even so, an url used to reach farm A gets on maintenance site from B

This is strange behaviour, doesnt a sorryserver just accept requests with the requested hostheader by the client ?

Also, when i put the rservers from A and B back into service i have to do a "clear stick database all" otherwise the sorryserver will remain active.

What is wrong here ?

probe http EHIC-http

description Test op WWW functionaliteit

interval 10

passdetect interval 30

request method get url http://acc.site-B.nl/web/

expect status 200 200

header Host header-value "acc.site-B.nl"

expect regex 1.8.0.2

probe http WWW-http

description Test op WWW functionaliteit

interval 10

passdetect interval 30

request method get url http://acc.site-A.nl/web/default.aspx

expect status 200 200

header Host header-value "acc.site-A.nl"

expect regex v1.9.2.327

serverfarm host EHIC-FARM

failaction purge

predictor leastconns slowstart 30

probe EHIC-http

rserver ehic_server01.site-B.nl

inservice

serverfarm host SORRY-FARM

failaction purge

predictor leastconns

rserver sorrypage.site-C.nl

inservice

serverfarm host WBS-FARM

failaction purge

predictor leastconns slowstart 30

probe ICMP-PROBE

rserver acc-wbs01v.site-D

inservice

rserver wbs_01.site-D

inservice

rserver wbs_02.site-D

inservice

serverfarm host WWW-FARM

failaction purge

predictor leastconns slowstart 30

probe WWW-http

rserver acc-www01v.site-A

inservice

rserver acc_server01.site-A

inservice

rserver acc_server02.site-A

inservice

sticky ip-netmask 255.255.255.255 address source EHIC-FARM-STICKY

serverfarm EHIC-FARM backup SORRY-FARM

sticky ip-netmask 255.255.255.255 address source WWW-FARM-STICKY

serverfarm WWW-FARM backup SORRY-FARM

class-map match-any EHIC-VIP

2 match virtual-address 172.30.9.4 tcp eq https

3 match virtual-address 172.30.9.4 tcp eq www

class-map match-any WBS-VIP

6 match virtual-address 172.30.5.4 tcp eq www

7 match virtual-address 172.30.5.4 tcp eq https

class-map match-any WWW-VIP

2 match virtual-address 172.30.6.4 tcp eq www

3 match virtual-address 172.30.6.4 tcp eq https

policy-map type loadbalance first-match EHIC-FARM-STICKY-BALANCE

class class-default

sticky-serverfarm EHIC-FARM-STICKY

policy-map type loadbalance first-match WBS-FARM-BALANCE

class class-default

serverfarm WBS-FARM

policy-map type loadbalance first-match WWW-FARM-STICKY-BALANCE

class class-default

sticky-serverfarm WWW-FARM-STICKY

policy-map multi-match LOADBALANCING-EHIC

class EHIC-VIP

loadbalance vip inservice

loadbalance policy EHIC-FARM-STICKY-BALANCE

loadbalance vip icmp-reply active

appl-parameter http advanced-options EHIC-PARAMETERS

policy-map multi-match LOADBALANCING-WBS

class WBS-VIP

loadbalance vip inservice

loadbalance policy WBS-FARM-BALANCE

loadbalance vip icmp-reply active

appl-parameter http advanced-options WBS-PARAMETERS

policy-map multi-match LOADBALANCING-WWW

class WWW-VIP

loadbalance vip inservice

loadbalance policy WWW-FARM-STICKY-BALANCE

loadbalance vip icmp-reply active

appl-parameter http advanced-options WWW-PARAMETERS

Regards,

Sebastian

Labels:
0 Helpful
1 Accepted Solution

Accepted Solutions

Go to solution
Gilles Dufour
Cisco Employee
Cisco Employee
In response to sebastianvandijk

‎01-09-2008 02:20 AM

Sebastian,

thanks for the new description.

I finally got to understand what you are trying to do.

So, the same sorry server is supposed to check the host header contained in the http request and based on the value decide which page to return.

What you see is that you always get the page for site A.

Did you try to sniff in front of the sorry server to see if the request coming in have the correct hostname ?

I don't think this is an issue with ACE here but more a server config.

ACE does not touch the hostname. So whatever you configured is what will be used.

For the 2nd part, and the need for clearing the sticky database, this does not sound right. I would prefer you to open a service request so that a bug can be opened if necessary by the TAC.

Thanks,

Gilles.

View solution in original post

0 Helpful
6 Replies 6

Go to solution
Gilles Dufour
Cisco Employee
Cisco Employee

‎12-27-2007 04:27 AM

Sebastian,

your description is not perfectly clear.

What do you call maintenance website ??

What is the ip address that you use ?

Regarding the sticky behavior, this is not normal. The behavior you descrive is the one you get when you use the option 'sticky' in the definition of the backup serverfarm.

http://www.cisco.com/en/US/docs/interfaces_modules/services_modules/ace/v3.00_A1/command/reference/sticky.html#wp1011140

If you are already useing A1(6.3) open a service request to get this investigated.

If not, do an upgrade and see if the problem persist.

Gilles.

Go to solution
sebastianvandijk
Level 1
Level 1
In response to Gilles Dufour

‎01-08-2008 02:49 AM

Hi Gilles,

The maintenance website is a website which contains an "under construction" notice for our customers.

which ip do you mean ?

I have version A1_6_2a, so i'll upgrade to 6.3 first.

0 Helpful

Go to solution
Gilles Dufour
Cisco Employee
Cisco Employee
In response to sebastianvandijk

‎01-08-2008 04:34 AM

the name or function of a machine is not useful for troubleshooting.

We prefer to get ip addresses of the device.

So instead of saying the maintenance website did this or that, give us the ip address.

Or use letters like machine A B C D , ....

Just tell us if the device is a client, an rserver or a vserver.

Then give us information like when going from A to B this or that happened.

It's important to know the path of the traffic from source to destination.

Then based on the config, we can tell if something went wrong or not.

Gilles.

0 Helpful

Go to solution
sebastianvandijk
Level 1
Level 1
In response to Gilles Dufour

‎01-08-2008 07:09 AM

Hi Gilles,

Here is our full config, i only changed some domain names.

I'll try to describe the problem again ;

We have published a website by vip 172.30.6.4

We have another website published by vip 172.30.9.4

These websites are hosted by realservers configured in 2 serverfarms and can be reached from the internet (secured by an ASA)

For both of these farms i have configured a sorryserver. This sorry server should serve a webpage containing a maintenance message whenever a farm should get down.

The sorry server is configured with 2 websites, each listening to the specific hostheader. This hostheader is the same as configured on the rservers for the specific farm 172.30.6.4 or 172.30.9.4.

So what i am trying to accomplish is that i only need 1 sorryserver to server 2 sorry webpages, ofcourse listening to a hostheader to get 2 different sorrypages to be returned.

Now when i take all realservers for both serverfarms down, except for the sorryserver, i can only reach 1 sorrypage.

For example, site A and B are down, when i try to reach site A i get to the sorrypage of site A. But when i try to reach site B i too get served the sorrypage of site A.

And also when i "inservice" all rservers again i have to do a "clear sticky database", otherwise the sorryserver will remain active.

Now i have upgraded to the last version of the ACE ios, but i still have to test if the same problem persists so i will give feedback on this later.

Regards,

Sebastian

Preview file
9 KB
0 Helpful

Go to solution
Gilles Dufour
Cisco Employee
Cisco Employee
In response to sebastianvandijk

‎01-09-2008 02:20 AM

Sebastian,

thanks for the new description.

I finally got to understand what you are trying to do.

So, the same sorry server is supposed to check the host header contained in the http request and based on the value decide which page to return.

What you see is that you always get the page for site A.

Did you try to sniff in front of the sorry server to see if the request coming in have the correct hostname ?

I don't think this is an issue with ACE here but more a server config.

ACE does not touch the hostname. So whatever you configured is what will be used.

For the 2nd part, and the need for clearing the sticky database, this does not sound right. I would prefer you to open a service request so that a bug can be opened if necessary by the TAC.

Thanks,

Gilles.

0 Helpful

Go to solution
sebastianvandijk
Level 1
Level 1
In response to Gilles Dufour

‎01-18-2008 01:17 AM

Hi Gilles,

Problem has been solved for now.

The sticky thing is mentioned in CSCsj59357.

This will be solved in version 2.

The IIS thing was a misconfiguration thing in our config.

Thanks for the help !

Sebastian

0 Helpful
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:

Customers Also Viewed These Support Documents