CSS Connection Reset

Unanswered Question
Jan 9th, 2008

Hi all,

Is there any timeout, in content's, service, whereelse, wich by default is 20 seconds?

I have tried to change the "flow-timeout-multiplier" command to Zero.

I've been made load-charge tests using some scripts, and im always getting "connection reset" after 20 seconds.

I've have done the same test without the CSS, directly to one aplication server, and this is not appearing.

I'm counting with ur knowledge to give me some ideas on this.

Best Regards,

Bruno Petrónio

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 4 (1 ratings)
Loading.
Gilles Dufour Thu, 01/10/2008 - 06:11

Bruno,

show dos.

Any dos attack ?

The CSS will reset a connection if it considers it is an attack.

Except that, there is no other 20sec timeout.

Send your config if you do not find a solution and tell us where your client is connected.

(which vlan, ip ?)

Gilles.

b.petronio Thu, 01/10/2008 - 14:31

I was out of office today, but tomorrow i'll send u back more info.

Best Regards,

Bruno Petrónio

b.petronio Mon, 01/14/2008 - 09:03

Hi all,

Thanks for ur reply, which give me some ideias where to look.

The 20 seconds issue disappear, and now i have the following scenario:

NET_Client_Side --- CSS --- NET_Server_Side

10.1.2.128 / 25 --- CSS --- 10.1.1.0 / 24

The following description is only seen in a Testing Load Charge environment, wich is made by 5 PC's , in the Client Side Network, and 2 Apache Servers in the Server Side Network.

I had compression and was using ArrowPoint Cookie's, to stuck the sessions in the browsers.

One of the testing PC's is sending information to another 4 PC's, making them to start sessions to an url, simulating the browsing page, from the user authentication to the DataBase writing, and then exiting the session.

They use some random algorithm to make more real the browsing, making some sleep functions simulating the normal delay user typing/browsing.

This was working fine, when they was trying 1 user at a time. No errors was ocurred.

But then, they try to perform about 225 sessions by PC, which means 900 users at the same time.

The script works fine for some time, and then we see, that the number os sessions is decreasing in time.

I will attach the configuration i have in the CSS, and some logs in the apache server, and on the script.

I could not correlate them in time, since they move forward the tests with out the Load Balancer, wich works fine. Unfortunatly for me.. :(

So, i suppose something is happening here, but no DOS Vip/Service ip's was seen in the "show dos" command neither "show log sys.log"

Just another question, i was searching for Product limitation by hardware specifications, and could not find it, beside i was that feeling i had see some time ago a table with that type of information in cisco site.

Best Regards,

Bruno Petrónio

b.petronio Thu, 01/17/2008 - 15:04

I've been working on this, and i just want to ask u something.

Is it possible to see if there is something wrong in the compression stats?

I'm not sure where to look beside "show service" command, but i've read in the bug toolkit, that my Software version 8.10.1.6, is affected by a compression bug, wich may cause my symptoms, i hope.

Best Regards,

Petrónio

Gilles Dufour Fri, 01/18/2008 - 02:33

I would suggest to simply try without compression and see if it works.

Gilles.

b.petronio Fri, 01/18/2008 - 08:41

I Gilles,

We made the action you suggest the night before, and it only regist 1 error, wich is not dramatic.

We had upgrade the "CSS11501S-C-K9", from the 08.10.1.06 to 08.20.2.01 Software Version, cause we read about some Compression Bug's in the open caveats in the Release Notes.

"Bug CSCek45031"

But it seems that it had no improvement cause when we restore the compression content, the script logs register several "connection reset" again.

Any ideas ?

I'm out of them ! :(

Suggestion/Invitation:

Let's make a deal.

I offer you 1 week in Tróia, "http://www.troiaresort.net", and you came here to resolve my issue .

;)

Best Regards,

Bruno Petrónio

b.petronio Tue, 01/22/2008 - 04:05

Hello all again,

After i clear all stats and perform a test, i got these messages in the " show ssl statistics | grep ompression" command:

Compression Acceleration Statistics

Component: Compression Module: 2

1,974 HTTP compression service SYN packets

57 HTTP compression service not SYN packet

0 HTTP compression service sessions not allowed

905 FIN Client-Tcp after Compression WriteAlert/shutdown

1 RST Client-Tcp after Compression WriteAlert/shutdown

0 FIN Server-Tcp after Compression WriteAlert/shutdown

0 RST Server-Tcp after Compression WriteAlert/shutdown

0 RST Client-Tcp after Compression internal-error

0 RST Server-Tcp after Compression internal-error

0 Compression only sessions

First of all, what it is "WriteAlert/shutdown" ???

Any ideas of how to passtrough this type of errors?

Best Regards,

Bruno Petrónio

b.petronio Thu, 01/24/2008 - 06:06

Well, im refreshing this thread.

My support engineering team opened a case about this, but they are asking me for captures Inside and Outside the CSS when the error occurs.

What is happening is that im not seeing the normal 3-way tcp handshake capturing with the wireshark sniffer.

I got tones of MB of capture and when i do a follow TCP Stream on the resets i think the VIP address sends to the client, everytime begins with a POST !

This is not making sence to me. Anyone help me here.

Thanks in advance.

Bruno Petrónio

Gilles Dufour Thu, 01/24/2008 - 07:30

Bruno,

could you filter one connection and send it to us.

Also (re)send your config.

If all this info is attached to your case, just give me the case #.

Gilles.

b.petronio Thu, 01/24/2008 - 14:27

Well, i appreciate your time for this.

The case # is SR 607756393.

Note that the config in the case is a litle more expensive, since i have more owner's, rules and services configured, but this is the only using compression.

Nevertheless, tomorrow i will put some captures here to everyone look it.

Best Regards,

Petrónio

rich-nelson Thu, 02/12/2009 - 11:56

What was the resolution to our issue? I believe we're experiencing an event similar to your situation.

b.petronio Thu, 03/05/2009 - 07:04

Hi Rich,

After some time spended, someone decided to left the compression on the Server Side.

We will "upgrade" to ACE's to resolve this issue. (That's the final point)

Best Regards,

Petrónio

Actions

This Discussion