(Illustration by Gaich Muramatsu)
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. JanReceived on 2003-06-02 13:29:59