TCP bad checksum

Unanswered Question
Aug 6th, 2007


Could someone inform me how a CSS 11500 handles a packet with TCP invalid checksum. I have two loadbalanced svrs behind a CSS and im seeing the and ACK with a bad checksum hitting the server VLAN interface of the CSS which appears to send RST 200 micro seconds later to the server but not to the client, Is this normal behaviour ?.

Thanks in advance

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
stephen.baugh Mon, 08/06/2007 - 02:27


Ignore the previous, it looks like tcp checksum offloading is enabled and causing errors in Wireshark. But I still get RST from the CSS to a server withount one being transmitted to the client, any ideas ?


Gilles Dufour Mon, 08/06/2007 - 04:34

idle timeout issue ?

Try to increase the 'flow-timeout-multiplier' under the content rule and group.


stephen.baugh Mon, 08/06/2007 - 04:37


I don't think it is an idle timeout, it is using the default (16secs) and the reset happened after 10 seconds of the previous packet.


Gilles Dufour Mon, 08/06/2007 - 05:17


don't look at the interval with just the last packet.

The CSS will mark a flow idle if the interval between 2 consecutives packet is bigger than the idle timeout.

At that time, no reset will be sent.

But during the garbage collection process, the CS may reclaim resources hold by connections that were marked idle.

Even if the connection was not idle anymore, the CSS will destroy it if it was marked idle anytime in the past.

Moreover, for http connection, the idle timeout is 8 sec and not 16.

Finally, you can also check with 'show dos' to see if the css consider the connection as illegal - which would trigger a reset as well.


stephen.baugh Mon, 08/06/2007 - 05:59


Should both connections be torn down rather than just the connection to the server ?



This Discussion