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

[Ian Miller.]

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.

[STEPHEN CONWAY_1]

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]

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.

[John Abbott_2]

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

[John Abbott_2]

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.

[Volker Halle]

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]

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.

[Volker Halle]

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]

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.

[John Abbott_2]

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.