Cisco Support Community
Showing results for 
Search instead for 
Did you mean: 

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. If you'd prefer to explore, try our test area to get started. And see here for current known issues.

New Member

Asymetrical file transfer times across network

Hello all,

I am troubleshooting an issue that is really stumping me. We have a WAN that is basically hub and spoke. The hub routers are 7206VXRs and the regional spokes are 3600 series.

We have all DS3 point to point circuits between the hub and the spokes. we are seeing asymetrical file transfer times when getting a file between two sites. One direction may be 50 seconds but getting the file from the opposite site will may be 2.5 minutes.

We use EIGRP as our routing protocol and I have gone through the router's config from one end to the other and they look fine.

Has anyone seen anything like this or have a clue where I might look next?


  • Other Network Infrastructure Subjects

Re: Asymetrical file transfer times across network

I would start by tracing the route from one end, then tracing it from the other end, to see if the routing is assymetrical (I assume it is), and then seeing if you can figure out why the routing is assymetrical. It could also be some issue with load sharing--perhaps per packet load sharing is turned on for some pair of links in one direction, causing a massive number of out of order packets, and thus a much slower file transfer.


New Member

Re: Asymetrical file transfer times across network

Assymetrical routing was the first thing I looked for, and if life was easy I would have found it. There does not appear to be any assymetrical routing going on, there also does not appear to be any load balancing. These are the reasons I am so stumped on this one.



Re: Asymetrical file transfer times across network

Is there any information about end-to-end traffic patterns? When you check the interfaces on the end-to-end data transfer path maybe you can identify something noteworthy (Rx/Tx load figures, in/out interface errors or drops). Are both end-point systems that take part in the data transfer the same kind? Due to specifications of these systems TCP behaviour may be different in both directions (assuming your data transfer process use TCP).

New Member

Re: Asymetrical file transfer times across network

The time difference between directions, seems to be too great to be just an asymetrical routing problem.. I would first ask if the end devices you are comparing times on, at both sides are similar,ie memory, processor speed. Also, is the LAN enviroment similar, ie number of hubs, switches, routers, pc's.... By the way, what size files are we talking about?? 1k, 1m, 1gig???? What type files being transfered??? Does the router on one end have multiple humongos ACLs that take alot of processing time??

Re: Asymetrical file transfer times across network


don't forget to check LAN switches port for "port storm-control unicast" commands. While such a port is dropping frames nothing goes to syslog or error counters.




Re: Asymetrical file transfer times across network

If the routing is symmetrical, then the most probable cause is TCP window size differences in each direction (assuming you are using FTP to transfer your files). The only window size which counts is that used from the source of the file to the destination of the file. Defaults for various flavors of Windows tend to vary, but are usually too small to support high data rates over links with non-negligable delays (anything other than a local LAN).

The specific parameter is the TCP receive window size (RWIN in Microsoft documentation). This is a very common problem with Windows boxes on broadband Internet connections such as DSL, and there are many web pages out there describing the registry adjustments required for various flavors of Windows. Or see Microsoft Knowledge base items #224829 and 263088.

Good luck and have fun!

Vincent C Jones

Good luck and good hunting.

This widget could not be displayed.