|
> OK. You have a client on the local net, where your "external" interfaces are
> (for d1 and d2).
> Indeed there is no router involved. Client consults its ARP table, and sends
> Ethernet packets to MAC address found therein.
>
> However: you must make sure, that the client's ARP table is updated when
> you fail over. ( The GARP must be sent out to the external net as well!)
> this way the client knows where to send the packets.
The client's ARP table appears to be correct both before and after
failover.
> You may want to try traceroute-ing from the client to the VIP in both
> pre-and
> post failover, to see where your traffic is blocked.
>
I can ping and traceroute all VIP's correctly. traceroute makes one hop
directly to D1 or D2, whichever is active. The default route on the
client is the router to the outside world. D1 and D2 are on the same net
as the client so the default route isn't getting used at all between the
client and the director.
> The client may be sending its traffic to D1 because its default route is set
> to that.
> This default IP may be another IP (not one of the VIP-s) and possibly you do
> not
> re-map this when you fail over. Traceroute will tell you what's the clients
> notion
> of the packet's destination is.
>
According to traceroute the client is sending packets to the correct
destination. When failover occurs D2 acquires ALL IP's from D1. Every
single IP that was on D1 is now pingable on D2 from both the client and
the real servers. I can connect to the real servers from D2 with no
problems at all. I can ssh to D2 from the client with no problems. This
works for any of the external IP's on D2.
The ARP tables must be correct or the ssh packets wouldn't get to the
correct destination, right?
If I set up a virtual service for port 22 I can't connect to the real
servers. The connection hangs just like the web connection does for the
VIP's. I can see the ssh connection on D2, but I can't see the connection
on the real server. Here's the output from ipvsadm -l:
IP Virtual Server version 0.9.15 (size=4096)
Prot LocalAddress:Port Scheduler Flags
-> RemoteAddress:Port Forward Weight ActiveConn InActConn
TCP 63.86.125.54:ssh rr
-> 192.168.0.100:ssh Masq 1 0 0
TCP 63.86.125.47:www wrr
-> 192.168.0.100:www Masq 1 0 0
D2 can ping both the client and the real servers, but it can't seem to
establish a connection between them. Is it possible that the real servers
are getting confused because the default route is changing machines even
though the ARP tables have the correct info?
Brad Benson
|
