[Info-vax] SFTP hang - from VMS to Windows

[jbriggs444 at gmail.com]

On Monday, February 25, 2013 10:19:32 AM UTC-5, GerMarsh wrote:
[...]
>Thank you for the comments and pointers. It is indeed an FTP connection
>which kicks the SFTP transfer back into life and the FTP is initiated from
>Windows. I reckon that this fact indicates that this is not a VMS SFTP
>client issue at all.

Here is a theory that is pretty well "out there"...

It is an ARP problem somewhere in the network.  The SFTP peer (or some
upstream router) has lost its ARP entry for its default gateway router.
Dynamic ARP is failing.  The FTP initiation triggers a transmission
attempt for a datagram toward a fresh IP address that is not currently
in the gateway router's ARP cache.  This causes that router to send an ARP
"who has" broadcast request.  The "who has" is picked up by the SFTP
peer (or its upstream router), added to the ARP cache and transmission
resumes.

Dynamic ARP can fail when the reqesting MAC address is a broadcast MAC.
This can happen with some flavors of Microsoft clustering.  Cisco routers
do sanity-checking and will refuse to accept ARP requests or replies which
contain multicast MAC addresses. A partial remediation for this is to
configure static ARP on the router facing the Microsoft cluster.  This
works surprisingly well as long as the network is busy and the router
sends frequent ARP requests on the attached subnet.  But it is a
prescription for intermittent failure when the segment is idle or when
a cluster member boots onto the segment.  A more complete remediation
is to configure static ARP on the servers within the Microsoft cluster
as well.  [Then you just have to worry about populating your switch MAC
address table with the multicast MAC address so that you are not depending
on multicast flooding for your layer 2 multicasts]