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 _______________________________________________ LinuxVirtualServer.org mailing list - [email protected] Send requests to [EMAIL PROTECTED] or go to http://lists.graemef.net/mailman/listinfo/lvs-users
