Content rules issue - request directed to the wrong content

Question

Hi,
We have the following setup;
Requests to www.oursite.com goes to the content rule LB_FD_87. Request to www.oursite.com/water/* goes to the more specific content rule FD/WATER_LB_87. Sometimes, for unexplicable reasons, requests for www.oursite.com/water/* are sent to the content rule LB_FD_87 instead of the more specific rule FD/WATER_LB_87 and the client get a 404 error. Anyone have a clue?
our setup:
dql FD_87
domain www.oursite.com index 1
owner FD
content LB_FD_87
add service W0_FD_3.71
add service W1_FD_3.81
protocol tcp
vip address XXX.XXX.29.87
port 80
balance leastconn
advanced-balance arrowpoint-cookie
active
owner FD_nonbalance
content FD/WATER_LB_87
vip address XXX.XXX.29.87
add service W3_GL_3.160
protocol tcp
port 80
url "/water*" dql FD_87
active
Thanks for your help
Wig

Answer 1

Hi Gilles,
I don't understand your sugestion .
I don't think increasing the flow timeout will help since according to CISCO documentation that will only permit to the flow to stay idle longer.
http://www.cisco.com/en/US/products/hw/contnetw/ps792/products_configuration_guide_chapter09186a00801ee806.html#wp1013729
CISCO DOC: "Configuring Flow Inactivity Timeouts on Content Rules and Source Groups
Use this feature with a CSS to configure flow inactivity timeout values for TCP and UDP flows on a per content rule and per source group basis. This timeout value is not the frequency with which a CSS reclaims flow resources, but is the time period that must elapse for an idle flow before the CSS marks the flow for cleanup. "
And I am not sure of what you mean by "the CSS it will stop looking into the content to detect if a remapping to a better rule is required" I think you mean that the CSS will look for a another content rule if a content rule does not repond to a request. But our understanding is that a CSS look for the more specific content rule to serve a request and if all the service of that content rule are dead the pacquet is drop not send to a another content rule.
We did test that with spefic and less specific content rule and if the more specific content rule as all is services dead the packet is drop not send to the least specific content rule.
thanks for your interest in our problem
We cannot reproduce this problem but still find the line sporadically in the web server log .