On Sat, Sep 13, 2008 at 8:55 PM, Graeme Fowler <graeme@xxxxxxxxxxx> wrote:
> 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
> 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-020.4.028.116-1
To unsubscribe from this list: send the line "unsubscribe lvs-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html