[KLUG Members] Ultramonkey/ LVS / Network wackiness

[Adam Bultman]

It's Friday. It is almost the weekend. My mind is obviously elsewhere.  
And I can't figure out this network problem.

Background:
I'm using ultramonkey on Red hat 7.3  machines to load balance web 
connections to  a fedora core 1 system. They are blade servers, and they 
each have network setups like this:
eth0: 192.168.202.x
eth1: 10.88.0.x (netmask 255.255.0.0)
eth2: 10.0.0.x (netmask 255.255.255.0) (management, no wires involved)

 My load balancers balance the connections for web servers, which site 
on the same internal network. The web connections are NATted and each 
server sits on a 192.168.202.x network.


Because each site takes up 5 ip addresses, I'm running out of room, and 
I want to expand that.  So, I'm using eth1's new network (set up 
recently) to act as a way of increasing the number of IPs I have to 
use.  I'm starting off by assigning 10.88.1.x to a two servers and 
seeing if they can  talk to each other. So far, most of them can.


Issue 1:
One of my servers keeps 'stealing' ip addresses.  If you say, assign it 
an ip address:  10.88.0.15 and a virtual of 10.88.1.2; and you restart 
the eth1 interface on another server, the first server 'steals' the ip 
address.  It says,
"Error, some other host already uses address 10.88.0.2", and the 
10.88.0.15 server is stealing it.   SSH to that ip, and sure enough... 
the first server stole it.    I don't understand what it is doing at all.

Issue 2:
I don't know if Issue 1 is affecting this, or if it is routing, but it 
would appear that the load balancers aren't happy with my using 
10.88.x.x, because it *should* be balancing and sending data to the 
other systems - the load balancers are definately connected to the test 
server on eth1.  It seems like they can't always ping each other on the 
eth1 interface, and it would appear that the 'greedy' server is the one 
with connectivity problems.
  Regardless: in ldirector.cf, I've got:


#nonsecure
virtual=192.168.202.160:80
        real=10.88.1.1->10.88.1.5:80  gate
        service=http
         request="index.html"
        receive="it worked"

#secure
virtual=192.168.202.160:443
        real=10.88.1.1->10.88.1.5:443  gate
        service=https
        checktype=connect
        persistent=600


It looks correct to me, but perhaps trying to connect to a wierd server 
is causing me issues.  But let me know if there are problems there... 
I'm not MASQing the connections, so I don't know what else I'd use 
besides 'gate'.

Any help = swell.

Adam