LVS
lvs-users
Google
 
Web LinuxVirtualServer.org

Re: lvs setup via tunelling problem

To: Djamil ESSAISSI <djamil@xxxxxxxxxxxxxxxx>
Subject: Re: lvs setup via tunelling problem
Cc: <lvs-users@xxxxxxxxxxxxxxxxxxxxxx>
From: Julian Anastasov <ja@xxxxxx>
Date: Wed, 17 Oct 2001 19:25:03 +0300 (EEST)
        Hello,

On Wed, 17 Oct 2001, Djamil ESSAISSI wrote:

> I may not have my PhD but trust me i've spent the last 20years studying alot 
> o'stuff by my self because i dont have the time to go to school so that might 
> be the reason we think differently, my point is; i'm not saying you have not 
> explained very well nor have not given me enought information but that 
> ,relatively to me, they werent expressed the way i could understand it.

        It seems I have to create troublehooting document for LVS-TUN,
there is already for NAT on my page. Then all possible problems will
be visible because as you said below the setup involves other possible
problems, not only the related to LVS settings but also a routing and
some Linux specific details.

> For example i still didnt get how is routing doing in all this since i see 
> other answers and threads using it ...

        For LVS-TUN LVS performs such routing calls (I show them with
ip command syntax):

# packet comes from CIP:

director# ip route get from CIP to VIP iif eth0 => local delivery => LVS
LVS-TUN: ip route get from 0 to RIP => send IPIP to RIP through eth0

RS: IPIP packet => through tunl0 for decapsulation
RS: IP packet => ip route get from CIP to VIP iif tunl0 => local delivery
RS: will reply: ip route get from VIP to CIP => through RS_GW
RS: arp-who has RS_GW tell VIP
RS_GW: RS_GW is-at MAC_RS_GW
RS: send reply to MAC_RS_GW

RS_GW or next gateways: can drop this packet with saddr=VIP

> Sorry for the time i wasted, yours and mine.
>
> This is an awsome project ! i'm gonna give it a last shot if it doesnt do it, 
> i'm gonna have to play with iptables and netcat ...
>
> I'll check you all out the next release, lvs will be on the top of my list 
> for a very long time.

        We saw in your tcpdumps that LVS sends the packets to the RS
and they are received there. By changing the setups you forgot to
check the main thing, whether the VIP->CIP packets leave the RS's
gateway and reach the client. Everything else is working. I don't
see a need to explain again how it is done, I already wrote it in
two emails in this thread:

rs# traceroute -n -s VIP CIP

Then check in the client whether any UDP packets from VIP are received.
So, as result, the LVS-TUN example in the web page is correct, the
main thing to check is whether the remote (RS's) ISP allows spoofing with
saddr=VIP

> :)AFontenayssB-101-2-2-157.abo.wanadoo.fr.2446 > 212.43.218.155.ssh: S
> :)1237575829:1237575829(0) win 5840 <mss 1460,sackOK,timestamp 2015288
> :)0,nop,wscale 0> (DF) (ipip)

        We already know that LVS successfully sends IPIP packets to
RIP, then RS generates the right replies to CIP. Now we don't know
whether these VIP->CIP packets are not dropped from the RS's ISP.
This is the main problem when using LVS-TUN, most of the people
assume the world is ideal and they assume these packet can reach
the client. So, what do you suspect now? Something that we already
solved?

Regards

--
Julian Anastasov <ja@xxxxxx>



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