Header-map not working in CSM-S

Answered Question
Jul 5th, 2007
User Badges:

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

Correct Answer by Gilles Dufour about 9 years 11 months ago

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.

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (1 ratings)
Loading.
Gilles Dufour Thu, 07/05/2007 - 03:53
User Badges:
  • Cisco Employee,

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 Thu, 07/05/2007 - 06:48
User Badges:

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

hussainmo Fri, 07/06/2007 - 01:22
User Badges:

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

Correct Answer
Gilles Dufour Fri, 07/06/2007 - 01:28
User Badges:
  • Cisco Employee,

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.

Actions

This Discussion