Service Guard and Active FTP

[Kent Pollard]

Does anyone know if Service Guard gets involved in an Active FTP session? Here's what I mean:

When an active FTP sessions is initiated by the client it connects to the server via the Virtual IP address configured in Service Guard. When the server initiates the return connection of the FTP process instead of it returning with the actual IP address of the server Service Guard makes the initiating IP address that of the virtual IP address.

We have an issue here that we have a client making an Active FTP connecition to our production server via the Virtual IP address and the FTP process works flawlessly. But once in DR (where we do not have Service Guard)the client still connects to the NAT of the Virtual IP address and a router NAT's it to the hard IP address so when the server initiates the return the router sees that and sends the traffic to the NAT of the real IP address of the server and not the NAT of the virtual IP address.

After all the above confusing explainations all I really want to know is does Service Guard play a roll in Active FTP sessions?

Thanks,

[Olivier Masse]

First of all, as you probably know already active FTP is not ideal since it is not easily to firewall it on the host or run it behind a NAT. That being said, I run an FTP service under ServiceGuard with the stock wu-ftpd daemon that comes with HP-UX and didn't have any problems, although I'm not sure any of the clients use active FTP; all my tests were done using passive FTP and I'm not behind a NAT so that makes things easier.

You can bind wu-ftpd to a particular IP address using daemonaddress in /etc/ftpd/ftpaccess. If I recall correctly, this will force all TCP sessions initiated server-side to use the floating IP. I tried it a while ago, but at my site I limit the number of available passive ports and using daemonaddress deactivated that feature so I ditched it.

On a side note, be sure that in /etc/inetd.conf the protocol for ftpd is set to "tcp" and not "tcp6". When using "tcp6" it starts the daemon in IPv6 mode and many features get disabled. This might be what you're experiencing on your failover node.

Good luck

[Armin Kunaschik]

As long as you use the OS supplied wu-ftpd, this is the standard. This is not a Service Guard issue, but depends on the use of the virtual IP address. Outgoing traffic is routed through the NIC (that is IP address) the default gateway points to, which is never identically with the virtual ip address (and can not be!!). That means, the source for outgoing packets "changes" if the cluster fails over.

I could not find an option to bind wu-ftp onto a particular ip address, so you're probably out of luck.

You may try another ftpd (like proftpd), but you still won't get uninterrupted transfers when the cluster fails over to the other node.

My 2 cents,
Armin

[Rita C Workman]

Why not look at it from a different perspective - resoution.
Make DNS work for you !

Have them search NOT for an IP, but for the PkgName. That way they always find what they're looking for, even in a failover locally.

Now for your "in DR" statement. Well - you could just turn your clustered server(s) into single node clusters in DR. Hence resolution remains the same - to the Pkg.
[ I say this, cause it is fairly easy to do and how we handle DR for an 8 node cluster we have. That way, again, resolution continues to work ]

Just an option,
Rgrds,
Rita

[Rita C Workman]

Sorry I forgot to address your specific question:

After all the above confusing explainations all I really want to know is does Service Guard play a roll in Active FTP sessions?

>>>Answer - I do not believe that Service Guard plays any role in Active FTP sessions, other than that it is running. It simply mounts up file systems and runs whatever commands (i.e. start Oracle instance) you set it up to run at startup/shutdown. FTP sessions are handled as a result of it's network connection with a user interface to the File Transfer Protocol.

/rcw

Rgrds,
Rita

[Stephen Doud]

Serviceguard only has the ability to assign a relocatable IP to a NIC when the package starts, and remove it when the package is halted. It does not innately influence the way that a system or network routes.

The network configuration differences between the normal package operation site and DR site produces the differing results you are seeing.

[Kent Pollard]

I realized I did not word my question well. How about this;

For an Active FTP session. When the client makes the connection to the Virtual IP address of the package does Service Guard cause the return connection to not be initiated by the normal IP of the network card but be initialized by the virtual IP address of the package? I am assuming it does because it is the only thing that I can think of that would be doing it. Normal traffic ( Say a telnet session ) that originates from the server goes out with the physical IP address of the server but because the Active FTP session was started by a client system, Service Guard adjusts the return connection to use the Virtual IP address instead of the physical IP address.

I am looking for confirmation of this so we know for sure that if we create a single node cluster in DR then this active FTP issue would be resolved. Unfortunately we are being forced by the client that this file transfer originates from to use Active FTP so we have no other option even though Passive FTP or better yet Secure File Transfer would work without an issue.

Thanks for all the responses so far though.

Kent.