Topology of ultramonkey...

"liran tal" <[email protected]> Wed, 22 Nov 2006 16:37:46 +0200
Newsgroups gmane.linux.highavailability.ultramonkey
Message-ID <[email protected]>
Hey guys,

I'm trying to setup ultramonkey (basically just load balancing currently, no
heartbeat required,
so I guess we're talking about ldirectord only...) in a somewhat different
topology as shown in the website:

the vip load balancer:
host lb1 has ip addresses: 192.168.0.20 on eth0 and 192.168.0.105 on eth0:0
(.105 is the vip)
the default gateway for lb1 is 192.168.0.5 which is a linux-based router
with 2 nics.
(by the way, a quick question: to which ip does the hostname lb1 suppose to
resolve to? to 192.168.0.105 the vip?)

the router:
1 nic for WAN interface is 192.168.0.0/24
1 nic for LAN interface is 10.107.0.0/24

the real server (running apache for the sake of experiement):
has ip address 10.107.0.163 on eth0
has default gw of 192.168.0.5 which is the router.

the topology used is lvs/dr as you can see.

the problems i've encountered:
1. when the real server DOESN'T have an alias interface of say eth0:0 with
ip address 192.168.0.105/32 then there is ping communication
between lb1 and the real server and i see on the logs that ldirectord adds
the real server with weight 1 as it detects it is alive although when trying
to access 192.168.0.105 from the WAN network (from the 192.168.0.0/24)
nothing happens
(i'm assuming it's because the real server doesn't have an alias interface
configured with the vip address).

in continuation to 1:
2. so when i configure an aliased interface of eth0:0 with ip address
192.168.0.105 and netmask 32 (255.255.255.255) there is no ping
communication now
between lb1 and the real server cause when i ping from lb1 to the real
server i see on the real server with ethereal that the source ip of the ping
is 192.168.0.105
so it doesnt reply back cause it's thinking it is replying to itself since
it has that ip address on the aliased interface.


by the way no action was taken regarding to arp issues...
any thoughts of this issue are most welcome,

thanks,
liran.