FTP failure on bigger files

[Steven Underwood]

I am in the process uf an upgrade of our ES40 from 7.2-1 to 7.3-2 and an Oracle upgrade. To facilitate this, we rented a clone to our first machine and are currently running production from there while I upgrade our box.

I am having problems transferring any file larger than about 20 blocks via ftp between the 2 ES40 boxes (alpha1 and alpha3) which are on the same LAN segment. I can transfer them successfully through another Alpha (alpha2) located on the WAN in another part of the state, but a 2 part transfer is not ideal.

Before the upgrade, the alpha3 server was a clone of the alpha1 machine (split mirror set moved). The alpha3 system has been upgraded to ODS-5 along with the OS and TCPIP upgrades.

Any ideas are welcome.

The systems:
ALPHA1::SUNDERWOOD$ tcpip sh ver

DIGITAL TCP/IP Services for OpenVMS Alpha Version V5.0A
on a AlphaServer ES40 running OpenVMS V7.2-1

ALPHA2::SUNDERWOOD$ tcpip sh ver

DIGITAL TCP/IP Services for OpenVMS Alpha Version V5.0A
on a DEC 3000 Model 400 running OpenVMS V7.1

ALPHA3::SUNDERWOOD$ tcpip sh ver

HP TCP/IP Services for OpenVMS Alpha Version V5.4 - ECO 2
on a AlphaServer ES40 running OpenVMS V7.3-2

[Antoniov.]

Hi Steven,
because alpha1 and alpha3 are on same lan segment I guess you could use decnet to transfer files that's simplest way do copy.
However, because it very limited you can copy via ftp, please what kind of error do you see during copy?

Antonio Vigliotti

[Steven Underwood]

I don't have decnet installed on either machine and upgrading the production server is out of the question (testing required).

Sorry about forgetting the error message...

Anything more than a about 20 blocks takes a long time (sometimes up to a minute) to transfer and I can see by disk activity that nothing is moving. On larger transfers (>~50 blocks) after a few minutes I get:
%SYSTEM-F-CONNECTFAIL, connect to network object timed-out or failed

By the way, this happens with GET or PUT in either direction.

[Steven Underwood]

Sorry to reply to my own messge but I just received a new error while trying a larger transfer.

This error message on alpha3 PUT:
%TCPIP-E-FTP_SEND, cannot send on socket
-SYSTEM-F-LINKDISCON, network partner disconnected logical link

This error message on alpha1 GET:
550-Failed to send data on socket.
550 network partner disconnected logical link

[Bojan Nemec · Accepted solution]

Hi,

What about the switch and alphas ethernet port settings. This is a known issue which was discuted in more than one thread in this forum.
The two ports (alpha and switch) must be set to same speed. The easiest way is to set all ports to Fast Full Duplex.

The -SYSTEM-F-LINKDISCON means that the communication betwen alphas was droped, or that the other party (FTP server) has closed comunication or crashed.

Bojan

[Steven Underwood]

Good thought...because I was switching this machine between testing on a private network and needing to get data from the LAN, I had the machine connected to a hub which then was connected to the switch as the other machine is. I have removed the hub and connected directly to the switch but get the same errors.

The alphas are both set to FFD via the console as are the BayStack 450's ports that are in use. I will try slowing down the port on the test apha to see if there is any improvement.

[Jan van den Ende]

Steven,

I have to agree with Bojan, and add one more detail:
(have your network people) switch OFF auto-negotiate at the switches! It is a recurrent issue, and for network people counter-intuitive, but it DOES make a difference!

hth


Jan

[labadie_1]

I have already seen FTP failing with your 550 error message. It was due to a router, and the route was not the same going from A to B and from B to A. Check carefully the route with traceroute to alpha3 from alpha1 and the reverse. You may be surprised...

This reminds me of (long ago) a Decnet copy from Paris to Paris, taking so long that the first solution was to make a tape, give it to a guy with a motorcycle who went to the other site (3 kms). We eventually discovered that the packets went from Paris to Hong-Kong, then England (London, then various places in England) and then back to France.

[Antoniov.]

Just for curiosity,
this is the work table:

Workstation <-> Switch ------> Result
-----------------------------------------
Forced Half <-> Forced Half -> Works
Forced Full <-> Forced Full -> Works
Auto <--------> Auto --------> Maybe
Forced Full <-> Auto --------> NO
Auto <--------> Forced Full -> NO
Forced Half <-> Forced Full -> NO
Forced Full <-> Forced Half -> NO

Antonio Vigliotti

[Steven Underwood]

Thank you all...this has been solved.

It is the network negotiation issue. The switching of networks had me plug it into the wrong port on the switch. I found it when I tried the slower speed and found changing the port (I thought I was conected to) did not change anything.

Thank you all. BTW, the routing is the same for both machines because they are in effect the same configuration, with one upgraded.