LVS
lvs-users
Google
 
Web LinuxVirtualServer.org

Re: Redhat6.1 and DR via the director itself.

To: Stephen Zander <gibreel@xxxxxxxxx>
Subject: Re: Redhat6.1 and DR via the director itself.
Cc: Lars Marowsky-Bree <lmb@xxxxxxx>, catls <catls@xxxxxxxxx>, lvs-users@xxxxxxxxxxxxxxxxxxxxxx
From: Julian Anastasov <uli@xxxxxxxxxxxxxxxxxxxxxx>
Date: Fri, 12 May 2000 07:40:02 +0300 (EEST)
        Hello,

On 11 May 2000, Stephen Zander wrote:

> >>>>> "Lars" == Lars Marowsky-Bree <lmb@xxxxxxx> writes:
>     Lars> Because with the fw-mark stuff, the load balancer doesn't
>     Lars> have to have that interface any more.
> 
> My urn for a stupid question then: if the director doesn't have an
> interface with VIP dound to it, how does it accept the packets at all?

        Please, this thread is very interesting :)

        First for the fwmark. The fwmark support int the
kernel just mark packets. It can't be used to mark these packets
to be delivered locally. The routing decides which packet can be
locally accepted. But you can check the fwmark at routing level. 
We have two variants:

- patch the kernel in the source address validation, which is a
hack

- use policy routing to allow the director to forward packets
from the real servers with saddr=VIP. No patch required. OK,
this is again a hack.

        I'm calling for testers for the second case. We want
using advanced routing techniques to allow these packets to
exit from the Director.

        Here is my first try for such rules (in the Director):

# DIP* -> VIP is local
ip rule add prio 200 from DIP1 iif eth1 table 200
ip rule add prio 201 from DIP2 iif eth1 table 200
... Put here all DIPs that is possible to talk with VIPs,
usually none but this is not a problem if these rules exist

# Any other traffic to VIP* is unicast
ip rule add prio 1000 from 0/0 iif eth1 table 201

# Local table
ip route add table 200 local VIP1 dev eth1
ip route add table 200 local VIP2 dev eth1

# Unicast table
ip route add table 201 unicast VIP1 dev eth1
ip route add table 201 unicast VIP2 dev eth1

        Is that looking good? eth1 is where the packets from
the real servers come from (the internal interface).

        We want everything (not DIPs) to VIPs on eth1 to
be treated as unicast.

        May be that is not correct. I'm calling for
testers with enough time and hardware to test it :)
Please, no rp_filter in the first test! But in the second
yes. You must know how to use policy routing.


Regards

--
Julian Anastasov <uli@xxxxxxxxxxxxxxxxxxxxxx>



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