SNAT Confusion

[Rodre Ghorashi-Zadeh]

Hello,

>
>So if the realserver is dead, it can't ask the 2nd request?
>

I think the fear is more along the lines of what if the service is dead, and 
perhaps being able to perform rolling maintenance. Also the app that I am 
trying to get load balanced, Oracle OCS, actually mentions the f5 load 
balancers SNAT mode, so I believe it is a pretty deep rooted requirement.

>
>LVS could be pure netfilter, but it would be really slow.
>
Enough said. I knew there had to be a reason, now I understand why. Out of 
curiosity do you think that this still holds true with todays hardware, gig 
nics, dual/quad core CPUs, etc?


In regards to my problem I still can't get the reply packets, once SNAT-ed, 
sent to the realserver, and sent back to the director to be accepted by the 
director and sent back to the client. I am thinking it might have some thing 
to do with some of the the /proc/sys/net/ipv4 params, anyone have any ideas? 
I am totally stumped.

~Rod

>From: Joseph Mack NA3T <jmack at wm7d.net>
>Reply-To: "LinuxVirtualServer.org users mailing list." 
><lvs-users at LinuxVirtualServer.org>
>To: "LinuxVirtualServer.org users mailing list." 
><lvs-users at LinuxVirtualServer.org>
>CC: jkrzyszt at tis.icnet.pl
>Subject: Re: SNAT Confusion
>Date: Sat, 17 Mar 2007 18:10:00 -0700 (PDT)
>
>On Sat, 17 Mar 2007, Rodre Ghorashi-Zadeh wrote:
>
>>Hello,
>>
>>For my application the first request, from the initial client on the 
>>internet, comes in as an http request and hits the VIP and gets 
>>loadbalanced via LVS-NAT as intended. The second request, from the real 
>>server, is an LDAP request that get's sent to an LVS-DR VIP to perform 
>>authentication as part of the initial client connection. I need the 2nd 
>>layer of load balancing more for high availability than for actual 
>>balancing of the load.
>
>So if the realserver is dead, it can't ask the 2nd request?
>
>>This is a requirement that I can't get around, therefore I have no choice 
>>but to face any dificulties in getting it to work. What are these 
>>difficulties?
>>
>>Also, on a side note, at the risk of sounding like I am critiquing LVS 
>>(which I am not, I have been a big fan and user for years and have 
>>implemented it over an appliance from a big name 9 times out of 10),
>
>not at all. We are well aware of many of the limitations of LVS. The one's 
>we don't know about, we'd rather hear about here, than pretend they don't 
>exist. The problem is we don't have time to fix them all. As well it would 
>be nice to have a grand overhaul of LVS, but we're not contemplating that 
>either.
>
>>I read somewhere that since LVS's inception into the mainstream Kernel 
>>that it "sit's on top of the Netfilter framework".
>
>This is mostly true if you're limited to a description of LVS in 8 words or 
>less.
>
>LVS could be pure netfilter, but it would be really slow. LVS packets then 
>do not follow all the netfilter traffic paths and rules. It's conceivable 
>that LVS could mimick (look on the outside) to follow most/all the 
>netfilter rules, but this is the overhaul that hasn't been written.
>
>Joe
>
>--
>Joseph Mack NA3T EME(B,D), FM05lw North Carolina
>jmack (at) wm7d (dot) net - azimuthal equidistant map
>generator at http://www.wm7d.net/azproj.shtml
>Homepage http://www.austintek.com/ It's GNU/Linux!
>_______________________________________________
>LinuxVirtualServer.org mailing list - lvs-users at LinuxVirtualServer.org
>Send requests to lvs-users-request at LinuxVirtualServer.org
>or go to http://www.in-addr.de/mailman/listinfo/lvs-users

_________________________________________________________________
Have Some Fresh Air Fun This March Break 
http://local.live.com/?mkt=en-ca/?v=2&cid=A6D6BDB4586E357F!147