Re: [PATCH] Runtime interception method switch

To: Simon Horman <horms@xxxxxxxxxxxx>
Subject: Re: [PATCH] Runtime interception method switch
Cc: LVS Devel <lvs-devel@xxxxxxxxxxxxxxx>, Janusz Krzysztofik <jkrzyszt@xxxxxxxxxxxx>
From: Joseph Mack NA3T <jmack@xxxxxxxx>
Date: Wed, 16 Jan 2008 07:09:26 -0800 (PST)
On Wed, 16 Jan 2008, Simon Horman wrote:

For starters could we clarify that the patch in question is the following one by Janusz Krzysztofik?

I see Janusz has replied to this.

I had assumed that if Raphael could output the packets to the right spot (before POSTROUTING on the inbound direction?) that iptables could handle the NAT'ing and no extra ipvs code would be neccessary.

What I didn't know was the original reason the packets were output to a place where iptables couldn't manipulate them. Was this for speed? to get ipvs to work at all? If for speed, the director has always been limited by wirespeed, not by anything in ipvs, so any increase in latency through ipvs may not be seen.

Also can I clarify that the aim is to be able to SNAT LVS-DR

I didn't realise Janusz was SNAT'ing LVS-DR.

(and if possible LVS-NAT and LVS-TUN)?
Or is the aim to add a new method, LVS-FULL-NAT?

What the users want is to be able to put unmodified servers behind a director - they can't even change the default gw. The only thing they can change is the RIP. So the servers would have to be realservers behind an LVS-NAT director which is outputting packets with src_addr=DIP, ie the realservers see connect requests only from the DIP. I'd assumed the director would be running a new version of standard LVS-NAT, with iptables doing the SNAT in POSTROUTING.

Joseph Mack NA3T EME(B,D), FM05lw North Carolina
jmack (at) wm7d (dot) net - azimuthal equidistant map
generator at
Homepage It's GNU/Linux!
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>