- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - OpenVMS
- >
- Re: ftp large files fail, small files succeed
Categories
Company
Local Language
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Discussions
Discussions
Forums
Forums
Discussions
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Community
Resources
Forums
Blogs
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО07-13-2010 11:08 AM
тАО07-13-2010 11:08 AM
I'm into a client via vpn, though I don't think that should matter. (though once I get connected via vpn, I can't putty directly to the test system, I have to putty to the prod system and then telnet to the test system.)
Anyway, trying to ftp a large file from prod to test (both vms). I can ftp smaller files. for larger ones, I get the output below. it connects enough to get the filesize, and allocates that space on the test system disk. but, the file size remains 0.
Does anyone still hang out here? :) any thoughts? some type of firewall/network switch setup issue that I'd have no access to? (I did ask them to verify fixed full on the ports.)
Thanks!
Ron
FTP> bin
200 TYPE set to IMAGE.
FTP> get openvms_alpha_8_3.zip
200 PORT command successful.
150 Opening data connection for SYS$COMMON:[SYSMGR.WEB.83]openvms_alpha_8_3.zip; (10.252.16.75,49183) (209548312 bytes)
HNATST::_TNA8: 14:39:12 TCPIP$FTP CPU=00:00:00.72 PF=1386 IO=2374 MEM=349
GET (VMS+) 0 bytes 00:00:04.98 elapsed (0.00 KB/S)
Local: LAB2:[000000]OPENVMS_ALPHA_8_3.ZIP;1
Remote: openvms_alpha_8_3.zip
HNATST::_TNA8: 14:39:22 TCPIP$FTP CPU=00:00:00.72 PF=1386 IO=2378 MEM=349
GET (VMS+) 0 bytes 00:00:15.14 elapsed (0.00 KB/S)
Local: LAB2:[000000]OPENVMS_ALPHA_8_3.ZIP;1
Remote: openvms_alpha_8_3.zip
HNATST::_TNA8: 14:45:59 TCPIP$FTP CPU=00:00:00.72 PF=1386 IO=2382 MEM=349
GET (VMS+) 0 bytes 00:06:51.61 elapsed (0.00 KB/S)
Local: LAB2:[000000]OPENVMS_ALPHA_8_3.ZIP;1
Remote: openvms_alpha_8_3.zip
%SYSTEM-F-CONNECFAIL, connect to network object timed-out or failed
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО07-13-2010 12:14 PM
тАО07-13-2010 12:14 PM
SolutionI'd start with looking at the network. Make sure both VMS systems and switches are set to agree on speed/duplex or auto negotiate.
What sort of VPN and is there an MTU recommendation to trim MTU? Are these Giga adaptors? If so, are jumbo frames enabled and over running the VPN?
Andy
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО07-13-2010 01:33 PM
тАО07-13-2010 01:33 PM
Re: ftp large files fail, small files succeed
As has been noted, duplex mismatches somewhere in the path will produce this type of symptom (I have seen it, they can be pernicious to track down -- I had it happen at a client a while back, someone in the network group had swapped a switch and mis-configured the replacement).
A LAN trace of the transfer can be illuminating. Wireshark is freely available, and runs on many standard personal platforms.
The small files may not hit the timing problem that is the actual problem.
- Bob Gezelter, http://www.rlgsc.com
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО07-13-2010 02:02 PM
тАО07-13-2010 02:02 PM
Re: ftp large files fail, small files succeed
As others said, this is almost certainly a duplex mismatch.
> (I did ask them to verify fixed full on the ports.)
Please ask "them" to set AUTO on all ports and switches. Hard setting network speeds is just setting yourself up for a failure like the one you're observing sometime in the future.
Remember to check all systems in the path between you and the FTP target.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО07-13-2010 04:45 PM
тАО07-13-2010 04:45 PM
Re: ftp large files fail, small files succeed
VMS Engineer who wrote ethernet drivers for a couple of decades is to set both ends of the connection to autonegotiate, assuming a modern version of VMS (in this case "modern" means V.3-2 and newer) and a properly-functioning switch. VMS should always get it right.
-- Rob
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО07-14-2010 03:55 AM
тАО07-14-2010 03:55 AM
Re: ftp large files fail, small files succeed
I do find it interesting though, I'd always heard NOT to use auto, but that seems to be the opposite of what I'm hearing here. I will take that into consideration! It seems to me - though I can't remember details - that auto was to be avoided because "things" (cisco, nics, can't remember what) didn't always make the right choice, so that's why fixed was preferred. Of course, this may be outdated information...
So, thanks for your input, and I will report back if I find a definitive answer.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО07-14-2010 04:30 AM
тАО07-14-2010 04:30 AM
Re: ftp large files fail, small files succeed
Since small file transfer fine, but large files are allocated, but not transferred, I'd look for something that might be tearing down an "idle" connection. Does the path between the production system and test system involve some sort of firewall or NAT device?
The information above shows that you aren't operating in passive mode; have you tried passive mode?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО07-14-2010 04:35 AM
тАО07-14-2010 04:35 AM
Re: ftp large files fail, small files succeed
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО07-14-2010 06:24 AM
тАО07-14-2010 06:24 AM
Re: ftp large files fail, small files succeed
This will cause the FTP server to create the data port and pass information to the client as to how to connect to it.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО07-14-2010 06:32 AM
тАО07-14-2010 06:32 AM
Re: ftp large files fail, small files succeed
ACTIVE and PASSIVE are transfer modes. Check your ftp client command documentation for details. The command is often a toggle command "passive", but syntax varies. TCP/IP Services uses the SET PASSIVE (on|off) command.
ACTIVE: the ftp client tells the ftp server which port the server should connect back to. Can be blocked by the client or client network firewall.
PASSIVE: client asks server for the identity of a port to connect into. Can be blocked by the server or server network firewall.
Because of that second channel and its associated handling, the ftp protocol design is largely incompatible with modern IP networks; with (most) IP firewalls.
(Trivia: ftp is older than IP, and way older than IP firewalls.)
The "fun" is that ftp uses a second IP port from the ephemeral range, and in a way that is inherently blocked by the most prevalent designs for IP firewalls. This means that the port range specified for ftp will have to be coordinated with the firewall, and opened. (And yes, other network applications can also use the ephemeral port range, so various firewall administrators are loathe to open it.)
There are comparatively sophisticated IP firewalls that can deal with ftp, as they explicitly know the ftp protocol, sniff and remember the ftp traffic, and automatically open the correct port for the impending data connection. These firewalls aren't yet in common use.
All of which means that ftp goes off the rails fairly regularly, and folks try the so-called active and passive transfers, and can end up opening up vast ranges of IP ports.
ftp also spews your credentials in cleartext, so it's a poor choice for any applications where write access is required.
sftp is a far newer design and - though it shares three letters with and its basic purpose with ftp - shares little else. sftp is vastly easier to punch through a firewall, and you can also incorporate certificates to greatly reduce your exposure to brute-force server attacks.
Yes, I've been known to express a relative distaste for ftp. Here are some technical details behind that opinion and around why ftp is such utter "fun" to deal with:
http://labs.hoffmanlabs.com/node/530
ftp is best left to the task of anonymous reading of and copying of files from a server, and little else. If you even use that and not something like WebDAV.
A network that requires VPN to PuTTY to telnet (and particularly if that's three separate steps and two intermediate hops) would imply the potential for simplification there, and potentially elsewhere in the network design. That is not a typical sequence for a secure network, and not an access sequence that would be commonplace for a more "open" internal network. I'd probably install a better and VPN-capable firewall, or otherwise reconfigure the firewall(s) and that LAN to allow a connection onto the LAN with the VMS servers. Based in this description (and I've built and rebuilt these sorts of network configurations myself) the network design looks to need some assistance to better contend with the organic growth it has apparently undergone.
Again, Note: IP firewalls aren't a factor with VMS, as VMS doesn't (yet?) have one. This particular case likely does NOT involve firewalls, particularly given the transfer works with smaller files.