LVS
lvs-users
Google
 
Web LinuxVirtualServer.org

Re: Trouble setting up LVS/TUN

To: "LinuxVirtualServer.org users mailing list." <lvs-users@xxxxxxxxxxxxxxxxxxxxxx>
Subject: Re: Trouble setting up LVS/TUN
From: Joseph Mack <mack.joseph@xxxxxxx>
Date: Sat, 05 Feb 2005 18:15:09 -0500
redirecting decoy wrote:
> 
> Ok, giving it another try.
> 
> This time I am not using UML. I am trying to use 3 machines on the 
> 192.168.10.x network.
> 
> Direcotor's Real IP  (DIP):  192.168.10.100
> Client IP            (CIP):  192.168.10.44
> Real Server IP       (RIP):  192.168.10.15
> Virtual IP           (VIP):  192.168.10.111
> Default Gateway           :  192.168.10.1
> 
> Thing's I'm doing from start to finish:
> 
> On Director:
> ----------------------------------------------------------------------------------------
> Has 2 nics  eth0 (10.1.1.1)  and eth1 (192.168.10.100)

ignoring eth0 then

> 1) ifconfig eth1:0 192.168.10.111 netmask 255.255.255.255 broadcast 
> 192.168.10.111 up
> 2) ipvsadm -A -t 192.168.10.111:ssh -s wlc -p
> 3) ipvsadm -a -t 192.168.10.111:ssh -r 192.168.10.15:ssh -i -w 3
> 
> rouitng table:
> Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
> 192.168.10.0    0.0.0.0         255.255.255.0   U     0      0        0 eth1
> 169.254.0.0     0.0.0.0         255.255.0.0     U     0      0        0 eth1
> 10.0.0.0        0.0.0.0         255.0.0.0       U     0      0        0 eth0
> 224.0.0.0       0.0.0.0         240.0.0.0       U     0      0        0 eth0
> 0.0.0.0         192.168.10.1    0.0.0.0         UG    0      0        0 eth1
> 
> On Realserver:
> ----------------------------------------------------------------------------------------
> I installed the noarp module on my realserver because a) didn't want to 
> recompile whole
> kernel for hidden patch, and b) arp_announce/arp_ignore just doesn't seem to 
> work right.
> Has 1 nic eth0(192.168.10.15)
> So to setup my realserver I do this:
> 
> 1) modprobe noarp
> 2) noarpctl add 192.168.10.111 192.168.10.15
> 3) ifconfig tunl0 0 up
> 4) ifconfig tunl0 192.168.10.111 netmask 255.255.255.255 broadcast 
> 192.168.10.111 up
> 5) ip_forward = 1
> 6) tunl0/rp_filter = 0
> 
> routing table:
> Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
> 192.168.10.0    0.0.0.0         255.255.255.0   U     0      0        0 eth0
> 169.254.0.0     0.0.0.0         255.255.0.0     U     0      0        0 eth0
> 0.0.0.0         192.168.10.1    0.0.0.0         UG    0      0        0 eth0
> 
> The director and real server is now setup.
> 
> On Client:
> ----------------------------------------------------------------------------------------
> >From my client, I attempt "ssh 192.168.10.111", which immediately tells me
> "No route to host".   My ethereal output tells me:
> 
> 1) My Director receives a SYN packet from the client, nothing else.
> 2) My Real Server receives a SYN packet from VIP (the director I'm assuming)
> 3) Real server says: "Destination unreachable (host administratively 
> prohibited)" after getting
> SYN

I believe this is the same as with the UML?

There's something wrong here that has nothing to do with LVS. 
Do you have any idea why you're getting the "administratively prohibited" 
message.
I've never had that, so I don't know what it is (other than my quick search
of google). Do you have filter rules in here? wierd networkctls?

> 4) My Client just says "Destination unreachable (host administratively 
> prohibited)", 

same problem I guess.

> but it says that the source is the VIP and the destination is the CIP.  That 
> doesn't sound right...

the result is what you want. 
The client sent a packet to the VIP and it has to receive
a packet from the VIP to the CIP.

> 
> Also, from my director, if I try the command "ping -I VIP RIP", 

I assume this is a ping with source VIP, dest RIP. I can't do this
with my ping.

> it works fine so long as the
> VIP(tunl0)
> is not setup on the real server.  Is this the correct behavior ?

Possibly. I haven't done that test. The one I do is ping the VIP
from the realserver (you'll be pinging the local non-arp'ing VIP
on the realserver),  and then ping the VIP from the client. 
The client should get the director's MAC address in `arp -a` for the VIP.
Then bring down the VIP on the director and you should no longer
be able to ping the VIP.

Joe
-- 
Joseph Mack PhD, High Performance Computing & Scientific Visualization
LMIT, Supporting the EPA Research Triangle Park, NC 919-541-0007
Federal Contact - John B. Smith 919-541-1087 - smith.johnb@xxxxxxx

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