LVS
lvs-users
Google
 
Web LinuxVirtualServer.org

Re: [lvs-users] internal network behind direct routing instead of nat.

To: tc lewis <tim@xxxxxxxxxx>
Subject: Re: [lvs-users] internal network behind direct routing instead of nat.
Cc: lvs-users@xxxxxxxxxxxxxxxxxxxxxx
From: Julian Anastasov <uli@xxxxxxxxxxxxxxxxxxxxxx>
Date: Sun, 23 Jan 2000 16:03:57 +0200 (EET)
        Hello,

On Thu, 20 Jan 2000, tc lewis wrote:

> 
> ok so let's say we have:
> 
> director:      199.199.199.2
> vip:           199.199.199.3
> real server 1: 199.199.199.4
> real server 2: 199.199.199.5
> subnetting:    normal class C, /24 block, netmask 255.255.255.0
> router:        199.199.199.1, no special firewall action going on, etc.
> 
> in a case like this, the ipvsadm commands can be specified with -g and
> direct routing can be used, as 199.199.199.4 and 199.199.199.5 can send
> directly back to some client machine on another network, assuming there
> are no other interferences.
> 
> but let's say we want the real servers on an internal network, such as:
> 
> director:      199.199.199.2 and 199.168.199.1
> vip:           199.199.199.3
> real server 1: 199.168.199.2 (whatever)
> real server 2: 199.168.199.3 (whatever)
> subnetting:    normal class C, /24 block, netmask 255.255.255.0 (for both 
> networks)
> router:        199.199.199.1, no special firewall action going on, etc.
> 
> in a case like this, one would normally think to use nat instead of direct
> routing, and the responses from the real servers would go back through the
> director again and be translated back to the original source address or
> what not, blah blah, standard nat stuff.
> 
> my question is: can direct routing be used in a circumstance like this?
> say, a separate machine to be the gateway for 199.168.199/24 and forward
> packets, or masquerade?  something like:
> 
> director:      199.199.199.2 (eth0?) and 199.168.199.4 (eth1?) (shrug)
> vip:           199.199.199.3
> real server 1: 199.168.199.2 (whatever)
> real server 2: 199.168.199.3 (whatever)
> subnetting:    normal class C, /24 block, netmask 255.255.255.0 (for both 
> networks)
> router:        199.199.199.1, no special firewall action going on, etc.
> internal network's gateway: 199.168.199.1 (ethX?) and 199.199.199.4 (ethY?) 
> (shrug)
> 
> the director would be setup with ipvsadm -g commands for direct routing,
> and the gateway on the real servers would be configured as that "internal
> network's gateway", 199.168.199.1, which would presumably be setup as a
> [linux] machine to forward packets from 199.168.199/24 back out to the
> real world (via masquerading?).
> 
> would this work?  what kind of problems would be involved?  any thoughts
> on the matter or suggestions would be greatly appreciated, as always.
> 
> -tcl.
> 
> 

        You can try this setup:


                Clients
                   |
                  ISP
                   |eth0/ppp0/...
                Router/Firewall/Director (LVS box)
                   |eth1
        +----------+------------+
        |eth0                   |eth0
        Real 1                  Real2

Router: transparent proxy for VIP (or all served VIPs)
The ISP must feed your Director with packets for your subnet 199.199.199.0/24
VS/DR mode (Yes, VS/DR, this is not a mistake)
eth1: 199.199.199.2
default gw is ISP

Real server(s): nothing special
VIP on hidden device or via transparent proxy
eth0: 199.199.199.3
default gateway is 199.199.199.2 (the Director)

        This is a minimum required config. You can add internal subnets
yourself using the same physical network (one NIC) or by adding additional
NICs, etc. They are not needed for this test.

        In this setup we expect that the packets from the real servers
with saddr=VIP will be successfully forwarded from the director because
VIP is not configured in the Director. We expect that this setup is faster
than VS/NAT. But there is a little magic: how the packets for your subnet
are coming in the Director. If you solve it there is no problem for this
VS/DR test.

Regards,

Julian Anastasov


----------------------------------------------------------------------
LinuxVirtualServer.org mailing list - lvs-users@xxxxxxxxxxxxxxxxxxxxxx
To unsubscribe, e-mail: lvs-users-unsubscribe@xxxxxxxxxxxxxxxxxxxxxx
For additional commands, e-mail: lvs-users-help@xxxxxxxxxxxxxxxxxxxxxx

<Prev in Thread] Current Thread [Next in Thread>