Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. And see here for current known issues.

wig
New Member

Content rules issue - request directed to the wrong content

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

8 REPLIES

Re: Content rules issue - request directed to the wrong content

Wig,

Can you look at the Web server logs for the 404? In my experience I have found that the most common reason a content rule isn't hit is because of inccorrect links or URIs in the application. Verification of the web server logs on the exact request can tell you if this is a CSS issue or application server.

If it is CSS related then you want to probably post your software version and review release notes for bugs.

Please rate any helpful posts

Thanks

Fred

wig
New Member

Re: Content rules issue - request directed to the wrong content

Hi Fred,

We already completed this investigation in the logs. The requests going to the wrong content rule are valid URL.

Thanks for your input, we'll have a look at the release notes related to our software version on the CSS.

Thanks

Wig

Bronze

Re: Content rules issue - request directed to the wrong content

Hi Wig,

Make sure the the service within the content rule is alive at all times. If the keepalive for that service fails for a few seconds and it is placed in dead status by the CSS, then the requests would go to the least specific content rule.

You can check if the service have had state transitions by looking at the logs. Thanks!

Regards,

Jose Quesada.

wig
New Member

Re: Content rules issue - request directed to the wrong content

Thanks for that suggestion,

We'll have a look at the logs and check if there's any server with a intermittent flicky NIC. Meanwhile we upgrade our Webns from 7.3 to 7.5.

Thanks again,

Wig

Cisco Employee

Re: Content rules issue - request directed to the wrong content

if a flow has been considered idle by the CSS it will stop looking into the content to detect if a remapping to a better rule is required.

So, you should increase the flow timeout to see if it helps.

Use the command 'flow-timeout-multiplier 20' on all your content rules.

Gilles.

wig
New Member

Re: Content rules issue - request directed to the wrong content

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 .

Cisco Employee

Re: Content rules issue - request directed to the wrong content

what you describe is well-known and the config I gave you is the solution.

I'll try to explain one more time the principle.

A browser usually uses persistent connections.

It's one TCP connection to send many http requests.

So, it may happen that the first request hits the first rule and a subsequent request hit a different rule.

The CSS is able to detect it and switch from one rule to the other.

However, if the connection is considered idle.

That is, if between 2 http requests the client waits more than 8 sec, the CSS will consider the flow idle and stop looking for http request. The connections stays up, but it will stay attached to the last server. Even if the new request matches a different rule.

Therefore the solution is to avoid the connection to become idle.

By increasing the flow-time-multiplier this is what we do.

Gilles.

wig
New Member

Re: Content rules issue - request directed to the wrong content

Hi,

we test your theory (on a CSS 11503, ver 7.5) but when a service is dead the content rule stay alive and active. the more specific content rule received the request but cannot answer the request because his service is dead. the request doesn't get send to the least specific content rule. the packet is drop.

Our understanding is that a CSS find the more specific content rule and doesn't look for another content rule if the first content rule connot serve the request.The packet is simply drop

176
Views
3
Helpful
8
Replies