LVS
lvs-users
Google
 
Web LinuxVirtualServer.org

LVS-DR w/ fwmarks and no VIP on director

To: lvs-users@xxxxxxxxxxxxxxxxxxxxxx
Subject: LVS-DR w/ fwmarks and no VIP on director
From: Sheldon Hearn <sheldonh@xxxxxxxxxxxxx>
Date: Thu, 08 Apr 2004 00:12:52 +0200
Hi folks,

I plan to use LVS-DR with fwmarks (Horms' method) to load balance a
transparent TCP proxy cluster.

I've set up a simple test environment and am very proud of myself as I
watch packets sent by the client arrive at the director and then get
forwarded to the original IP dest_addr but with the Ethernet dest_addr
of a real server.  It's exciting to have gotten this far.

Can I set the director up so that it doesn't have the VIPs configured on
any of its interfaces?  There will probably be a few class C's behind
the TCP proxies (the real servers my this configuration) and it's going
to be a real ball-ache to configure all those aliases on the director,
and to update the director every time a new class C is added.

I'm using vendor-modified kernel sources (2.6.3-gentoo-r1) and lsmod
shows the following modules, which I loaded manually:

ipt_mac
ipt_MARK
iptable_filter
ip_vs_lc
ip_vs
iptable_mangle
ipt_mark
ip_tables

I have CONFIG_IP_ROUTE_FWMARK=y in my kernel config, in case this is of
interest.

My network configuration looks like this:

                        ________
                       |        |
                       | client | 10.0.0.1
                       |________|
                           |
                           |---------------
                           |               |
--                         |               |
L                          |               |
i           __________ 10.0.0.2            |
n          |          |    |               |
u          | director |----| (director has 1 NIC)
x          |__________|    |               |
                       192.168.0.1         |
V                          |               |
i                          |               |
r         -----------------+----------------
t         |                                |
u         |                                |
a         |                                |
l   ____________                      ____________
   |            |                    |            |
S  | realserver |                    | realserver |
e  |____________|                    |____________|
r   RIP: 192.168.0.2          RIP: 192.168.0.3
v   VIP: 172.16.100.101       VIP: 172.16.100.102
e
r

The 10.0.0.0/24 network is my private network that exists even when I'm
not testing an LVS configuration. :-)

I introduced the 192.168.0.0/24 network to simulate the LVS network, and
172.16.100.0/24 to simulate the real-world, routable IP addresses of the
hosts that the transparent TCP proxies (real servers) would be
protecting in the final solution.

I told 10.0.0.1 to route to 172.16.100.0/24 via 10.0.0.2.  The
realservers communicate back to 10.0.0.1 directly for now.  The
realservers have the VIPs assigned to lo:0 (-arp), to simulate the fact
that, in the final solution, they'd be "behind" the realservers.

I added 192.168.0.1 as an alias on the director.  Then I configured it
thus:

iptables -F
iptables -F -t mangle
# Using --dport for now; final solution will use all ports
iptables -t mangle -A PREROUTING -i eth0 -p tcp \
    -s 0/0 -d 172.16.100.0/24 --dport 80 -j MARK --set-mark 1
ipvsadm -A -f 1 -s lc
ipvsadm -a -f 1 -r 192.168.0.2 -g -w 1
ipvsadm -a -f 1 -r 192.168.0.3 -g -w 1

This works like a charm, but only if I configure the VIPs on the
director.

If I don't configure the VIPs on the director, then:

1) With net/ipv4/ip_forward=0, the director just ignores the packets.

2) With net/ipv4/ip_forward=1, the director forwards the packets to the
Ethernet address of the client.  This is probably just coincidental,
because the client happens to be the default gateway for the private
network 10.0.0.0/24 and 10.0.0.2 doesn't have any special routing
instructions for 172.16.100.0/24.

The section on Horms' method talks about not needing the VIPs on the
director at all, but I'm obviously missing the magic configuration
subtlety.

I hope I've provided enough information.  I think this is my first
appeal for help on a Linux mailing list, so please be gentle.

Ciao,
Sheldon.

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