Operating System - OpenVMS
cancel
Showing results for 
Search instead for 
Did you mean: 

VMS V7.3-2 TCPIP 5.4 ECO5 to ECO6 FTP problem

 
John Abbott_2
Esteemed Contributor

VMS V7.3-2 TCPIP 5.4 ECO5 to ECO6 FTP problem

Related closed call...

http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=1057983

seen it (thanks), tested out the solution, but the supplied fix (copy *IPC_SHR.EXE) DOES NOT work on all our systems (I've checked IPC_SHR images installed via SDA, I am using the ECO 5 ones).

So far, systems with BIND disabled appear fine, those with BIND enabled do not. The problem is intermittent on the enabled ones, mostly every other ftp connect fails, but sometimes I get more than one failure to connect in a row.I need to test further... so far

$ ftp dns_name(local or resolved from primary DNS (wintel)) OR specifying an IP_ADDR fails, examples:

Reply from an ftp command to a softer_os gives:
$ ftp dns_name OR ip_addr
421 Service not available, Remote server has closed the connection

Alpha reply:
$ ftp dns_name or ip_addr
TCPIP-E-FTP_NETERR, I/O error on network device
-SYSTEM-F-REJECT, connect to network object rejected

Did anyone get an offical reply/solution from HP from the previous call I've linked to ? I don't think the ECO6 kit has been re-mastered.

Thanks in advance.
John.
Don't do what Donny Dont does
20 REPLIES
John Abbott_2
Esteemed Contributor

Re: VMS V7.3-2 TCPIP 5.4 ECO5 to ECO6 FTP problem

Update. Problem system is a 3 note system, common system disk. One node can ftp connect 100%, the two others have 82~85% failure rate. Routing looks fine, smtp and telnet fine. *IPC_SHR.EXE images are is sys$common:[syslib]
Don't do what Donny Dont does
John Abbott_2
Esteemed Contributor

Re: VMS V7.3-2 TCPIP 5.4 ECO5 to ECO6 FTP problem

The TCPIP$*.DAT files are in sys$common:[sysexe] (i.e ther's nothing in sysroot or anything obvious for that makes one node work and the other not).
Don't do what Donny Dont does
Volker Halle
Honored Contributor

Re: VMS V7.3-2 TCPIP 5.4 ECO5 to ECO6 FTP problem

John,

can you debug the BIND resolver by using:

$ DEFINE TCPIP$BIND_RES_OPTIONS "debug"

Then issue your IP commands...

Volker.
John Abbott_2
Esteemed Contributor

Re: VMS V7.3-2 TCPIP 5.4 ECO5 to ECO6 FTP problem

Hi Volker, looks like the reverse lookup debug output is missing on a failure. I include an attachment (with ubstituted ip and dns names) that gives two examples both from an node with intermittent ftp connects (the first works, the second that fails).

If I define the remote_system.co.uk name on the local host then I get no dns debug output and still ad-hoc failure.
Don't do what Donny Dont does
Volker Halle
Honored Contributor

Re: VMS V7.3-2 TCPIP 5.4 ECO5 to ECO6 FTP problem

John,

as the IP connection to the FTP server seems to fail, there will be no reverse lookup in case of the failing attempt.

Does the problem also happen with TELNET ? If so, you could use 'Monitoring Socket Activity' feature of TCPIP:

$ DEFINE TCPIP$SOCKET_TRACE 1
$ DEFINE TCPIP$SOCKET_TRACE - SYS$LOGIN:TCPIP$SOCKET_TRACE.LOG
$ TELNET node-or-IP-address

$ TYPE SYS$LOGIN:TCPIP$SOCKET_TRACE.LOG

The next step after this would be a TCPTRACE of the packets to/from the remote node.

Volker.
John Abbott_2
Esteemed Contributor

Re: VMS V7.3-2 TCPIP 5.4 ECO5 to ECO6 FTP problem

Hi Volker, I tried this before, I could not get a TELNET connect to fail.
Don't do what Donny Dont does
Volker Halle
Honored Contributor

Re: VMS V7.3-2 TCPIP 5.4 ECO5 to ECO6 FTP problem

John,

slight correction:

$ DEFINE TCPIP$SOCKET_TRACE 1

will show trace on SYS$OUTPUT

or

$ DEFINE TCPIP$SOCKET_TRACE - SYS$LOGIN:TCPIP$SOCKET_TRACE.LOG

will put trace in file.

http://h71000.www7.hp.com/doc/732final/6631/6631pro_003.html#socket_trace_sec

Volker.
Volker Halle
Honored Contributor

Re: VMS V7.3-2 TCPIP 5.4 ECO5 to ECO6 FTP problem

John,

if I try a TCPIP$SOCKET_TRACE with FTP, I get the following error (TCPIP V5.5):

$ DEFINE TCPIP$SOCKET_TRACE 1
$ ftp i64vms
Error opening trace log file: i/o error
220 i64vms.xxx.xxx FTP Server (Version 5.5) Ready.
Connected to I64VMS.
Name (I64VMS:halle):

It works with TELNET.

A TCPTRACE should not pose a big problem, it's just a couple of packets to be traced.

Volker.
John Abbott_2
Esteemed Contributor

Re: VMS V7.3-2 TCPIP 5.4 ECO5 to ECO6 FTP problem

Hi Volker thanks for your help so far,

I include the output for a TCPTRACE remote_node/FULL/OUTPUT=file.txt

14:13:12 entries are from the failure (error 421)
14:13:31 are from a good connect

again using $ ftp remote_dns_node_name
first one failed, up arrow, and 2nd attempt connected.

John.
Don't do what Donny Dont does
Ian Miller.
Honored Contributor

Re: VMS V7.3-2 TCPIP 5.4 ECO5 to ECO6 FTP problem

John,
have you reported this to HP?
TCPIP Eng do know about this and may have a fix which can be given to people who log calls.
____________________
Purely Personal Opinion

Re: VMS V7.3-2 TCPIP 5.4 ECO5 to ECO6 FTP problem

This is a new one on me, we don't have any other reports of this. Kinda glad I'm on vacation next week :)

Steve
John Abbott_2
Esteemed Contributor

Re: VMS V7.3-2 TCPIP 5.4 ECO5 to ECO6 FTP problem

Hi Ian,
> have you reported this to HP?
Yesterday

The FTP trace (I'm told) doesn't look like a dns issue...

The first three packets are as expected - SYN, ACK + SYN, and ACK. The
fourth is where it goes wrong - the server sends a 'FIN' back to the
client almost immediately (hence the "connection closed by remote host"
type of message). Normally, you would see an ftp 220 response from the
server.

I've tried using thr eco 5 ftp client image, no change.

I'm going to check the ftp logs again.

Over the weekend I will boot from a disk with eco 5 and test as the network is "slightly" different on the two cluster nodes that fail vs. the one that works.

Stephen... not planning on coming to the UK are you :-) you could pay us a vist ! thanks for the info, have a good one.

John.
Don't do what Donny Dont does
John Abbott_2
Esteemed Contributor

Re: VMS V7.3-2 TCPIP 5.4 ECO5 to ECO6 FTP problem

>> have you reported this to HP?
>Yesterday
You get two fresh *IP_SHR.EXE images. Uncertain if this will fix my ftp issue.
Let's see...
Don't do what Donny Dont does
John Abbott_2
Esteemed Contributor

Re: VMS V7.3-2 TCPIP 5.4 ECO5 to ECO6 FTP problem

The official images didn't fix my ftp problem. The cluster behaves just fine on the eco5 kit. Contacting HP again... Still puzzled why one node works and the other two fail to connect 82~85% of the time.
Don't do what Donny Dont does
Volker Halle
Honored Contributor

Re: VMS V7.3-2 TCPIP 5.4 ECO5 to ECO6 FTP problem

John,

you might also need to check 'the other end' of your failing FTP connection and the the route to that node (any firewalls involved ) ?

You've shown: Alpha reply: SYSTEM-F-REJECT. Did the connect message really reach the Alpha ?

Volker.
John Abbott_2
Esteemed Contributor

Re: VMS V7.3-2 TCPIP 5.4 ECO5 to ECO6 FTP problem

Out of office too much last week.

Here's where I'm at...

Our networks team have investigated the four switches which are used by the three VMS clustered nodes. The switches are stacked together and have no other special additional set-up. They cannot see what could possibly be set to prevent our systems from working as expected. The only thing in common is that the primary interface for all three nodes uses switch 3 (I suspect this is historical).

Therefore, this morning, to rule out any firewall, WANS, switch3, etc, I decided to perform a simple "ping" test using one of the nodes to my wintel desktop pc.

I swapped around the cabling of IE0 and IE1 interfaces on the VMS box, as these connect to our network using switch 3 and switch 4 respectively. A ping from my desktop pc (on the same LAN) can see (100%) all three interfaces/ip addrs on the VMS node, however if I login on the VMS box and ping my desktop PC, it only works if I "set route mypc/gate=primary_ie0_interface" It always fails if I route using the either of the other two interfaces.

Moving the cabling back to it's original position/switches gives the same results.

Therefore I think this proves by using another switch that the problem is NOT with the switches, but looks more like tcp/ip 5.4 eco6 kit.

It would be good to boot an ec05 kit sys disk and perform the same test, but I can't at the mo.

Don't do what Donny Dont does
Volker Halle
Honored Contributor

Re: VMS V7.3-2 TCPIP 5.4 ECO5 to ECO6 FTP problem

John,

if you have multiple IP interfaces defined in the same subnet, TCPIP uses a round-robin algorithm for outgoing sessions to try to load-balance across those interfaces.

You need to take this into account, if you try to draw conclusions from any OUTGOING tests !

Volker.
John Abbott_2
Esteemed Contributor

Re: VMS V7.3-2 TCPIP 5.4 ECO5 to ECO6 FTP problem

Hi Volker, yes I know that, thanks :-) this is why I did a

$tcpip set route mypc/gate=interface_n

so that my "ping" from vms to wintel used only one interface for each test. I only get a reply using the first interface.

It's almost like anything outbound only works via the primary.

Looks like I will have to repeat the same test under eco5 kit to completely rule out anything hardware as I don't manage the network hw.

Thanks
John.
Don't do what Donny Dont does
John Abbott_2
Esteemed Contributor

Re: VMS V7.3-2 TCPIP 5.4 ECO5 to ECO6 FTP problem

Using $tcpip set route mypc/gate=interface_n
is not valid... a netstat -rn shows that a gateway to mypc is set-up on a secondary interface pointing back to the vms box primary interface, so the packets just loop around the secondary back to the primary - doah!

More tracing required (as Volker suggests) and perhaps an out of hours hardware check.
Don't do what Donny Dont does
John Abbott_2
Esteemed Contributor

Re: VMS V7.3-2 TCPIP 5.4 ECO5 to ECO6 FTP problem


A dissapointing "closed by author" conclusion.

Moving from eco5 to eco6 sees a change in behaviour that I cannot see in the release notes and concerns a set-up where you have more than one interface on the same subnet... outbound ftp connects in eco5 appear to always use the primary interface whereas eco6 will see them balanced across all interfaces.

Part of our network was not configured to allow ftp via one of the interfaces.

Volker, thanks for your help.
Don't do what Donny Dont does