Re: Adding SNAT support to LVS/NAT

To: "Graeme Fowler" <graeme@xxxxxxxxxxx>
Subject: Re: Adding SNAT support to LVS/NAT
Cc: "Joseph Mack NA3T" <jmack@xxxxxxxx>, lvs-devel@xxxxxxxxxxxxxxx, netdev@xxxxxxxxxxxxxxx, j.stubbs@xxxxxxxxxxxxxxx
From: "Julius Volz" <juliusv@xxxxxxxxxx>
Date: Sun, 14 Sep 2008 02:41:30 +0200
On Sat, Sep 13, 2008 at 8:55 PM, Graeme Fowler <graeme@xxxxxxxxxxx> wrote:
> Hi
> On Sat, 2008-09-13 at 11:17 -0700, Joseph Mack NA3T wrote:
>> when we've discussed it before, the packets will appear to
>> come from the DIP, a private IP (or whatever IP the servers
>> were using for their default route before they were put into
>> an LVS).
> I'm a bit late to the party, but...
> Ideally, the packets would appear to come from the "inside face" of the
> director - usually (and in the most basic case) the NIC with an address
> on the same layer 3 network as the real servers. This way the default
> route would be ignored as there would normally be a more specific route
> for that network, namely straight out of the device the packets arrived
> on. Of course, if that coincides with the default gateway address, it'll
> still work anyway.

Yes. I think this is what I meant in my previous answer to Joe.

>> more importantly, people who are bound by serious IT rules
>> setup by managers, can duplicate their (real) servers only
>> with a change in RIP on each server and can keep the default
>> route.
> This is the single most compelling thing about this setup.
> It's simultaneously a problem in that for (say) an HTTP server, all the
> requests will appear to be sourced from the director's internal address.
> For many applications this won't be acceptable, not least in that for
> the webserver case log processing will be an irrelevance!
> Anyone know how the F5 hardware gets around this? I can't get my hands
> on any to test...

Yes, this is a known issue that is usually handled by injecting
something like an X-User-IP header into the HTTP request. Hard to do
in IPVS (could be done in an app helper though, I assume).


Julius Volz - Corporate Operations - SysOps

Google Switzerland GmbH - Identification No.: CH-
To unsubscribe from this list: send the line "unsubscribe lvs-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at

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