On Sun, Jun 01, 2003 at 07:17:35AM -0400, UpFront Technology wrote:
> Hello,
> 
> 	I am a small web developer intrigued by CODA's functionality.  I
> 	currently host sites I design and like Brett Lymn (Nice article
> 	in Sys Admin, BTW), I plan to try CODA to replicate to multiple
> 	web servers for fail over purposes.

I can't really figure out the description of your problem. The image
isn't helping. I tried to look at it with different tabstop settings.

> "http://www.coda.cs.cmu.edu/maillists/codalist/codalist-2002/4771.html"
> regarding Problems connecting to svm: RTP2_NOTCLIENT
> 
>  I took down 10.0.0.9 (eth1) and all works fine.  It seems to be a problem
> with the server replying back on the wrong (multiple) interface.  The above
> article finishes up by saying "Actually, the server is listening on all
> interfaces. And indeed, after pointing the client to the internal interface
> instead of the external, the mounting succeeded.

Why would it be replying on the 'wrong' interface? When the server
receives a packet, it get's the address of the sending host along with
the packet, this is the address of the outgoing interface on the client.
It then sends the reply to that address, and assumes that the routing
table is set up to send the reply out from the correct interface. I
guess it goes out on the wrong interface, and is as such given a
different address, the client ofcourse drops the packet.

I guess we have the following situation,

10.0.0.5 wants to talk to a server at 10.0.0.2 and sends a packet to
10.0.0.2, which is received by the server on eth0. Server sends the
reply back, however the routing table tells it that it has to (can) use
eth1, and the outgoing packet is 'stamped' as coming from 10.0.0.9.

Now look at this from the perspective of the client. It sends a request
to 10.0.0.2 and then receives some stray packet from a machine with
address 10.0.0.9, which is a perfectly logical thing to do.

To get this kind of multi-homing setup working entirely correctly
requires opening a separate socket for each interface and doing some
of the routing in RPC2. It also becomes increasingly more difficult when
you consider network topology changes, interfaces disappearing and
re-appearing or simply route changes which typically happen when mobile
clients are moving around.

The only solution right now is to bind the server explicitly to a single
ip-address on your multi-homed machine. There should be a server_ip
options in server.conf for that.

In the long term, we might be able to decouple the existing 1:1
relationship between a server and it's ip-address. This way a client
should be less surprised about receiving the response from 10.0.0.9 as
long as gethostbyaddr returned that as one of the usable addresses for
our peer.

Jan