|
> No, I didn't mean that. I mean that in the VS-NAT mode, response
> packets from your "daisy" box to the "fred" box must go through your
> "virtip" box, so that the load balancer have chance to rewrite the
> source of the response packets back to the virtip.
>
> Since you said that the default route of your "daisy" box was set to
> the "virtip" box, it is good, but please check if there is another
> route that the "daisy" is directly connected to your "fred" box, which
> will break connection.
In fact, there is. But daisy's routing table does not show it.
But just in case, I added a rule to the other (Linux) router with ipchains...
Chain input (policy ACCEPT):
target prot opt source destination ports
DENY all ------ daisy anywhere n/a
There is no other route from daisy to fred.
I think this assures that the return packets don't go that way. There is
no other route, and when I add the same rule to the virtip box, a ping
from fred to daisy stops working, confirming that the technique is valid.
Yet the packet trace still shows the response packets marked with source
of daisy on eth1!
So it seems that the packets are really returning via the VS box, yet
the source IP is not being rewritten. Perhaps I configured it incorrectly
by using a virtual IP that is different from elmo, the usual external
address?
Or maybe the code requires that the virtip be on the same ethernet as the
real server? Can this be used on a dual-homed box as I am doing? Sorry
for the speculation - I haven't been ambitious enough to read the code,
but if you'll point me at the right place, I'll assume the burden! I
appreciate your help.
Regards,
Bill
|
