NetNews Usenet Archive 1992 #20/NN_1992_20.iso/spool/comp/protocol/appletal/3319

Internet Message Format | 1992-09-08 | 3.8 KB

Path: sparky!uunet!usc!lkimes
From: [e-mail] (Lance 'Moof' Kimes)
Newsgroups: comp.protocols.appletalk
Subject: Re: Novell servers running Internet Router
Date: 8 Sep 1992 10:17:28 -0700
Organization: University of Southern California, Los Angeles, CA
Lines: 64
Sender: [e-mail] (Lance 'Moof' Kimes)
Distribution: world
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]>
NNTP-Posting-Host: alshain.usc.edu



We finally got a REAL and HONEST answer from someone at Novell.  I applaude you.
When will the no-routing version be ready? Netware servers were about to be
tossed around here, but if you've got a solution we'll try it.

Lance Kimes
Systems Programmer
USC


In article <[e-mail]>, [e-mail] (Brian Bulkowski) writes:
|> Hi,
|> The real reason we designed it this way was two fold:
|> 1) It was a heck of a lot easier to do in the time we had with the
|> tools and source code bases we had. We had the AppleTalk router
|> from the fastpath, we had (ancient, I've heard they've cleaned it up)
|> Portable AppleTalk code from Apple. We had to mate the two together,
|> an internal net was ideal.
|> 2) To protect administrators from themselves. If AppleTalk homes on
|> a particular card, then all AppleTalk services are slave to that card
|> and network being up. By homing on an internal net, we can keep AppleTalk
|> services up as cards are bound and unbound, as configuration changes.
|>
|> Since we realize that this isn't an ideal situation, a future release
|> will include the ability to run without the router. Another configuration
|> will allow routing, but the stack will be homed on a particular interface.
|> But it was the best we could do at the time.
|>
|> WRT your feeling that the extra routers slow down a net - I don't think
|> this is a real concern, unless you run with localtalk backbones. Even with
|> 50 nets, that won't even get you three packets. Thus, for each router you
|> generate 3 packets every 10 seconds, even without split horizon. If you had
|> 10 servers on a backbone, we're talking 3 packets per second without split
|> horizon, and probably 1 packet per second with. With NBP and all your servers
|> in the same zone, things get a bit worse, since a FwdReq will be generated
|> for each server, but if you split your zones humanely you wouldn't incur
|> more than a few extra packets per lookup. With ZIP the only extra traffic
|> is when a net goes up or down.
|>
|> The main reason that we found for everyone hating "router on always"
|> was that a network number had to be assigned for each server. Thus, the
|> far flung server, under some strange administrator, had to be more closely
|> tied into the network administration. This is our main motovation for
|> moving to the no-router case. I think the other problem, that people don't
|> want extra router on their network, is based in fear of the unknown rather
|> than real technical problems. I know of a network far worse, with about
|> 50 Novell AppleTalk servers ON ONE NETWORK on ethertalk with T1 *repeaters*
|> between the ethernet segments. 1200 devices in one network. And it works,
|> mostly, and RTMP, ZIP, and NBP from the extra routers are the least of
|> their worries.
|>
|> BTW, I find the terminology of "Novell Internet Router" confusing. Any
|> router is, by Apple definition of the word, "Internet". It routes between
|> two nets. However, it confuses with the Apple Product "Apple Internet Router",
|> aka AIR. So, "AppleTalk Router" should be sufficient.
|>
|> I hope this clears up any confusion, and shows that Novell is answering
|> the demands of the marketplace in this regard. We hear you!
|>
|> BrianB
|> AppleTalk transport project lead
|> [e-mail]
|>