|
carla quiblat wrote:
>
> Hello all,
>
> I'd just like to report that I got LVS-TUN working for a
> Linux(as director)-OpenBSD(as realserver).
OK
> 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.
>
> ifconfig tunl0 172.26.20.110 netmask 255.255.255.255 broadcast
> 172.26.20.110
> route add -host 172.26.20.110 dev tunl0
>
> Basically, I understand that the tunl0 is identified with the remote
> tunnel end (VIP) but I don't understand the "route add" part since LVS-TUN
> only implements a one-way tunnel. That is, from the director to the
> realserver, tunneling from realserver-to-director is not required and
> seems useless. The realserver routes following it's default router path
> direct to the client. So that's where I got stuck. "How do you say
> this in *BSD using the gif0 interface, the one I'm familiar with?"
so you do or don't have it working?
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?
> 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
> ifconfig lo0 _VIP netmask 255.255.255.255
>
> 10.10.8.1 is the default gateway for the private network. Notice that the
> tunnel endpoint is the DIP (not VIP like in Linux). This is because as I
> 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.
> When I do "telnet VIP" from the client, I successfully enter
> 10.10.8.199 after the login.
>
> Please comment if I'm doing anything wrong or some things I didn't
> understand. I've still a long way to go but it's working. :)
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.
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
|
