|
On Thu, May 11, 2000 at 03:20:02PM +0200, Ratz wrote:
[snip]
> The problem is, that clients coming from 172.23.2.[32-64] or correctly
> marked but unfortunately they are distributed as if persistency does not
> apply to them. A short look into the code and the concept show it and
> it's clear. However, it would be nice, if a mark could be handled like a
> single entity which would always be redirected to the same server in case
> of persistency.
Is there no persistency at all, or is the persistancy granularity
255.255.255.255? If there is 255.255.255.255 peristancy does
changing the netmask for persistancy help? If you want all traffic
for a specific network to be consistently be directed to the
same host, perhaps you should consider setting up a virtual
service for this that only has a single real server, this would
achieve this quite well. Perhaps I am missing the point.
> And the second additional feature which
> would be nice is, that one could specify multiple fwmarks as a group
> acting as one service. Then one could specify pools of IPs. Example
>
> ipchains -A input -p tcp -s 192.168.100.0/24 -d 192.168.100.100/24 80 \
> -m 1 -j ACCEPT
> ipchains -A input -p tcp -s 138.190.199.128/28 -d 192.168.100.100/24 80
> \
> -m 2 -j ACCEPT
> ipchains -A input -p tcp -s 172.23.2.32/27 -d 192.168.100.100/24 80 \
> -m 3 -j ACCEPT
With the exception of the group persistency behaviour that you suggest this
can be achieved by marking each network with the _same_ fwmark.
ipchains -A input -p tcp -s 192.168.100.0/24 -d 192.168.100.100/24 80 \
-m 1 -j ACCEPT
ipchains -A input -p tcp -s 138.190.199.128/28 -d 192.168.100.100/24 80 \
-m 1 -j ACCEPT
ipchains -A input -p tcp -s 172.23.2.32/27 -d 192.168.100.100/24 80 \
-m 1 -j ACCEPT
>
> ipvsadm -A -f 1,2,3 -s wrr -p 200 -M 255.255.255.255
> and normal compulsory stuff...
>
> The output would be as follows:
>
> IP Virtual Server version 0.9.13 (size=4096)
> Prot LocalAddress:Port Scheduler Flags
> -> RemoteAddress:Port Forward Weight ActiveConn InActConn
> TCP 192.168.100.100:0 wrr persistent 200
> -> 192.168.100.13:0 Route 1 0 0
> -> 192.168.100.12:0 Route 1 0 0
> -> 192.168.100.11:0 Route 1 0 0
> -> 192.168.100.10:0 Route 1 0 0
> FWM 1,2,3 wrr persistent 200
> -> 192.168.100.13:0 Route 1 0 0
> -> 192.168.100.12:0 Route 1 0 0
> -> 192.168.100.11:0 Route 1 0 0
> -> 192.168.100.10:0 Route 1 0 0
>
> So every CIP coming with fwmark 1 would f.e. go to 192.168.100.10
> every CIP coming with fwmark 2 would f.e. go to 192.168.100.11
> every CIP coming with fwmark 3 would f.e. go to 192.168.100.12
> a new CIP coming without fwmark would f.e. go to 192.168.100.10
> the next CIP coming without fwmark would f.e. go to 192.168.100.11
> and so on...
>
> Hope I could express myself in a more or less understandable way.
> I've already setup something that works in that direction but its
> extremely ugly with lots of service entries.
I think that what you want, a method of specifying variable persistancy
netmasks for a service is plausible, but I wonder how usful it would be.
Grouping addresses together has problems of its own - all traffic
from that group of addresses will be seint to a single host, egardless
of how many clients there actually are.
--
Horms
|
