|
Hello,
On Tue, 10 Oct 2000, joern maier wrote:
> Hi there,
>
> I hope anybody of you can help me. I´ve got a problem using LVS and CBQ
> (class based queueing -> feature of advanced routing of the Linux
> Kernel)
> with CBQ you can shape bandwidth (see adv_routing_how_to)
> The problem is as follows:
>
> I´ve got a setup like this using LVS and direct_routing, aller hosts are
> Athlon 800MHZ, 256MByte RAM, 3com90x 100Mbit Netcard using SuSE Linux
> 7.0
> i.e. Kernel 2.2.16:
>
>
>
> ---server_1 (lo:0 192.168.10.17)
> /
> client --------------|-----------------server_2 (lo:0 192.168.10.17)
> 192.168.10.15 load balancer \
> (with CBQ) ---server_3 (lo:0 192.168.10.17)
> eth0:110 = 192.168.10.17
>
>
> the real IP-Adr of the real servers are:
> server_1: 192.168.10.07
> server_2: 192.168.10.08
> server_3: 192.168.10.09
>
...
>
> using one of the following roules nothing happend:
> # ipchains -A forward -p ip -s 192.168.10.15 -m 100 -j ACCEPT
> or
> # ipchains -A output -p ip -s 192.168.10.15 -m 100 -j ACCEPT
>
> has anybody a clue what I´ve done wrong or if you need some more
> information so
> please e-mail me.
LVS currently uses fwmark only to lookup the virtual service. If
you mark packets they don't hit non-fwmark virtual services. This
problem is known from long time. May be now it is time the packets
with fwmark!=0 to be checked for non-fwmark services too. I.e. we will
perform two lookups for virtual service for the marked packets: little
performance drop for the fwmark users.
You can't use ipchains to distinguish the packets to different
real servers in VS/DR mode. The packets are not changed. If you trace
them you can see that only the MAC address is different. The real server
IP is used only for the routing decision, i.e. to select the parameters
for the lower layer. For VS/TUN and VS/NAT you can safely rely on the
IP header to extract the real server IP but not for LVS/DR. This is the
way LVS/DR is working: the destination address in the IP header is
not changed, it is same for all real servers: the VIP.
Regards
--
Julian Anastasov <ja@xxxxxx>
|
