Re: LVS-NAT - will this work?

To: " users mailing list." <lvs-users@xxxxxxxxxxxxxxxxxxxxxx>
Subject: Re: LVS-NAT - will this work?
From: John Oliver <joliver@xxxxxxxxxxxxxxx>
Date: Thu, 25 May 2006 16:52:38 -0700
In reference to:

                       |        |
                       | client |
                      |          |
                      |  ROUTER  |
             __________    |
            |          |   |   VIP=
            | director |---|   eth0=
            |__________|   |   DIP=SGW=
          |                                 |
          |                                 |
 RIP=        RIP=
   eth0=              eth0=
     ____________                      ____________
    |            |                    |            |
    | realserver |                    | realserver |
    |____________|                    |____________|

On Fri, May 19, 2006 at 04:47:46AM -0700, Joseph Mack NA3T wrote:
> On Thu, 18 May 2006, John Oliver wrote:
> >Yes, it's messy.  But I need to do something like this because there's a
> >lot more going on on this network than just the stuff I want behind an
> >LVS.  I can't help but think, though, that traffic returning from the
> >realservers would have the source IP of eth0 instead of eth0:1
> Yes.
> I assume you have two IPs on the realservers for other 
> reasons. Possibly you're adding the extra IP on eth0:x
> to setup the LVS.

I have two addresses because, as I understand it, LVS-NAT *must* be
NATed, but I do not want to NAT everything... just the web server.  It
would be very problematic to try to handle SSH, various management
agents, etc. through an unnecessary NAT.

> The reply packets will come from the IP that the service is 
> listening to. If you don't do anything special (anything 
> special = using xinetd and have the demon listen on the IP 
> of eth0:x), then the service will bind to and reply from the 
> IP on eth0. You could have the service listen to and 
> in your ipvsadm rules send to the IP on eth0:x.

What do you mean by "You could have the service listen to and in
your ipvsadm rules send to the IP on eth0:x"?  It's my understanding
that, with LVS-NAT, no special configuration (LVS-wise) is needed on the
realservers.  The HOWTO makes no mention of running ipvsadm on the

With things configured as above, a connection from the client to the VIP
just times out after 15 seconds or so.  On the director, I can connect
to port 80 of the RIPs.  But, the realservers have a default gateway
that's the same as the director... I have a feeling that responses to
requests made through the director are getting sent to the default
gateway and not the DIP.  Do I need to do something to force traffic
leaving the director to appear to be from the DIP?

FWIW, on the director, I can see InActConn incrementing as I try again
and again.  But I never see any connection in netstat on the realserver.

Here's ipvsadm on the director:

[root@quark ~]# ipvsadm
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
  -> RemoteAddress:Port           Forward Weight ActiveConn InActConn
TCP rr
  ->           Masq    1      0          1
  ->           Masq    1      0          0

Is there anything else that would return useful info in troubleshooting

> All of the early parts of the HOWTO, like you used for your 
> ascii art, were written when ethernet aliases were in use. 
> Now it would be better to use the iproute2 tools to put on 
> the two IPs. Doing it this way both IPs are primary IPs in 
> the sense that the IP you have on eth0 is a primary IP.
> In this case the ethernet aliases should work, but if you 
> can't get it to go easily, then try adding the IPs with 
> iproute2 tools (the IPs you add will be invisible to 
> ifconfig).

I've looked at iproute2, but it isn't immediately intuitive.  If
ifconfig "should" work, I'd rather keep working with something I'm
familiar with than trying to learn several things at once :-)

* John Oliver                    *
*                                                                     *

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