Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations IamaSherpa on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

wireshark "this frame acks a segment we've never seen"

Status
Not open for further replies.

jimfixit

MIS
Aug 5, 2003
116
US
I'm trapping a problem with replication between our on-site and off-site san. The data goes from the onsite san, across a fiber-scsi to ethernet switch, over dark fiber to the offsite location, across another ethernet to fiber-scsi switch and onto the off-site san.

The fiber to ethernet switch continually registers retransmissions and slow tcp starts. However the ports on the cisco ethernet switches show no drops, no errors of any kind. utilization statistics of the links (including the ports that connect the dark fiber and the ports that connect the fiber-ethernet switch) all show low utilization, as in not even a 10th of the available bandwidth. CPU on the cisco switchs is under 10%.

So I trapped packets with wireshark on the port where the fiber-ethernet switch connects to the cisco switch. What I see are frequent TCP Sequence issues that will say "The frame acks a segment we have not seen". I see that for transactions going in both directions.

If find this odd. For point "A" to generate an Ack it had to get the packet in the first place. For point "B" to say, "I never saw the packet this is acking" is insane...who put the packet on the wire for A to ack if B did not ever see it? B had to generate it to begin with!!

Is it possible this error is a result of using a port mirroring situation instead of a real wiretap? Could wireshark just be missing something in the capture? It is interesting that these are not just at the start up capture these errors are seen through out the trace. And I don't see any legimate packets with the sequence number that the packets are supposed to be acking...they really aren't there.

But then, at some point they had to be..unless the device on the other end is just randomly making up acks....

thanks for insight.
 
I've never known Wireshark to 'miss' anything, nor have I had any problems using a port mirror...

Can you stick a hub in the stream? Sniffing from there would eliminate the mirror possibility.

Are jumbo frames involved? Could be a mis-match.




--
The stagehand's axiom: "Never lift what you can drag, never drag what you can roll, never roll what you can leave.
 
hmm...

well I thought about the hub thing because I knew that would eliminate the need for the mirror but, I'd have to take the san completely off line long enough to slip that into place. With this many servers running 365 24x7 that's never going to be permitted.

I will check with the SAN guys reguarding jumbo frames though, that's a good point.

Thanks.
 
No CRC errors? Are you using ISL trunking (if you have vlans)? ISL trunking will cause jumbo frames...
A wants to send a frame to B, so it sends a SYN packet. B sends a SYN-ACK, and then A sends an ACK to this. If neither side sees the SYN-ACK, you'd likely get the error you're seeing...has the window size been adjusted at all?

Burt
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top