To: "'lvs-users@xxxxxxxxxxxxxxxxxxxxxx'" <lvs-users@xxxxxxxxxxxxxxxxxxxxxx>
Subject: RE: KTCPVS
Cc: "'alexandre.cassen@xxxxxxxxxxxxxx'" <alexandre.cassen@xxxxxxxxxxxxxx>
From: Jimmy Yeung <JYeung@xxxxxxxxxx>
Date: Tue, 26 Mar 2002 10:34:57 -0500

Thanks for your feedback Alexandre.
Company I work for want to test the scalability of our server application ... which means we want to get away from buying any hardware (e.g. BigIP) ... instead, we wanna simulate through it (BigIP) with one PC.

Just wondering, what if ...
I will have the client hit the apache server directly and apache will terminate the SSL right there (in order to use same certificate for all request since client sees only 1 IP - VIP ... and don't know anything about the real server(s) behind).  Then, apache will redirect the request to KTCPVS (which listening on another virtual IP on the same box).  KTCPVS will then do the load balancing to different real servers.  In this case, KTCPVS will handle it as HTTP as ususal.  Does this works?  Does KTCPVS do "pinning" (if I use the right term) for return the request ... since KTCPVS will see the same IP (apache's IP) as client request coming in all the time?

Another thing though ... I think the apache loads modules in sequence.  The "rewrite URL" module will load before the "ssl" module, so it will actually redirect request by rewriting the URL without terminating SSL.  Is it true?

-----Original Message-----
From: Alexandre CASSEN [mailto:alexandre.cassen@xxxxxxxxxxxxxx]
Sent: Tuesday, March 26, 2002 3:19 AM
To: lvs-users@xxxxxxxxxxxxxxxxxxxxxx
Subject: Re: KTCPVS

Hi Jimmy,

>Can anyone tell me if the following will work?  I know it may defeat the
whole purpose of load balance at layer 4, but I just need something to
simulate >BigIP kinda stuffs.
>Client -> SSL -> KTCPVS -> Apache (which terminate SSL by listen 2 virtual
IP) -> Real Servers

KTCPVS operate at layer7. So it consist of a socket pair used to forward
stream between remote client and scheduled realserver. The application
listener is first located to the director which is the connection acceptor.
So if you want to accept SSL connection directly on the KTCPVS box, this
protocol need to be implemented into the KTCPVS code. Currently KTCPVS only
support HTTP listener forwarding stream.

A strict/typic layer7 switching env is : client -> SSL -> KTCPVS ->
Realservers (HTTP protocol) => SSL is handled by director. Adding SSL
support to KTCPVS is adding SSL support into the kernel which is a hard

So in short the setup you describe will not work properly.

>KTCPVS & Apache (with 2 virtual IP) are in the same physical linux box.  I
understand that same certificate needs to be used for both virtual IP of
the apache.

hmm.. a SSL certificates in a loadbalancing env must be registered with the
Common Name of the VIP DNS entry... This is the only need...

>Once I add the KTCPVS patch to existing LVS patched kernel source ... then
compile it.  Is that mean this new compiled kernel can only do >KTCPVS?  Is
it configurable between KTCPVS & LVS? ... without using 2 different kernels
by selecting from LILO?

KTCPVS is a kernel module. So no need to rebuild your kernel simply compile
the KTCPVS modules and load then into the kernel. Currently there is no
communication between LVS & KTCPVS.

This is probably the final goal of Wensong :)

Best regards,

_______________________________________________ mailing list - lvs-users@xxxxxxxxxxxxxxxxxxxxxx
Send requests to lvs-users-request@xxxxxxxxxxxxxxxxxxxxxx
or go to

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