|
Hello,
On Thu, 3 May 2001, Joseph Mack wrote:
> > May be they know about NAT boxes without FTP support :) But the
> > FTP support is useful because the data connection can be marked as
> > slave to the command connection and by this way to avoid command
> > connection reconnects.
>
> hmm, I don't know what's going on here. can you give an example of the
> sort of situation that passive ftp handles that will cause problems with
> active
> ftp?
This is the usual masq example, where any outgoing TCP connection
is automatically masqueraded. This is done for passive FTP when the
client is an internal host. In this case the client creates two
in->out connections and no special FTP support is required in the
masq box. In contrast, the active FTP requires someone to forward the
external server data connections to the right internal server/port.
This is done only with special FTP support, the ip_masq_ftp module
in the linux case.
> can you use priority routing to let the real-server think that the VIP
> is the main IP and for all processes to make their calls from the VIP?
ip route add default gw uplink_router src ONLY_ONE_VIP
This IP is selected as source when the processes don't
specify specific source address in their higher layer protocol requests.
Each route can use a preferred source value but only one.
> How about instead if we configured the VIP as a hidden IP on eth0 and
> put the RIP on a 2nd card say eth1?
If eth1/hidden=1 this is working, you can put many VIPs on eth1.
This setup assumes the broadcast ARP probes come from eth0. In this
case we replace lo with eth1 in the real servers and use hidden=1 for
this interface.
> Joe
>
> --
> Joseph Mack PhD, Senior Systems Engineer, Lockheed Martin
> contractor to the National Environmental Supercomputer Center,
> mailto:mack.joseph@xxxxxxx ph# 919-541-0007, RTP, NC, USA
Regards
--
Julian Anastasov <ja@xxxxxx>
|
