• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 302
  • Last Modified:

What would prevent the completion of large files being copied of over a WAN.

What would prevent the completion of large files being copied of over a WAN.
Our comapny is having issuse with large file transfers.

example 500mb img,iso, or pst file.

The file will copy for awhile and them it seems to time itself out.

The most common error message is:
Error Copying File or Folder
Cannot copy "A NAME OF FILE": The specified network name no longer available.

Not sure where to look to resolve this issue.
Most think it is a network problem others think it is server related.

Any Suggestions
0
mgbooker
Asked:
mgbooker
  • 4
  • 3
  • 3
2 Solutions
 
pseudocyberCommented:
What is the OS?  Are you sending over your own WAN?  Can you check your network connections through your WAN?  Make sure you don't have any duplex mismatches caused by different settings from the NIC to the network along the way - for instance, one side Autonegotiate and the other side 100 Full Duplex.
0
 
mgbookerAuthor Commented:
windows xp and windows 2000, and windows nt

This problem only exist in on site location. All other locations can copy files that are large fine. But when we try to copy any large files not on our local subnet it will bomb out. I have capture packets from my computer and the server, but not able to make heads or tails of it. Using Ethereal at this time.
0
 
lrmooreCommented:
MTU size has a big impact on large file transfers.
DSL w/PPPoE adds extra overhead and creates packet fragmentation with large packets...

Path MTU Discovery gets broken if ICMP is blocked
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/randz/protocol/path_mtu_discovery.asp
0
Industry Leaders: We Want Your Opinion!

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

 
pseudocyberCommented:
lr has a good point.  Try dropping MTU to say 1390 on all the WAN connections via DSL.
0
 
mgbookerAuthor Commented:
This is not a DSL
0
 
lrmooreCommented:
Can you describe your WAN links better? This is a *classic* symptom of MTU mismatches, not just on DSL...
0
 
mgbookerAuthor Commented:
How do you check MTU mismatches?
0
 
pseudocyberCommented:
You could try doing a ping with the packet size set and the do not fragment bit set and see if it gets through:

ping -l (size you want to test) -f destination.

For instance:  

F:\>ping -l 1473 -f www.experts-exchange.com

Pinging experts-exchange.com [64.156.132.140] with 1473 bytes of data:

Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.

Ping statistics for 64.156.132.140:
    Packets: Sent = 2, Received = 0, Lost = 2 (100% loss),
Control-C
^C
F:\>ping -l 1472 -f www.experts-exchange.com

Pinging experts-exchange.com [64.156.132.140] with 1472 bytes of data:

Request timed out.
Request timed out.

I just discovered my ISP is limiting MTU to 1472.
0
 
lrmooreCommented:
Depends on the routers and the wan links in between. Check router configurations on both ends of each wan link.
Depends on whether or not ICMP is being blocked (see link above regarding PMTUD)

Use the technique here to try different packet sizes with the "do not fragment" bit set on
http://www.dslreports.com/faq/2603


0
 
pseudocyberCommented:
Interested.
0

Featured Post

Concerto Cloud for Software Providers & ISVs

Can Concerto Cloud Services help you focus on evolving your application offerings, while delivering the best cloud experience to your customers? From DevOps to revenue models and customer support, the answer is yes!

Learn how Concerto can help you.

  • 4
  • 3
  • 3
Tackle projects and never again get stuck behind a technical roadblock.
Join Now