1. Home
  2. Cisco Systems
  3. Spercified network name is no longer available....????

Spercified network name is no longer available....????

We have a windows XP PC, on a private vlan, gig link, behind a PAT NAT. This machine is copying data to and from a cifs server volume that is off campus. The copy will take about 2 hours, as calculated by the windows progress bar. The copy will stop with the following error, "The file XXXXXXXXX cannot be copied because the specified network name is no longer available." Where it stops is sporadic. It could be after 8 minutes, it could be after 75 min. The local PC tech has checked the PC, and has found nothing amiss, and I have checked network, and found nothing that would cause this. The interfaces shows no errors, the remote server shows no errors, the PC log shows no errors, and the NAT log didn't show any errors that I thought would cause this error. I did a Google search, and the error dates back to

2004, but there was no solid resolution. The ones that did find one was limited to soho type routers. I don't manage any of the campus routers, just our local switch(s), a 6509.

What I have done so far is to lengthen the NAT time-outs for udp and icmp. Neither have produced any positive results. Of course, this person is the ONLY one to have any issues with my network (if it is even a network issue). Trace routes look fine. I wasn't able to get Wireshark to work to see if there was some reset packet that is stopping the transfer. She is the only one to do a copy this long or big, and is the only one that is copying data to an off campus server. Everybody else is using a local NetApp.

I feel it may have something to do with the NAT. I say this because the PC used to be on the public vlan, and it didn't have these issues, or at least they didn't mention it. Due to security issues, it had to be placed on a private vlan behind the NAT. The machine cannot be patched due to the patches breaking the installed software. The error didn't start right away, but after a few days or so. The PC tech will be testing a different machine in the same vlan to see if the issue persists, and I will try and get wireshark to work to do a capture.

Are there any suggestions from the audience?

Thanks Lovejoy

Reply to
Lovejoy
Loading thread data ...

I would, as you suggest, capture the traffic during the failure. Also run say pingplotter to see if there are problems with the link. Pingplotter sends pings or other probes and displays the results very conveniently. Use long packets as well as short ones. you could use PingP to probe TCP 445 (or the other port, which ever your CIFS is using, 139?) but worry about leaving loads of half open connections on the other side or the firewall/nat. PP does close the connections but still worry about it:-)

Consider, compressing the remote file before transfer using a restartable file transfer tool - xcopy /z : maybe, but it did not seem to work when I tried it robocopy ftp - some clients support restartable transfers bit torrent - for industrial strength re-startableness

Reply to
bod43

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Anything stand out on the CIFS server side? Internal drive, not usb I hope. I seriously doubt you have anything wrong in the network as l2/ l3 are fairly black and white. They either work, or they don't, and if there is an issue, it should be reproducable or at minimum, you should be able to find something in counters or logs. If I had to take a shot in the dark, something is wrong on the storage side, and the error message is a generic one that happens when the volume is no longer accessible to write to. I'd check whatever logs you have on the server side.

Reply to
Trendkill

The storage side is pretty stable. The remote server is a NetApp as well. The admin checked the logs and didn't see any errors. The NetApp is pretty robust about errors. If anything was wrong, it would have made sure you knew about it. They have a pile of spare discs that was automatically sent to them when there was a false alarm sent to the company. I will have him double check the logs.

Lovejoy

Reply to
Lovejoy

I had mentioned robocopy to the tech, but am not sure if the users would want to use it. I will mention it to them again. Drag and drop can be a daunting task for them at times.

Lovejoy

Reply to
Lovejoy

Sounds to me like you could have a name resolution issue because of the NAT. Is the name being resolved via DNS, AD, WINS or are you specifing an IP address? You can specifiy the server name in the client's "hosts" file or "lmhosts.sam" file to avoid the resolution issue. Not sure why it resolves but then doesn't but Microsoft does do some weird stuff.

If you can get a sniffer capture of when it fails, that would definately point you in the right direction as to why the the transfers is stopped and tell you if this is a name resolution issue.

Reply to
Thrill5

the message "The file XXXXXXXXX cannot be copied because the specified network name is no longer available."

is microsoft's quaint way of saying that the connection has been lost.

Once a drive is mounted it does not use the name again. It is just a single TCP session for all functions associated with the mount. Directory listings, file copies, the lot. Now prefers TCP port 445 but clients still send to TCP 139? as well for every session initiation.

You can mount cifs drives by IP address, just substitute the address for the server name.

These ones are not presently active but they were working.

C:\Users\>net use New connections will be remembered. Status Local Remote Network

---------------------------------------------------------------------------=

Reply to
bod43

Thanks for the reply. I believe it is being resolved via WINS. I will have the tech to add the name to the hosts file. I am at a different site today, but will be there tomorrow.

Lovejoy

Reply to
Lovejoy

Well, after ding some more diggung and using the suggestions lister in this thread, it appears I may be having an issues with kerberos from behind my NAT. What I have found with a packet capture is that there is a kerberos request packet sent out, that comes back rejected, right before the transfer stops with an error message. The odd thing, to me anyway, is that the request is sent out after the transfer has started. I have a pretty standard PAT/NAT set up, and all my other users have no issues. Is there some option I need to set in order for kerberos to work correctly for this one user?

Lovejoy

Reply to
Lovejoy

You could try to force the Kerreros to use TCP. There is a know timeout issue when it uses UDP.

formatting link

Reply to
Brian V

Once upon a time I had a problem with MTU and UDP kerberos.

I forget all the details but there was (Server 2000/3 maybe) a registry value that specified the kerberos request size that when exceeded caused kerberos to switch to TCP from UDP. 2000 bytes seems to ring a bell. In one instance I changed it to a value less than a single packet which fixed some problem.

Reply to
douglas.scott

Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.