Learn how to a build a cloud-first strategyRegister Now

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 848
  • Last Modified:

Copying file fails in one direction

I have 3 sites (let's call them Sites 1a, 2a, 2b).  They were connected by T1 circuits, but were recently converted to Metro-E.  Everything works great, except for when I copy files.  Normal traffic flows normally.  Here is the problem.  If I copy a file from 1a to 2a or 2b using just unc paths that were typed in windows explorer, it will start to copy and then at around 10 seconds left it will just freeze and finally get one of 2 errors.....1) Cannot copy XXXXX: The specified network name is no longer available or 2) the path is too deep .  The path is 21 characters, so I know it is not too deep.  If I remote in to the server that I'm trying to copy the file to at 2a or 2b using pc/anywhere and then copy the file across from that direction it works perfectly.  In both cases I can be on the machine at 2a and copy from 1a or be on the machine at 2b and copy from 1a.  But if I am on 1a, I can not copy to 2a or 2b.  The file I'm trying to copy is 4.8 MB.  Smaller files seem to work.  The 2a is running Windows Server 2003 and the 2b is running Windows Server 2000.  On the 1a site, I have tried a windows xp pro machine and a Windows Server 2003 server.  I have worked with the phone provider that installed the Metro-E and they finally brought in the hardware vendor for their equipment.  He is saying it is a windows problem and not theirs.  My only problem with that is it worked perfect on the T1 circuit, so even if it is a Windows problem I need some direction on what to be looking for.  I don't feel anything should need to be changed since the Metro-E is basically just a wired connection to another site.  Any one that could point me into the right direction or more things to try to narrow down the issue would be appreciated.
0
durrence71
Asked:
durrence71
  • 5
  • 4
3 Solutions
 
powercramCommented:
What kind of hardware are you using?

Check your MTU's on all routers/firewalls to make sure they match.
0
 
JohnDemerjianCommented:
I agree that you should check your MTU size.  Here is one way to begin:
from point 1a, ping with a custom packet size to the servers in the remote locations where you are copying from/to and notice the difference in result.  If your MTU is not configured properly it can cause excessive fragmentation which will decrease performance and possibly cause errors like the ones you are seeing.  So if you haven't used ping this way try this test with the packet size set to 1500 (the default MTU for Ethernet).  the -f tells ping not to fragment the packet and the -l specifies the size.

ping -f -l 1500 <server IP>
Pinging <server IP> with 1500 bytes of data:
Packet needs to be fragmented but DF set.

if that returns with "Packet needs to be fragmented but DF set." keep reducing the packet size (1475, 1450, 1425) until you know the max packet size that will pass end to end between the point A and point B.  Confirm it is the same in all the directions you want to copy files to.  This is a good step one.  Chances are that if you had T1s in place prior, your MTU may be incorectly set on some gear.
0
 
durrence71Author Commented:
I have a Sonicwall Pro 2040 on the 1a side and a 3Com Cable/DSL router on the 2a and 2b side.  Neither the Sonicwall or 3Com routers let me set the MTU.  The Sonicwall lets me set the MTU, but only on the WAN interface(and it is at 1500).  The 3Com does not have a MTU setting at all.  According to the circuit providers all their routers are set to 1500 MTU.  They also pointed out for me to check the MTU settings, but to make them 1492 to cover for VLAN tags (which I'm not using, so they must be).
0
VIDEO: THE CONCERTO CLOUD FOR HEALTHCARE

Modern healthcare requires a modern cloud. View this brief video to understand how the Concerto Cloud for Healthcare can help your organization.

 
durrence71Author Commented:
John:

I had to go to 1450 before I would not get the packet needs to be fragmented but DF set message.  Since I can't find the MTU setting in my routers, should I try to set the MTU in the registry on my PC and then attempt to copy the file from my pc to the server at the other site?
0
 
JohnDemerjianCommented:
an MTU 0f 1450 seems fine.  I wouldn't do anything to work around it just yet.  the question is do you get the same result in all scenarios - we are trying to find a difference so we can put a finger on where the file copy problem is.  did you do the ping test in the same manner that the file copies would occur?

also, did you say you can copy from the windows GUI fine or do you run into problems doing that as well?  for example a copy/paste to \\server\share
0
 
durrence71Author Commented:
I tested the ping command from 1a to 2a (and 2b) and also tested the ping from 2a (and 2b) to 1a.  I had to adjust it down to 1450 in all cases.  Actually I found that 1472 works in all cases and 1473 is fragmented.  Didn't know if it was important to find the exact number where it works and doesn't work.

On the copy, I'm going to simplify this some and say just use sites 1a and 2a from now on.  I only mentioned 2b to show that I have 2 different circuits (although same type) that were not working.  In the gui if I copy from 1a to 2a it will fail.  If I use pcanywhere and remote into 2a and copy from 2a to 1a it will fail, BUT if I use pcanywhere and remote into 2a and copy from 1a to 2a, it works.  That is very confusing in all of this is that there is one way it does work.  It is almost like it matters if I "push" the file or "pull" the file (if that makes sense).

So if I copy from 1a to 2a ("push) the file it fails.  If I remote into 2a (same as sitting there at the machine) and copy from 1a to 2a ("pull"), it works.  If I remote into 2a and copy from 2a to 1a ("push") it fails.
0
 
JohnDemerjianCommented:
i think your MTU is fine.  what is latency like?  when you ping across the WAN are you getting 15ms response time or so?  

please try your copy process to a NEW folder location to rule out a sharing violation.  in other words copy the files to a c:\temp folder or something just to see if it makes a difference.  

also, i don't know if it is possible to have an asymetric route on your network but if you do a tracert from 1a to 2a and then a tracert from 2a to 1a do they follow the same *exact* path only in reverse?  

can you check the interfaces in your routers to see if there is any duplex/speed mismatching, crc errors or other errors on the interfaces?

how are you using a 3Com cable/dsl router with metro ethernet?  does that work?  if so, what is the metro ethernet speed?
0
 
JohnDemerjianCommented:
another thing to try is an FTP file copy over the WAN.  if it is easy enough to do, move a large amount of data with FTP and if it times out you can tell your vendor that FTP died as well, thus ruling out a "windows" problem.
0
 
durrence71Author Commented:
They had actually had me do that also.  I loaded Cerberus FTP server on 2a and then I loaded WS_FTP LE on 1a and the file copy was successful over to 2a.  They didn't want me using any windows software for this test (i.e. the built in ftp server on Windows 2003).  They again told me it was a Windows problem.  I don't disagree, but told them they need me to assist me with finding what setting(s) are causing the exact problem so that I can fix it.  From what I understand the default MTU in Windows Server 2003 and XP is 1500 on Ethernet networks.
0
 
JohnDemerjianCommented:
most devices on an ethernet network are configured to use 1500 MTU by default but in reality, you don't get exactly 1500 because of the overhead of various protocols.  in my experience an mtu of 1472 is normal and won't cause you any performance issues.  but i'm not a router god.  there is a protocol that auto-calculates mtu but i don't know if it is going to help you at all.  http://www.cisco.com/en/US/tech/tk827/tk369/technologies_white_paper09186a00800d6979.shtml

but i would really look at the other items suggested first.  crc errors on interfaces, autonegotiating when you should have the inteface fixed, errors in the logs - that is where i would spend time for now.  
0

Featured Post

New Tabletop Appliances Blow Competitors Away!

WatchGuard’s new T15, T35 and T55 tabletop UTMs provide the highest-performing security inspection in their class, allowing users at small offices, home offices and distributed enterprises to experience blazing-fast Internet speeds without sacrificing enterprise-grade security.

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