From owner-freebsd-questions Fri Sep 17 14:49:46 1999 Delivered-To: freebsd-questions@freebsd.org Received: from fedde.littleton.co.us (fedde.littleton.co.us [207.204.248.149]) by hub.freebsd.org (Postfix) with ESMTP id 5B56A14D3B for ; Fri, 17 Sep 1999 14:49:35 -0700 (PDT) (envelope-from cfedde@fedde.littleton.co.us) Received: from fedde.littleton.co.us (localhost.fedde.littleton.co.us [127.0.0.1]) by fedde.littleton.co.us (8.9.3/8.9.3) with ESMTP id PAA36738; Fri, 17 Sep 1999 15:49:05 -0600 (MDT) Message-Id: <199909172149.PAA36738@fedde.littleton.co.us> To: Mitch Collinsworth Cc: "Mark Jones" , freebsd-questions@FreeBSD.ORG From: Chris Fedde Subject: Re: multi-homed In-reply-to: Your message of "Wed, 08 Sep 1999 12:48:45 EDT." <199909081648.AA244489326@broccoli.graphics.cornell.edu> Date: Fri, 17 Sep 1999 15:49:05 -0600 Sender: owner-freebsd-questions@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Sorry to have taken so long to get back to you on this. I havent looked in this folder for some time. Mitch Collinsworth writes: +--------------- | Ok, this I didn't know and is why I phrased my initial response in the | form of a question. To allow someone who knew for sure to either confirm | or correct me. Thank you. Just out of curiosity, is there a source | for a more definitive description of "most modern TCP clients"? +--------------- It seems that I over stated the case slightly... The Host Requirements Standard (RFC 1123) states: 2.3 Applications on Multihomed hosts When the remote host is multihomed, the name-to-address translation will return a list of alternative IP addresses. As specified in Section 6.1.3.4, this list should be in order of decreasing preference. Application protocol implementations SHOULD be prepared to try multiple addresses from the list until success is obtained. More specific requirements for SMTP are given in Section 5.3.4. The problem here is the word SHOULD. In standards speek it means that the implementer may choose not to implement this. Most programmers choose not to implement MAY and SHOULD features. I set up a little test round robbin here. This demonstrates that telnet at least implements the protocol this way. $ dig +pfset=0x2020 He.fedde.littleton.co.us He.fedde.littleton.co.us. 1H IN A 10.0.0.6 He.fedde.littleton.co.us. 1H IN A 10.0.0.5 He.fedde.littleton.co.us. 1H IN A 10.0.0.4 He.fedde.littleton.co.us. 1H IN A 10.0.0.3 $ telnet He.fedde.littleton.co.us Trying 10.0.0.5... telnet: connect to address 10.0.0.5: Operation timed out telnet: connect to address 10.0.0.4: Operation timed out telnet: connect to address 10.0.0.3: Operation timed out telnet: Unable to connect to remote host: Operation timed out I tested Netscape at it appears that it does not bother to implement this behavior at all. That is a shame because it makes the network that much less reliable. But at least it does use the next address in the round robin on each subsequent click of the same url. More than once I've been blindsided by this kind of situation. For example routers MUST send an ICMP unreachable messages when they cannot forward a packet. Unfortunately clients MAY choose to use the information provided by ICMP messages. This is another example where an opportunity at robustness has been lost because of implementation expedience. Still the basic argument holds. Round robin over a diverse deployment of hosts is usually a superior configuration to concentrating resources in one site. chris __ Chris Fedde 303 773 9134 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message