|
Somebody can correct me if I'm wrong, but you need to have the slaves on a
seperate subnet than the rest of the network. The Linux Director works by
getting the Linux masquerading code to handle the connections between the
slaves and the connecting computer. These connections have to be routed
through the forwarding firewall of the Linux Director (your master).
In your case, the packets are received on an interface (let's say eth0) which
is also the same interface for the rest of the network. The master will
decide that it isn't the computer that the packet was intended for and
finding no other routing information will drop the packet. Here's how I
think you should set it up.
192.168.1.254 gateway
192.168.1.10 master outside interface
192.168.2.10 master inside interface
192.168.2.21 slave1 (default gateway for slaves is 192.168.2.10)
192.168.2.22 slave2
192.168.2.23 slave3
You've now set up a class C subnet 192.168.2.0 netmask 255.255.255.0. You
have to set up masquerading out of the subnet or it won't work:
ipfwadm -F -a accept -m -S 192.168.2.0/24 -D 0.0.0.0/0
Then you can set up the forwarding to the three slaves.
ippfvsadm -A -t 192.168.1.10:4444 -R 192.168.2.21:4444
ippfvsadm -A -t 192.168.1.10:4444 -R 192.168.2.22:4444
ippfvsadm -A -t 192.168.1.10:4444 -R 192.168.2.23:4444
Add the following line if the master is also a slave (I think this is the
right syntax, but you may actually send it back to the outside interface,
I've never actually set it up):
ippfvsadm -A -t 192.168.1.10:4444 -R 192.168.2.10:4444
Your network doesn't need to know anything about your subnet because it is
masquerading. It just has to have a distinctly different network portion
from your main network to allow for routing.
>From the output of ippfvsadm I would say that the patch worked on your
Alpha. Someone else may have a more informed opinion on this though as I've
never used an Alpha.
Cheers,
Matthew
John Connett wrote:
> I am trying to set up a simple Linux Virtual Server to distribute
> requests to a single IP Address/Port across a small group of systems,
> including the target host. I have built a modified 2.0.36 kernel for
> Red Hat Linux 5.2 for Intel and ippfvsadm. Running ippfvsadm produces
> the following output:
>
> ippfvs (LinuxDirector) version 0.8 (NAT, LocalNode, WRR)
> IP Port Forwarding & Virtual Server Table
> Protocol Local Addr:Port ==>
> Remote Addr:Port Weight
> ...
>
> All the systems are on the same network segment, for example:
>
> 192.168.1.10 master
> 192.168.1.21 slave1
> 192.168.1.22 slave2
> 192.168.1.23 slave3
> 192.168.1.254 gateway
>
> All of the systems have a server running which is listening on the same
> port number, for example 4444.
>
> What combination of ipfwadm and ippfvsadm commands are needed on
> "master" to achieve the desired behaviour?
>
> My guess was something like the following:
>
> ipfwadm -F -a accept -m -P tcp -S 192.168.1.21
> ipfwadm -F -a accept -m -P tcp -S 192.168.1.22
> ipfwadm -F -a accept -m -P tcp -S 192.168.1.23
> ippfvsadm -A -t 192.168.1.10:4444 -R 192.168.1.10:4444
> ippfvsadm -A -t 192.168.1.10:4444 -R 192.168.1.21:4444
> ippfvsadm -A -t 192.168.1.10:4444 -R 192.168.1.22:4444
> ippfvsadm -A -t 192.168.1.10:4444 -R 192.168.1.23:4444
>
> All systems on the segment have their default route set to "gateway",
> 192.168.1.254.
>
> However, this doesn't seem to work ...
>
> Can someone suggest a solution that should work? Also, is the first of
> the ippfvsadm commands given above the correct way to configure for
> LocalNode operation?
>
> Also, can anyone confirm that this version of the Linux Virtual Server
> works on Red Hat Linux 5.2 for Alpha? I have tried the above with
> "master" as either Intel or Alpha with similar results.
>
> Many thanks in anticipation
> --
> John Connett (jrc@xxxxxxxxxxxxxx)
|
