LVS
lvs-users
Google
 
Web LinuxVirtualServer.org

Re: Two node Virtual Server ?!

To: Wensong Zhang <wensong@xxxxxxxxxxxx>, linux-virtualserver@xxxxxxxxxxxx
Subject: Re: Two node Virtual Server ?!
From: Peter Kese <peter.kese@xxxxxx>
Date: Mon, 11 Jan 1999 20:33:42 +0100
Hi!

I have patched your kernel source code to make the VS-Router computer
behave as a server as well. I am now able to set up a two node virtual
server with one node configured as a server AND a router and the other
node configured as a router only. Of course I had to configure the
virtual server to support tunneling.

I have patched the end of the demasquerade function of the ip_masq.c
such
that the masquerading entry selected for a given tunnel connection is
checked whether the selected host is a local computer. If true, the
tunneling is simply skipped and the packet left to kernel to handle it
just as any normal packet originating from an ethernet adapter.

Using ippfvsadm to add a route to the router itself, the command could
look like this:

  ippfvsadm -A -t 203.1.1.10:8080 -R 127.0.0.1 (or an address of a
                                                local ethernet adapter)

Here is what I did:

--- ip_masq.c.org       Thu Jan  7 13:10:39 1999
+++ ip_masq.c   Thu Jan  7 13:13:24 1999
@@ -1893,6 +1893,7 @@
                ip_send_check(iph);
 #ifdef CONFIG_IP_MASQUERADE_IPPFVS_TUNNEL
                } else {
+                   if (ip_chk_addr(ms->saddr) == IS_MYADDR) return(0);
                    if(!ip_pfvs_encapsule(skb_p, dev, ms->saddr))
                        return 0;
                }

As you can see, I have added only one line of code:

+                   if (ip_chk_addr(ms->saddr) == IS_MYADDR) return(0);

The ip_chk_addr function is being checked before any packet gets
tunneled. Insted of calling ip_chk_addr for each packet, I think it
would be wiser to check for local addres when the masquerading-entry
structure is generated and store it into the structure itself as a
flag. That would speed things up, but I have decided to stay with the
simplest patch, to keep it simple, explainable and easy to test.

I have tested the kernel and it seems to work nicely. The router does
not
have to have a tunnel interface set up.

Do you think you could include such an option into the virtual server
kernel patch (maybe in next release)?

Cheers,

                                Peter


P.S. Any chance of porting the patch to 2.0.36/37. How about the 2.2.xx
kernels... will there be a VS patch too?

------------------------------------------------

Wensong Zhang wrote:
> 
> At 21:29 99-1-1 +0100, Peter Ke{e wrote:
> >
> >Hi!
> >
> >Is it possible in some way to use the router computer in both ways:
> >as a router and as a server. What I want is to set up a two node
> >virtual server using only two computers.
> >
> >I was playing arround with the following tunneling router
> >configuration (one computer only: router and server):
> >
> >ROUTER CONFIGURATION: IP=192.168.1.55, Virtual IP=192.168.1.10
> >  # configure the router
> >  echo "1" > /proc/sys/net/ipv4/ip_forward
> >  ifconfig eth0:0 192.168.1.10 arp up
> >
> >  # add a VS tunneling device to the router itself
> >  modprobe new_tunnel.o
> >  modprobe ipip.o
> >  ifconfig tunl0 192.168.1.10 up
> >
> >  # and add the router computer to the server list
> >  ippfvsadm -A -t 192.168.1.10:23 -R 192.168.1.55 (or 127.0.0.1 or
> >something)
> >
> >Well, it didn't work. When I try to telnet to 192.168.1.10, the computer
> >simply freezes. Ok, ok, I know, I am pushing it too hard, but still,
> >I wonder if the idea is totaly and utterly wrong in the first place
> >(shame on me) or is it worth of some further investigation? Would it be
> >possible to patch the virtual server in some a way to enable such
> >a (weird ;) configuration?
> 
> It seems that you want to make the load balancer and the service daemon run
> on the same node. I don't think it can work with the current patch.
> However, this function can be extended to build distributed servers with
> load balancing, for example, a server will be busy to handle requests, then
> it can forward requests to other less idler server; and so do other
> servers. I wanted to implement this function before, but I
> 
> For the configuration above,  the packet handling is as follows:
>                         Device          Dest:port
> incoming packet eth0:0          192.168.1.10:23
> routing it on the ip level
> encapsulating           lo              127.0.0.1:23
> decapsulating           tunl0           192.168.1.10:23
> routing it on the ip level
>         repeated as above. The packet will be droped due to the TTL number 
> finally.
> 
> No connection can be    established.
>

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