General discussion

  • Creator
    Topic
  • #2191937

    TCP anyone?

    Locked

    by kingarthur ·

    Hey All!

    Anyone with good knowledge of TCP?

    I understand that the TCP RST flag is set when the connection becomes
    unsynchronised. Is there any other reason for reseting a connection?

    If SERVER sends a packet with RST=1 does CLIENT respond at all? Should we
    see an ACK from CLIENT for the packet containing RST=1?

    Or does CLIENT just start up the three way handshake again?

    ALSO – And this is the real big question…… If, over the course of about
    4 hours, I see about 18 – 20 RST packets between a client and differnet servers, is
    this something to worry about?

    We are having “delayed write” errors between the clients and a number of
    servers and suspect that something (ISA?) is dropping frames.

    Any help or TCP gurus out there would be magic!

    Cheers

All Comments

  • Author
    Replies
    • #3106584

      Maybe normal

      by gary.kaiser ·

      In reply to TCP anyone?

      Often, in HTTP environments, a RST (or a few resets) is used instead of the “normal” FIN close sequence. Can you correlate the resets with the write errors?

      • #3106310

        Thanks Gary

        by kingarthur ·

        In reply to Maybe normal

        Gary, Many thanks for the reply. Sadly the Windows event log doesn’t time things quite so accurately as my packet sniffer! Yup – the write errors do occur in the same second, but there is an awful lot of other stuff goin on at the same time.
        It’s interesting what you say about “in HTTP environments”. The number of RST packets is fairly evenly distributed through all types of protocols – however the majority is Kerberos. I think there is only one or two HTTP RST packets.
        In my investigations this week, the evidence is pointing towards an issue with the firewall that sits between the client PCs and the servers. I have a feeling that is not coping with the quantity of traffic and complex routing that we make it carry out!
        Gary – Many thanks again.

    • #3162218

      TCP Help?

      by mbsystemsinc ·

      In reply to TCP anyone?

      Did you find anyone who could help you more with TCP? I’m also looking for help with interpreting TCP and ICMP errors.

      • #3154562

        Let me know

        by gary.kaiser ·

        In reply to TCP Help?

        Let me know what your questions are. I deal with TCP primarily as it relates to or affects application performance, so may not have all the answers, but also have some additional resources (friends).

        • #3152162

          Thank you Gary

          by mbsystemsinc ·

          In reply to Let me know

          I’m trying to find a resource that will help explain acceptable and unacceptable levels of TCP “errors”. Some of my monitoring software is showing a large number of TCP Slow ACK, TCP Reset Connection, etc… but none of them are actually listed as errors.

          Also while looking at netdiag logs, I’ve only found one document that explains how to interpret network statistics, but I’ve not found anything that explains TCP, ICMP, and datagram errors.

          Not sure how to ask spefically, but that’s kind of what I’m looking for.

        • #3153216

          Thank you Gary

          by kingarthur ·

          In reply to Thank you Gary

          Hi Marv,
          Just got back from a bit of a break so sorry for not getting back in here sooner.
          This kind of thing does seem to be a really grey area that is buried in the brown stuff! Finding anything out is a real mission. I think I am surprised at how much many people don’t actually know!!! 😉
          Luckily we had a consultant come in to look at some of the issues we were having. He reckoned that 20-30 RSTs over 4 hours is not a problem. Regarding my question about whether an RST is ACKed, he said it depends on whether an ACK is requested. Apparently in some applications the programmer may not write that bit in, so we get no ACK.
          I don’t know what anyone else thinks but I am begining to think that “if it’s not broken, don’t try to fix it”! So if your boxes that are generating TCP errors are not stressing themselves (CPU etc) and the network traffic is not overloaded (remember that a simple RST is going to be a tiny datagram), don’t worry about it!
          No, I don’t like it either!!!!!

Viewing 1 reply thread