Configuring LVS TUN with new arp_tables_jf

Nigel Hamilton nigel at
Tue Aug 9 09:45:39 BST 2005


 	I'm in the process of setting up LVS TUN on Red Hat Enterprise. 
I've installed the new arp_tables RPMs and am configuring the Real 
Servers. I've followed the instructions for restricting ARP advertisements 
found here 

 	The next step is to configure the "Loopback" interface. But I'm 
not sure this is the correct thing to do for LVS TUN?

 	The instructions say I should update /etc/sysconfig/network-scripts/ifcfg-lo:0

# ifcfg-lo:0

 	But now I'm stuck. Lets assume the IP of my real server is

 	* what address should I use for NETWORK? My real servers are on 
different networks? My guess is:
 	* what address should I use for the BROADCAST address? Can I just 
change the last parts of the address? My guess is:
 	* do I need to set the MTU anywhere? is 1480 correct for TUN? 
where can I set this?


Nigel Hamilton
Turbo10 Metasearch Engine

email:	nigel at					4 Ivory Wharf
tel:	+44 (0) 207 450 0221 					4 Elephant Lane
fax:	+44 (0) 207 232 4867					London SE16 4JD
________________________________________________________________________________		Search Deeper. Browse Faster.

On Tue, 9 Aug 2005, Horms wrote:

> On Thu, Aug 04, 2005 at 07:40:01AM +0200, Ludo Stellingwerff wrote:
>> Hash: SHA1
>> Horms wrote:
>>> I had a brief look over the patches and the seem ok to me. Except
>>> that I am not clear on the motivation of the following hooks.
>>> Doesn't this mean that ip_vs_in is registered in three separate
>>> places? Is this actually what you need?
>> Yes, as I try to redirect forwarded traffic (with addresses not local
>> to the director), I need to hook into NF_FORWARD. Ideally this has to
>> be a seperate ip_vs_forward_in function, but these patches are a
>> concept proof.
>> This new ip_vs_forward_in function should be limited to matching fwmarks.
>> Flow with these patches:
>> incoming packet -> PRE_ROUTING -> FORWARD -> ip_vs_in (returning
>> NF_ACCEPT, after changing skb->dst) -> POSTROUTING -> outgoing packet.
>> I'm also looking at the possibility of using the iptables REDIRECT
>> target to get rid of the forwarding hook and use the normal ip_vs_in,
>> but I'm not yet sure this will not mangle the original packet (It
>> should not loose the original destination data). At least reinject
>> should than be changed to return NF_STOLEN on the INPUT hook, and call
>> ip_forward() to get the packet on it's way again.
>> The flow for the packet will then become:
>> incoming packet -> PRE_ROUTING (REDIRECT)-> INPUT -> ip_vs_in
>> (returning NF_STOLEN, sending packet to ip_forward()) -> FORWARD ->
>> POSTROUTING -> outgoing packet.
> IF you can get that working, that would be nice.
> Though I have often wonder4ed about just moving ip_vs_in()
> to FORWARD and being done with it. I've tried it breifly
> in the past to good effect.
> --
> Horms
> _______________________________________________
> mailing list - lvs-users at
> Send requests to lvs-users-request at
> or go to

More information about the lvs-users mailing list