re: 2 or more MacIP Servers is one zone?
Tom Evans <tom@wcc.oz.au> Tue, 27 April 1993 11:05 UTC
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00729; 27 Apr 93 7:05 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id ac00717; 27 Apr 93 7:05 EDT
Received: from cayman.cayman.com by CNRI.Reston.VA.US id aa01408; 27 Apr 93 5:03 EDT
Received: by cayman.Cayman.COM (4.1/SMI-4.0) id AA29988; Tue, 27 Apr 93 03:27:38 EDT
Return-Path: <tom@wcc.oz.au>
Received: from munnari.oz.au by cayman.Cayman.COM (4.1/SMI-4.0) id AA29984; Tue, 27 Apr 93 03:27:27 EDT
Received: from wcc.oz by munnari.oz.au with SunIII (5.83--+1.3.1+0.50) id AA13008; Tue, 27 Apr 1993 17:26:35 +1000 (from tom@wcc.oz.au)
Message-Id: <9304270726.13008@munnari.oz.au>
Date: Tue, 27 Apr 1993 15:23:47 +1000
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Tom Evans <tom@wcc.oz.au>
To: apple-ip@cayman.com, bnr.ca@munnari, asc.slb.com@munnari.oz.au
MMDF-Warning: Parse error in original version of preceding line at CNRI.Reston.VA.US
Subject: re: 2 or more MacIP Servers is one zone?
Date: 27-Apr-93 To: Apple-IP Mailing List From: Tom Evans Re: re: 2 or more MacIP Servers is one zone? Cc: bschmidt@bnr.ca@munnari strick@asc.slb.com@munnari Cc: Chris Ranch "Ben (B.T.) Schmidt" <bschmidt@bnr.ca> writes: > In message " 2 or more MacIP Servers is one zone?", > 'strick@asc.slb.com' writes: > > > If I have two MacIP servers in the same zone, what rules determine > > which one servers me each time I connect to the net and request an > > address via 'Server' MacTCP? It depends. On everything. :-) In practice, assuming your setup works (with two MacIP gateways in the one zone), then the answer is either (1 )"the fastest", (2) "this one" or (3) "the other one". MacTCP is only "expecting" one response, and thus only specifies "one response" in the call to NBP. It will thus only see the first response returned to the Macintosh. (1) The Fastest. Under some network configurations, the winner will be "the fastest one to respond". This will only happen if the two gateways are an equal number of hops away from the Macintosh (usually both one hop or both two hops). If the two gateways are on the same LocalTalk network as the Macintosh, then it depends on which one the Macintosh sends the request packet to (and what the gateway then does - see (2) and (3)). Normally though, I would expect the Macintosh to be connected via LocalTalk to MacIP Gateway "A", and that there is another MacIP Gateway "B" that is in the same zone, but not on the same LocalTalk network (usually connected to the Ethernet backbone). If "B" is a FastPath, then it may be set up to only answer IPGATEWAY requests from Macintoshes on its own LocalTalk network, so it will never answer requests from the first Macintosh. In this case you have more than one MacIP gateway per zone, but only one will ever respond. (2) This One For the Webster MPG in the above case, "B" has to be set up for "MacIP on EtherTalk" in order to respond to the first Macintosh. However, "A" will always "win" as it uses "out-of-order-NBP" to answer the Macs request before forwarding it to other networks, so in this case the answer is "A". (3) The Other One If MacIP Gateway "A" receives the NBP BrRq from the Macintosh and "explodes" the BrRq into LkUps for all networks in the zone before answering the request itself, then it is possible that "B" will respond before "A" finishes sending out all the invitations. > I'd love to do this for fault-tolerance, but both my vendor of MacIP gateways > (cisco) and Tom Evan[s'] 16/March/1992 version of "Network Area Internet > Draft, MacIP - IP Transport over AppleTalk", warn that this is highly > implementation-dependent, and that this path invariably leads to the > "Dark Side". It isn't that bad in practice. All vendors make MacIP gateways that work, using one method or another (even if the "method" is "don't do it" :-). There's no controlling standard that everybody must adhere to, so there's no "guarantee" of multi-vendor interoperability. There's a good chance that what you put together will work. If it doesn't, one of your vendors will probably be able to suggest a rearrangement of your network (or may even supply new code) to fix it MacIP is complex, baroque and badly misunderstood. In the MacIP document we attempt to first explain "MacIP-1" as a basis for understanding, and then go on to describe a minimum set of "modifications" required for multi-gateway-in-zone operation. The document isn't finished yet. The "dark-side" comments are meant to be there to get your attention, and possibly your interest; to underline the fact that this protocol is misunderstood and isn't "simple". Have I been taking the wrong approach here (I guess so)? The only way to "guarantee" that a multivendor MacIP setup will work is not to "encroach" upon the "dark areas" too much. There's no "standard" for the Macintosh-end programs either. In trying to write the document, I send out a survey on this newsgroup to try and get this information so I could write a specification that would work with existing host-end implementation so I could write a specification that would work with them. I RECEIVED ONLY ONE RESPONSE (thank you Steve Ethier at Novell). I still have no idea how MacTCP really treats MacIP. >From section 4.8, Gateway NBP Proxy ARP, of the above doc: > >This results in the restriction that with MacIP-1 there must never be multiple >MacIP gateways in the one zone configured with different MacIP Ranges, as they >will defeat registration attempts by MacIP hosts that have been assigned >addresses by the other gateway. Then again, [no t?]wo MacIP gateways [can?] >can't be configured with the same MacIP range as normal IP routing (Routing >case) and Proxy ARP (Forwarding case) would fail. Therefore there can't be >more than one MacIP gateway in any one zone. This is the "Multiple Gateways >in the One Zone" problems, and will be addressed later. My phrasing is bad. Let's see if I can explain it better. "MacIP-1" gateways don't exist (*). All (most? some? I don't know) vendors handle this problem somehow. The above paragraph is attempting to explain what the "multiple gateways" problem is in the following steps: 1. MacIP-1 gateways respond to all IPADDRESS LkUps that aren't in their MacIP Range. 2. Therefore, two MacIP-1 gateways in the one zone with different MacIP Ranges will interfere with each other. 3. AHA! (says an astute reader). "I can fix this by configuring them with the SAME MacIP range and overcome the problem!" 4. Wrong, MacIP neophyte. That will cause IP Routing and Proxy ARP to fail. This is how MacIP "hacks" get started. :-) 5. Therefore proving the general case that there can't be more than one MacIP-1 gateway in any one zone. > Section 5.1, Multiple Gateways in One zone, then goes on to describe various > "MGOZ-Hacks", none of which my vendor will so far own up to. :) So I'm > (unnecessarily?) playing it safe for now with only one MacIP Gateway/zone. (*) Maybe MacIP-1 gateways do exist. I've just read the MacIP section of their manual, and it looks like they mean it when they say "only one MacIP server per zone". You can always break this rule and see what happens. ======================== Tom Evans tom@wcc.oz.au Webster Computer Corp P/L, 1270 Ferntree Gully Rd Scoresby, Melbourne 3179 Victoria, Australia 61-3-764-1100 FAX ...764-1179 A.C.N. 004 818 455
- 2 or more MacIP Servers is one zone? Don W Strickland, Schlumberger, Austin
- re: 2 or more MacIP Servers is one zone? Ben (B.T.) Schmidt
- re: 2 or more MacIP Servers is one zone? Tom Evans