FTP Problem through a switch

Experts,
 I need an expert to read a wireshark and let me know what you think may be causing my FTP data not to transfer after 50%


Thanks,

TamscoDan
FTP-ERROR.csv
LVL 3
TAMSCODANAsked:
Who is Participating?
 
Bill BachPresidentCommented:
That makes it easier to see the exact combination of ACKs:

ScreenShot
Here, we see the TCP window is still around 2900 bytes (two packets), which seems very small (must be an older OS on the target side).  Again, I've highlighted the ACKs for the data packets so you can see what is being ACKed.  Notice, though, the Delta Time column -- there is already an incredible time delay in these packets, with some replies coming many seconds after the requests, causing retransmissions.  

If you look deeply, however, it looks like things SHOULD be still under-way: the ACK is for 541961 (meaning that the target wants this packet next), and we see the exponential fallback as expected (right at the end in the retransmissions) as the source tries to re-send packet 541961 over and over again, but the target just keeps ACKing the same 541961 over and over again, very slowly.  This tells us that it is not receiving the data for some reason.

My guess is that the TCP stack on the target is a bit outdated.  You don't describe the network setup in detail, so coming to a conclusion is all but impossible.  For example, I *never* would have suggested to change out a media converter because you never mentioned that there was one in the loop!
0
 
Bill BachPresidentCommented:
Can you post the original PCAP file?  Analyzing a network via Excel is kind of like driving a cow to work.  It might be possible, but it's REALL slow going...
0
 
Bill BachPresidentCommented:
The first part of the failure shows that the ACK's simply start to stall out.  Either the receiver is too slow to process the data, or something is blocking the ACK packets:

Screen1
I indicated for each ACK which packet it is ACKing with the arrow.  The retransmissions at the end show that it is having lots of problems, and it is already stalling out.  A little while later, the same thing happens (but it is not as clear without being able to drill down into the TCP layer) and the transfer simply stops.

My guess?  Something is hampering the flow of data (the 64-byte ACK packets) from the target back to the source.  Could be as simple as a bad cable, traffic shaping on a link, or even a misconfiguration of duplex settings.
0
Ultimate Tool Kit for Technology Solution Provider

Broken down into practical pointers and step-by-step instructions, the IT Service Excellence Tool Kit delivers expert advice for technology solution providers. Get your free copy now.

 
Craig BeckCommented:
I'd also check that there's not an MTU issue.

From a command prompt (assuming you're using Windows) try this...

ping <ftpserverip> -f -l 1460

Open in new window


If you get this...

Packet needs to be fragmented but DF set.

...there is a problem with MTU.
0
 
TAMSCODANAuthor Commented:
I have atatched the PCAP you will need to add the extension since it would not let me load it. It is zipped.
FTP-ERROR.zip
0
 
TAMSCODANAuthor Commented:
One interesting test that we did do is that we put in a media converter and connected it into one of the copper ports of the switch and the transfer worked just fine. Than I looked at the specifications of the Media converter and found that the Media converter is rated at a distance of 2km where as the SFP that it was originally connected too was rated to 4Km. Do you think that the laser may be overpowering the rx port on the other end? wavelength is the same.
0
 
TAMSCODANAuthor Commented:
Topology is:

(END DEVICE A) ----via copper-----(Switch with Copper and Fiber)--------Fiber----------(FTP SERVER)
0
 
TAMSCODANAuthor Commented:
Initially there was no media converter, we used it to test therfore we connected the FTP server that was on the fiber and converted the FIBER to a copper connection so it worked fine that way. So this demostrates there was an issue with the SFP, however I would like to know what was the issue or how to figure this out via the wireshark capture. Great explanantion though!!!!
0
 
TAMSCODANAuthor Commented:
How can i get the Delta colum on wireshark?
0
 
Bill BachPresidentCommented:
Easy way: Select Edit / Time Display Format / Seconds Since Previous Displayed Packet (This changes the TIME field to the delta time)
Hard Way: Edit the entire column list, add a new column, rename it to Delta Time, and specify the item for Delta Time. (This allows you to have BOTH times shown, like I do.)

You can also show JUST the important traffic by right-clicking on an FTP packet, selecting Filter Conversation / TCP.
0
 
TAMSCODANAuthor Commented:
What prompted you to say incredible time delays? Sorry for all the questions. What should I expect for time delay?
0
 
Bill BachPresidentCommented:
While the process is running normally (towards the beginning of the process), you'll note the time delay is within a few ms each packet.  By the time it starts failing and the retransmissions start, it is taking over 1/4 second for each ACK (this lack of an ACK is what triggers the retransmission), and subsequent retransmissions are taking SEVERAL seconds.  This is an eternity as far as computers are concerned.
0
 
TAMSCODANAuthor Commented:
Thank you for all this good info!
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.