LVS
lvs-users
Google
 
Web LinuxVirtualServer.org

Re: realserver1 redirects to realserver2 :-(

To: Thomas Proell <Thomas.Proell@xxxxxxxxxx>
Subject: Re: realserver1 redirects to realserver2 :-(
Cc: lvs-users@xxxxxxxxxxxxxxxxxxxxxx, proellt@xxxxxx
From: Joseph Mack <mack@xxxxxxxxxxx>
Date: Mon, 14 Aug 2000 07:36:39 -0400 (EDT)
On Mon, 14 Aug 2000, Thomas Proell wrote:

> Hi!
> 
> > > - LVS accepting packets by transparent proxy
> > 
> > the director, realservers or both?
> 
> On both.
> 
> > > - ipfwadm to send the packets on port 80 to port 8080 (squid)
> > 
> > ipvs can only rewrite port numbers in VS-NAT mode. 
> > Tell us where the ports are being rewritten.
> 
> The IPVS (virtual server) gets the requests on port 80
> (as all http-requests) and redirects them to the realserver
> port 80. Squid is running on the realserver port 8080,
> so the packets are sent from realserver:80 to realserver:8080
> (by each realserver).
>  
> > > - arp-problem handled by setting arp-table-entry on client
> > 
> > do you mean on realserver?
> 
> ???
> No, on the test-client. Since it's just for testing (I won't
> have the arp-problem in the "real" environment) I can make
> an entry the arp-table on the client. If he wants to send
> something to 192.168.10.110, he'll find an entry in his arp-
> table with the adress of the virtual server.

if by "test-client" you mean the machine which is taking the place of the
customers out in user land... you don't have to change arp
entries on these machines.

> 
> Wait a minute - since the realserver accepts the packets by
> TP, there's no need for the entry 192.168.10.110  any more, 
> correct? At least, there's no change if I remove it :-)

right. You do have to route packets for the VIP to the director,
even though the director doesn't have the VIP on any devices.

> The client talks to the virtual server by "default route"
> then. The default route is set to the real IP of the
> virtual server, not on the VIP.

yes

> In fact, I use "tcpdump", and at least the conversation
> between client and virtual server looks o.k.
> 
> > what happens if you also allow the director to forward telnet?
> > Do you connect to one machine or each machine alternately?
 
> Hmm. There's something I don't understand. If I use TP, I
> don't really need a VIP any more, do I? I don't want to
> answer requests for a single IP (VIP), but all requests
> for all IPs should be sent to a farm on squid-caches.
> 
> Nomally, I don't need a VIP, correct?

"Normally", only if you are accepting packets by TP
 
> ifconfig doesn't indicate a VIP on the virtual server at least.

you mean on the director (the virtual server is the whole setup,
ie real-servers and director)

> ifconfig doesn't indicate a VIP on the real servers either.

correct

> ifconfig doesn't indicate a tunnelling device on the real
> servers, and that's confusing for me a bit.

confused the hell out of me too. Julian figured this one out.
I ought to know the answer off the top of my head, but I
don't. I've set this up and I think you only have to have tunneling
activated on the real-servers but no tunneling device.

> But if I call "telnet 192.168.10.110" (which is the VIP that
> seems not to exist), 

:-)

> then realserver1 answers. I didn't find
> out, if the virtual server redirected it there or if it's
> answering directly, but it's always realserver1, never
> realserver2. 
> 
> So, realserver1 always answers, it's not important if it's
> a telnet or a http-request.
> 
> Maybe it's just the arp-problem. I have to think about it.

You don't have an arp problem with TP. 
Is telnet in the ipvsadm table, pointing to both real-servers?
Is the telnet connection to the realserver dependant on having
a telnet entry in ipvsadm?

Joe

--
Joseph Mack mack@xxxxxxxxxxx



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