13 0.000000 10.151.19.21 10.151.17.21 TCP 1518 [TCP Out-Of-Order] 59988 > vnetd [ACK] Seq=1 Ack=1 Win=65535 Len=1460 asked 27 Mar '12, 01:58  wtycc |
我怎么样才能解决这个问题？ how to solve this problem?
2 Answers:
Your screenshot is showing a strange trace. First of all, you only seem to have captured one direction of the communication, from IP 10.151.19.21 to 10.151.17.21. So we don't know what the IP 10.151.17.21 sends back. But that is not the biggest problem. In frame 5, the (relative) Sequence number starts at 1 and goes up by 1460 bytes, as expected. There's a packet loss before frame 8, where Sequence 4381 should have been - but we see 5841 instead. So one segment is missing, and Wireshark is correct about the "TCP Previous Segment Lost". So far it's all pretty normal. The really strange thing happens in frame 11: suddenly the Sequence jumps (well, not a tiny jump, but more of a long range interstellar teleport) to 4294964377 (when it should have been a mere relative number of 10221). Something went really wrong here, and I doubt it's Wiresharks fault - more likely the packet got corrupted somehow, or the capture setup was faulty - especially since the following frame 12 has a correct sequence number of 11681 (10221 + 1460). Anyway, after frame 11 Wireshark seems a bit confused because huge amounts of data seem to be missing, which is probably why you get all the "Out-Of-Order" messages. Since we don't know what the other side replied we cannot tell what happened after , but it looks like the communication is started again at Sequence 1 in frame 13. Another very funny thing happens in frame 15 - suddenly we see an ACK number that is the same as the bogus sequence number in frame 11. Final verdict: your capture process didn't work well, and it looks like your captured data was kind of garbled. Forget about the Wireshark expert messages like "Out-Of-Order" and try to capture with a better capture device - it's not worth putting thought into analyzing this mess. I bet you didn't capture this on a PC but probably locally on a Netscreen firewall. Problem is that it didn't even bother to either capture both directions, much less write proper timestamps (which is always 0 in your trace) or good sequence numbers. answered 27 Mar '12, 15:02  Jasper ♦♦ edited 27 Mar '12, 15:05 |
This appears to be server backup traffic, and data flow in only one direction. TCP port 13724 is used by Veritas/Symantec. In our network, we normally filter out port 13724 traffic, when we take traces. Unless we are dealing with backup issue, and we truncate packets to make it easier for wireshark to capture. answered 08 Apr '12, 09:29  CKC |
Thank you for your answer.The first week of my two servers traffic is 2T, the second week of traffic up to 8T, the third week of traffic up to 13T, always feel some unusual stuff in there, but still have not found what reason, I will work to try to use theWireshark to solve some things, but not progress.Anyway, Thank you for your selfless assistance.
13T? You mean 13 Terabyte of data between the servers in a week? What are you trying to solve? The screenshot you provided indicated that you're looking for some kind of connection trouble or slow performance. If you're really looking for what causes that much traffic you're better of using the statistics menu, for example the conversion statistics. It will tell you what IP has how many connections and the number of packets/bytes/bps. By looking at the port numbers you should be able to match it to applications on the server.
I come from China, my English is too poor,Can you help me to analysis under my packet, I put it in my blog below http://www.wtycc.com/airsea/1921.zip Thank you very much and look forward to your reply. You are a good man .
Sorry, I couldn't get a look sooner. Now having the trace file I see why your sequence numbers look crazy on your screenshot. The huge jump in frame 11 isn't that huge, it's just going backwards beyond the relative zero sequence (which can happen when Wireshark didn't see the three way handshake).
Without having spent too much time on the trace I can tell you this: the line you captured on is so busy that you had tons of drops (packets that were there but didn't get captured because the capture device was too slow). You'll need to find a better way to capture your data I'm afraid, because with a capture file like this you can't really tell what happened (or if anything bad happened at all). You can still do some statistics on a file like this, but it won't be 100% accurate.