Configuring LVS TUN with new arp_tables_jf

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


Hi,

 	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 
(http://www.ultramonkey.org/3/topologies/hc=ha-lb-eg.html#real_servers).

 	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
DEVICE=lo:0
IPADDR=192.168.6.240
NETMASK=255.255.255.255
NETWORK=192.168.0.0
BROADCAST=192.168.0.255
ONBOOT=yes
NAME=loopback

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

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


NIge



Nigel Hamilton
Turbo10 Metasearch Engine

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

On Tue, 9 Aug 2005, Horms wrote:

> On Thu, Aug 04, 2005 at 07:40:01AM +0200, Ludo Stellingwerff wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> 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
> _______________________________________________
> 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
>


More information about the lvs-users mailing list