|
On Tue, 12 Aug 2003, Wensong Zhang wrote:
> Well, OSPF probably cannot control the kernel of 192.65.220.98 and
> 192.65.220.99 not to do ARP response for 192.65.220.53. Please have a look
Correct. However, because all the machines in the network are
participating in the OSPF routing (not just the routers), they will all
know that the route to .53 is via .19 or .20. Any that miss this fact
don't really matter to me.
> Maybe you can run ethereal or tcpdump on the host 192.65.220.19, and see
> if it receives and sends the packet destined for 192.65.220.53.
The problem is now solved. It appears that I needed to have a .53
(fifty three) interface on the director machine. With that in place,
everything works. I'm slightly mystified by this, but I now have a
working configuration.
On a related note, I am seeing problems with keepalived deleting
services. As a test, I have configured keepalived to manage my LVS
tables, and I then took one of the real servers down. Although
keepalived reports that the server is down and that it has removed it
from the pool, and strace reveals a zero return code:
[pid 5773] send(3, "<150>Aug 13 10:13:40 Keepalived_"..., 102, 0) = 102
[pid 5773] rt_sigaction(SIGPIPE, {SIG_DFL}, NULL, 8) = 0
[pid 5773] socket(PF_INET, SOCK_RAW, IPPROTO_RAW) = 9
[pid 5773] getsockopt(9, SOL_IP, 0x481 /* IP_??? */,
"\n\0\1\0\0\20\0\0\3\0\0\0", [12]) = 0
[pid 5773] setsockopt(9, SOL_IP, 0x488 /* IP_??? */,
"\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 92) = 0
[pid 5773] close(9) = 0
in fact ipvsadm shows the `removed' machine as still being part of the
pool and attempts to connect attempt to use the `removed' machine.
ian
|
