LVS
lvs-users
Google
 
Web LinuxVirtualServer.org

Re: LVS-TUN for Linux(director)-OpenBSD(realserver)

To: Joseph Mack <mack.joseph@xxxxxxx>
Subject: Re: LVS-TUN for Linux(director)-OpenBSD(realserver)
Cc: lvs-users@xxxxxxxxxxxxxxxxxxxxxx
From: carla quiblat <carlaq@xxxxxxxxxxxxxxxx>
Date: Tue, 2 Jul 2002 10:00:13 +0800 (PHT)
Hello,

On Mon, 1 Jul 2002, Joseph Mack wrote:

> carla quiblat wrote:
> 
> > For example, in linux to create a tunnel, you did this:
> > 
> > on the director: no tunnel is created because ipvs does the encapsulation
> > on the realserver:
> 
> not quite. ipvs on the director does the encapsulation. the decapsulation 
> takes
> place on the realserver.

        sorry, i meant tunnel interface and my statement above should have
read "On the director: no tunnel interface is created because ipvs does
the encapsulation. On the realserver: ..."

> 
> > 
> 
> so you do or don't have it working?
> 

        It's working. Telnet, and apache with virtual hosting. My test
setup, though, is just internal but it should work.

> 
> don't know anything about xxxBSD. On linux you need a routing command to
> route packets which arrive on the ethernet device to the tunnel device.
> Can you figure out a ***BSD command that does that?
> 
        You need to know the tunnel endpoint and then define the tunnel as
bellow using the gif interface. There's also a "tun" pseudo-device
supported by the FreeBSD kernel but I'm not familiar with it.

        ifconfig gif0 tunnel source_IP dest_IP

should create the tunnel. In LVS-TUN case, you don't have to add a
route because the tunnel is one-way, only from director-to-realserver,
not realserver-to-director. When it sees that the packet comes from
dest_IP, the packet goes through gif0 interface and is decapsulated.

> 
> > So what I did on the OpenBSD realserver is this,
> > 
> >         ifconfig fxp0 10.10.8.199 netmask 255.255.255.0 up
> >         route add default 10.10.8.1
> >         ifconfig gif0 tunnel 10.10.8.199 10.10.8.98
> 
> this looks like you're sending tunnel packets from the RIP to the DIP.
> There's no traffic that will go along this route
        
        Yes it does look that way but it does not because I have not
added a route. gif0 tunnel interface can encapsulate, decapsulate,
whichever is appropriate. It's just the way you create a tunnel in *BSD
using gif. This is as far as I know.

> 
> > understand, the packet that arrives at the realserver (encapsulated by
> > ipvs) has this format:
> >         [D|R|C|V|...payload....]
> > where, D - director address, R - realserver address, C - client address,
> > and V - VIP address. Decapsulation is done by the gif0 tunnel, after that
> > it sees that the packet is destined to itself (VIP defined at its lo0
> > interface) and processes it normally with source IP= client IP.
> > 
> 
> that's basically it. 
> 
> the packet from the client is CIP->VIP. This gets encapsulated by the director
> into a packet with DIP->RIP. Looking again, yes you seem to understand this.
> 
        I actually tried creating the tunnel in Linux way 
                (ifconfig gif0 tunnel RIP VIP ... route add...)
but it didn't work. That's when I wasn't thinking. :) So I thought about
it for a while in terms of what packet to expect, what it should do with
the packet, etc, and that's how I came about the solution above for the
OpenBSD realserver.

> > 
> 
> with 2.0 and 2.2 (maybe) linux you can use lo as the dst for tunnel
> packets and the kernel
> decapsulates the packets just fine. The later kernels are a bit more choosey
> about where the packet arrives.
>  
        Ok, I'll remember that. Thank you Mr. Mack.

Best regards,
carla

> Joe
> 
> -- 
> Joseph Mack PhD, Senior Systems Engineer, Lockheed Martin
> contractor to the National Environmental Supercomputer Center, 
> mailto:mack.joseph@xxxxxxx ph# 919-541-0007, RTP, NC, USA
> 



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