Solved: Header-map not working in CSM-S

hussainmo · ‎07-05-2007

Hi,

We are trying to configure an application using both a url and header map in the policy:

natpool DOC-PROD-NAT 10.1.1.1 10.1.1.1 netmask 255.255.255.128

probe DOC-GLIB-PROD http

request method get url /globelib/webcomponent/testbed/CLASSPATHTool.jsp

expect status 401

interval 15

retries 2

failed 30

open 2

map DOC-GLIB-PROD url

match protocol http url /globelib*

map DOCUMENTUM-PROD header

match protocol http header Host header-value ecm.ctr.globeint.ddc

serverfarm DOC-GLIB-PROD

nat server

nat client DOC-PROD-NAT

real name DDINTA34 7000

inservice

real name DDINTA37 7000

inservice

probe DOC-GLIB-PROD

sticky 66 cookie DOC-GLIB-PROD insert

policy DOC-GLIB-PROD

url-map DOC-GLIB-PROD

header-map DOCUMENTUM-PROD

sticky-group 66

serverfarm DOC-GLIB-PROD

vserver DOC-CSFSAP-PROD

virtual 10.1.1.1 tcp www

no persistent rebalance

slb-policy DOC-GLIB-PROD

inservice

The problem we have is that it does not work with the header map. As soon as I remove the header map from the policy it starts to work. It does not also work without the header map alone without the url map under the policy. As per Cisco documentation I don't see any issue with this config.

We have disabled persistent rebalancing due to the fact that CSM does not support http pipelining and this application uses it.

Any help will be appreciated.

Thanks,

Murtaza

Gilles Dufour · ‎07-06-2007

ok, I was able to detect the issue and reproduce it in my lab.

Your client sends the host value ecm.ctr.globeint.ddc:80 and it does not match your header-map.

If you change your header-map to look like this

map DOCUMENTUM-PROD header

match protocol http header Host header-value ecm.ctr.globeint.ddc*

then it works fine.

Gilles.

View solution in original post

Gilles Dufour · ‎07-05-2007

could you please describe 'does not work'.

Is it the first request that does not hit the appropriate policy ? or subsequent request ?

What happens with your request when it fails ? just hang or reset ?

Could you capture a sniffer trace showing the problem.

What version do you run ?

Gilles.

hussainmo · ‎07-05-2007

This application is a document respository. With this config we are able to connect to the application but when we try to open a document this action fails and we get a ucf error. However when the header map is removed we can open the same document successfully.

Based on this I would say that its the subsequent request that fails.

Its resets almost immediately.

I have 2 captures. One with (called header map which does not work) and the other without the header map (called url map which does work). Currently I am trying to attach these with IP addresses suppressed but so far I am out of luck. As soon as I figure it out I will attach them.

The software version is 2.1.4

Murtaza

Gilles Dufour · ‎07-06-2007

Murtaza

I would need a capture that can be viewed with ethereal. If you do not want everybody to look at it, you can send it to me directly gdufour@cisco.com

Gilles

Gilles Dufour · ‎07-06-2007

got your trace and have the config

hussainmo · ‎07-06-2007

Hello,

I hope I understand your question.

When I took the capture url map (the working situation) I had the following config in place:

policy DOC-GLIB-PROD

url-map DOC-GLIB-PROD

sticky-group 66

serverfarm DOC-GLIB-PROD

When I took the header map capture (the non working solution) I had the following config on the CSM:

policy DOC-GLIB-PROD

header-map DOCUMENTUM-PROD

sticky-group 66

serverfarm DOC-GLIB-PROD

Let me know if I have misunderstood your question.

Thanks,

Murtaza

Gilles Dufour · ‎07-06-2007

ok, I was able to detect the issue and reproduce it in my lab.

Your client sends the host value ecm.ctr.globeint.ddc:80 and it does not match your header-map.

If you change your header-map to look like this

map DOCUMENTUM-PROD header

match protocol http header Host header-value ecm.ctr.globeint.ddc*

then it works fine.

Gilles.