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

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

For an introduction to the new site, click here. If you'd prefer to explore, try our test area to get started. And see here for current known issues.

New Member

CSS 11501 Trouble shooting data throughput

I have two groups of servers that talk to each other through the Load Balancer. It appears that on certain transactions where there is a "get", "head" or "trace" in the actual http data, the transaction is not forwarded through the CSS 11501. This happens maybe once in 11,000 transactions. It appears the word get, head or trace has to be in a certain part of the data payload to cause this problem too occur. Has anybody heard of such an issue? If so, do you have a work around? If not, any suggestion on how I can further isolate the issue. FYI I have a TAC case open but it does not appear to be going any where any time soon.

Cisco Employee

Re: CSS 11501 Trouble shooting data throughput

is it happening in the middle of a persistent connection or with the first request ?

There are 2 possibilities I can think off.

First one would be a flow timeout and the next request is just dropped because the css reclaim the fcb.

The 2nd option is that by default the CSS does not support the "TRACE" http method.

It must be enabled.

See info at :

So, configure a flow-timeout-multiplier and enable parsing of rfc2518 methods.


New Member

Re: CSS 11501 Trouble shooting data throughput

It happens after the SYN and ACK. Once the data starts and if there is the word trace in the data (such as "123 Trace Lane, Buffalo, NY"), the transaction fails and the connection reset itself in about 2 minutes. I found a bug that might be right on point.


Cisco Employee

Re: CSS 11501 Trouble shooting data throughput

I do not think this ddts is a match based on your description.

First because, as I said, we do not support the "TRACE" method by default.

Next, the method must appear at the very begging of the packet, which is not the case in your data.

If you do not have the flow-timeout-multiplier as I mentioned before, try to configure it.