LVS
lvs-users
Google
 
Web LinuxVirtualServer.org

Re: hidding loopback interface does not work properly

To: "LinuxVirtualServer.org users mailing list." <lvs-users@xxxxxxxxxxxxxxxxxxxxxx>
Subject: Re: hidding loopback interface does not work properly
From: "John Barrett" <jbarrett@xxxxxx>
Date: Wed, 29 Oct 2003 04:33:46 -0500
Let me rephrase one statement:
Having the VIP hidden on the lo interface of a director is failing because
lo doesnt have a mac
address, and direct routing works by rewriting mac addresses. (or does it -- 
could you assign an IP to the lo at startup and use that as a realserver
address in the LD config ??)

----- Original Message ----- 
From: "John Barrett" <jbarrett@xxxxxx>
To: "LinuxVirtualServer.org users mailing list."
<lvs-users@xxxxxxxxxxxxxxxxxxxxxx>
Sent: Wednesday, October 29, 2003 4:20 AM
Subject: Re: hidding loopback interface does not work properly


> I'm a relative LVS newbie -- so feel free to shoot me down if I missed
> something :)
>
> Having the VIP on the lo interface is failing because lo doesnt have a mac
> address, and direct routing works by rewriting mac addresses.
>
> If you are using heartbeat+ldirector with HB launching LD, ldirector isnt
> running on any machine that is not currently handling the VIP. So asking
if
> "ldirector is available" doesnt make a lot of sense -- if the machine is
up
> at all (easily determined by opening any known active port on the DIP,
such
> as ssh, or even just ping the DIP), then technically "ldirector is
> available", but may not be active at the moment if another machine is
> currently handling the VIP
>
> What might be more useful is to have each HB+LD system run a local server
> that identifies the system, perhaps by setting up a private address on lo
> (192.168.1.1 will do, and you can use the same IP on all the hb+ld
> machines), then binding the server to that address -- configure LD to
route
> a port to that ip using NAT. Since the NAT address is handled locally,
each
> HB+LD system will use its local server to answer requests. Return the
> hostname as part of the response and you can identify which HB+LD is
> currently active.
>
> To answer your question about hiding: the typical realserver (without
hb+ld)
> has the VIP hidden on lo so that the realserver will not answer VIP arp
> requests from any eth* interfaces -- the hb+ld machine currently handling
> the VIP should be the only machine answering VIP arp requests. When
traffic
> for the VIP arrives, the director rewrites the mac address, forwarding the
> traffic to the mac address associated with one of the RIPs, kernel routing
> code at the realserver then routes the traffic internally by IP, which
> passes the traffic off to the VIP on lo.
>
> ----- Original Message ----- 
> From: <frederic.buche@xxxxxxxxxx
> To: "LinuxVirtualServer.org users mailing list."
> <lvs-users@xxxxxxxxxxxxxxxxxxxxxx>
> Sent: Wednesday, October 29, 2003 2:54 AM
> Subject: Re: hidding loopback interface does not work properly
>
>
> OK Joe, I am going to explain what I need :
>
> I have already implemented LVS by Direct Routing. And it is working well.
> I have 2 Linux Director connected by HeartBeat, which can detect all
> hardware troubles.
>
> I have an application called "Pollux" wich is a part of our monitoring
> system.
> Pollux just make polling on different port and send traps on the Hp
> OpenView.
>
> What I need is detect if the first Director is not available.
> To do that, I have planed to setup a RealServer on the same machine as the
> Director.
> I will test the LVS function by polling the VIP of this Realserver.
>
> So I have an apache server running wich answers only to requests received
> on the VIP address.
> I have to set up the VIP on an interface like eth0:1.
> But I need as well to configure a loopback interface with the same ip
> address. (for the Realserver)
> This loopback interface (lo:0) has the hidden parameter set.
>
> eth0 = 192.168.121.240
> eth0:1 = 192.168.121.242
> lo:0 = 192.168.121.242
>
> If the interface eth0:1 is not mounted I would expected that a ping on
> 192.168.121.242 do not reply.
> But it does.
>
> Perhaps I do not have understood exactly the purpose of "hidding", but I
> thought this architecture coud work.
>
>
> Frédéric BUCHE
> _______________________________________________
> LinuxVirtualServer.org mailing list - lvs-users@xxxxxxxxxxxxxxxxxxxxxx
> Send requests to lvs-users-request@xxxxxxxxxxxxxxxxxxxxxx
> or go to http://www.in-addr.de/mailman/listinfo/lvs-users
>
> _______________________________________________
> LinuxVirtualServer.org mailing list - lvs-users@xxxxxxxxxxxxxxxxxxxxxx
> Send requests to lvs-users-request@xxxxxxxxxxxxxxxxxxxxxx
> or go to http://www.in-addr.de/mailman/listinfo/lvs-users

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