Ldirectord realserver connection refused LVS-TUN
niraj at vipana.com
Tue Dec 12 20:39:28 GMT 2006
I saw that part but then how does ldirectord make its negotiation checks?
Does this also mean that you *MUST* run iptables in order to have
LVS-TUN work with failover and still have the flexibility of using
I'm using ldirectord 1.186, ipvsadm 1.24 and heartbeat 2.0.5 on kernel
Joseph Mack NA3T wrote:
> On Tue, 12 Dec 2006, Niraj Patel wrote:
>> Hello all,
>> Client machines (both on the same subnet and not) are able to access
>> the cluster using firefox, lynx, wget and telnet (ports 80 and 443).
>> However, when trying the same from the directors themselves, I get
>> connection refused.
<original post> -- adding because it didn't make it to HA list the first
I'm trying to run an LVS-TUN setup with heartbeat for an apache cluster.
Client machines (both on the same subnet and not) are able to access the
cluster using firefox, lynx, wget and telnet (ports 80 and 443).
However, when trying the same from the directors themselves, I get
connection refused. All machines (directors and realservers) are on the
same subnet. Arp tables are showing the correct MAC also.
I'm cross-posting here to both LVS and HA lists, but I'm assuming it's
not an ldirectord config issue because I can get to apache using various
methods, just not from the directors themselves. However, ldirectord
runs on the directors and keeps making the realservers quiescent since
the checks are failing. If I don't run ldirectord, things work, but
without it, what's the point?
The VIP's are all aliased off of eth0 or eth1 using IPaddr2. Even
after a successful failover, the other director exhibits the same
issues. Using kernel 2.6.16. In desperation, I also tried adding a
route to the VIP on the director but having a route back to the same
interface didn't help one bit.
However, one weird thing I noticed after running IPaddr2 was that the
VIP shows up using ip addr, but not ifconfig. I have no idea why this
might be the case.
haresources has the line: IPaddr2::172.16.0.10/24/eth1/172.16.0.255
(I also tried 32 but that didn't work either).
Any ideas? Any pointers would be highly appreciated.
Thanks and regards.
More information about the lvs-users