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