|
On Sun, 2007-12-23 at 19:20 -0800, Joseph Mack NA3T wrote:
> On Sun, 23 Dec 2007, chris barry wrote:
>
> > Ok, sorry to reply to my own post, but is this such a stupid question,
> > that when everyone saw it, they basically said "what an idiot!" and
> > immediately deleted it? It may well be an ignorant question, and maybe
> > I /should/ already know it, but I really did google all around, and
> > could not find anything on it. The whole thing is pretty much black
> > magic to me, and I'm just trying to grok it.
>
> this is the most fundamental question about how LVS works.
> All of the behaviours of LVS depend on how/where you hook
> LVS into the netfilter tables.
>
> There is a diagram/gif by Horms in the HOWTO I'll let you
> find it.
http://www.austintek.com/LVS/LVS-HOWTO/HOWTO/images/nf-lvs.png
Got it -Thanks! And thanks for the context. It's cool seeing how people
saw a problem, and created a solution - especially one arguably as
important as LVS. An amazing achievement, and my hat is off to all of
you. I'm using it to very good effect, and I do appreciate your efforts.
Any thoughts on creating a single html file for the howto? This would
make searching it a little easier. I did read the howto, but I'm not
sure how I missed it. Being largely a string of posts, sometimes it's a
little hard to follow.
>
> Because LVS was originally riding on the coattails of the
> masquerading code (ie only LVS-NAT existed), and ip_vs()
> on the director only accepted packets for one IP, an IP to
> which a service was listening, LVS hooked into the LOCAL_IN
> chain. This required the director to have an IP=VIP. The
> director was re-routing packets for a service that was
> actually listing on an IP on a backend machine (now called
> the realserver) and the VIP only existed on the director to
> be able to flag the packets of interest to ip_vs()
>
> LVS-DR, fwmarks, LVS's with many IPs and the rewriting of
> LVS to be now be based on netfilter (late 2.2 kernels)
> rather than masquerading code, it became obvious that the
> director was only a router (but with somewhat different
> rules than a regular router), and like a router didn't need
> to have the IP of any packets that it was routing. Although
> the best choice at the time, when based on 2.0.x kernels and
> masquerading code for a service listening on an IP, in the
> new framework, LOCAL_IN was no longer a good place to hook
> LVS.
>
> Horms has written an version of LVS that hooks into
> PRE_ROUTING which seems to work OK. It is now generally
> agreed (i.e. Horms say so, and it is OK with me) that LVS
> should be in the FORWARD chain, where LVS can best look like
> a router, and the director will not need a the VIP.
This is where I had guessed it might be. Sounds like that's a whole
'nother project though... Any thoughts of merging efforts and ideas with
the netfilter guys?
> Unfortunately no-one has yet had the time to rewrite
> (and test) LVS in the FORWARD chain.
>
> So LVS could be hooked almost anywhere and you just have to
> tell the users the expected behaviours. Currently LVS is
> hooked into LOCAL_IN, which we can live with, but which is
> no longer the best place.
>
> > <...pouring more eggnog...>
>
> having my 4th cup of Chateau cardboard (Australian delicacy)
> that I found in the tax free liquor store in New Hampshire
> (USA) on the way to my holiday in Maine (I now live in USA).
Is it from Corrogata region? ;)
I hail from Ashfield, in Western MA. Ayah, a New Englandah from way
back. (now living in Philly.)
Live Free or Die! (NH State motto, and a good one)
Cheers,
-C
|
