Re: [lvs-users] ipvs and iptables :: how do they mesh together?

To: " users mailing list." <lvs-users@xxxxxxxxxxxxxxxxxxxxxx>
Subject: Re: [lvs-users] ipvs and iptables :: how do they mesh together?
From: Joseph Mack NA3T <jmack@xxxxxxxx>
Date: Sun, 23 Dec 2007 19:20:05 -0800 (PST)
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.

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 

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. 
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).

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

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