|
On Tue, Oct 10, 2000 at 01:24:26PM +0200, joern maier wrote:
> Hi there,
Hi,
I believe that the problem is as follows relates to your use
of a firewall mark, I asume that CBQ keys of this, correct?
ipchains -A input -p ip -s 192.168.10.15 -m 100 -j ACCEPT
This marks the packet with firewall mark 100. This rule should stay on the
input chain but:
If a packet's skb has a firewall mark stamped on it then LVS will use this
as the key for the vitual service rather than the desination IP address,
port and the protocol.
Try changing your ipvsadm rules to something allong the lines of the
following.
ipvsadm -A -f 100
ipvsadm -a -f 100 -r 192.168.10.17:0
...
Note tha as per the ipvsadm man page LVS ignores the port for the real
server if a firewall mark service is used, rather traffic will be sent to
the same port on the real server as the port that it was recieved on. I.e.
you can't translate the port.
I'm not entirely sure where CBQ hooks in and it may not be able work with
LVS, but the above should at least get you a setup that will work from the
LVS end.
> 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
>
> the real IP-Adr of the LB is:
> 192.168.10.01
>
> serviced which are provided by LVS are telnet and http
>
> additional services on the director which are set up with IP
> 192.168.10.01
> and should therefore be unknown to the director and just be accessable
> via
> the real name of this server are: telnet, http and ftp
>
> the client is just for testing purposes
>
> what I´m trying to do is shaping the bandwidth from the load balancer to
> the
> webservers in a way that the client (src 192.168.10.15) is allowed to
> send a
> a maximum of 200KBit/s of data to the servers. Therefore I compiled the
> kernel
> of the LB (=VS.director) with the appropriate features. However it
> simply does
> not care about the bandwidth limitation. I tried it in two different
> ways:
> attempt 1:
> I implemented a CBQ filter like this:
>
> # tc filter add dev eth0 parent 100:0 protocol ip prio 100 u32 match ip
> src 192.168.10.15 flowid 100:100
>
> -> the queue 100:100 is set to a range of 200Kbit/s but this is just
> ignored. As many
> data as is send by the client is forwarded to the realservers
>
> attempt 2:
>
> I set the filter roule in a way that every package marked with 100 by
> the firewall is
> put into the above mentioned queue (100:100):
>
> # tc filter add dev eth0 protocol ip parent 100:0 prio 100 handle 100 fw
> classid 100:100
>
> then I set up the firewall with the following roule:
>
> # ipchains -A input -p ip -s 192.168.10.15 -m 100 -j ACCEPT
>
> after doing this, the LB (VS.director) did not forward any packet to the
> real_servers
> anymore. Trying it with http he used teh webserver which runs on the
> same
> machine as the director but should be unknown to the director because it
> is set up on the real IP of the director and never mentioned in any of
> the configuration skripts.
>
> 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.
>
> thanks,
> Joern
>
--
Horms
|
