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.
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]
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.
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.
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.
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.
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 !
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.
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.
