Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!aramis.rutgers.edu!athos.rutgers.edu!hedrick From: hedrick@athos.rutgers.edu (Charles Hedrick) Newsgroups: comp.protocols.appletalk Subject: Re: Administrative overhead of routing multiple protocols through cisco Message-ID: Date: 19 May 91 01:16:19 GMT References: <9105171831.AA22334@psuoradm.cc.pdx.edu> Organization: Rutgers Univ., New Brunswick, N.J. Lines: 46 Every protocol has overhead. Much of it is with the protocol, not the router. I.e. you have to assign addresses, names, etc., and do network monitoring. I regard tunneling and other ways to avoid multi-protocol routers as more of a support problem. The effect on router stability depends upon protocol and release. Cisco's DECnet support has been almost completely trouble-free, in all releases. We never have to put staff time in on it, and only minimal time on overall DECnet configuration and support. Novell has been close to trouble-free, and has required almost no staff time, at least in non-beta releases. However our Novell network is smaller than our Atalk network. If you want to be conservative, you might disable fast switching for Novell, though this could be paranoia. (I'm not saying it won't work, just that based on the history of the code, if Novell is going to fail, that's probably where.) Appletalk has been nothing but trouble for us. Its dynamic nature means that anybody can add a node to the network, or even a router, and the network management doesn't need to add any table entries, etct. This is advertized as an advantage, and the IP community seems to be adding similar features. I consider it a disaster, because one misconfigured KBox can cause havoc, and there's nothing to stop any random user from installing a KBox. (The same could be true of IP, of course, but it's less likely that somebody is going to create an IP subnet and add a router for it without talking to the network administration.) The reliability of cisco's Appletalk support, even in official releases (i.e not beta) has been less than ideal, though the failures don't normally impact other protocols going thru the router (except in the sense that an atalk failure may require a reboot). I think the next release of cisco 8.2 (expected imminently) will fix atalk. The most conservative approach would be to wait for a month or so after release and then ask about experiences, but I'm pretty confident. If you have lots of Macs there is probably no way to avoid routing Appletalk. Can you really afford to be unable to access printers, servers, etc., around the campus? But if you have a substantial network, expect to have a person doing Atalk support. My view of atalkad is that for a substantial network it's a bad idea, because it doesn't interact well with normal Atalk routing. If you have mostly Localtalk, and want to talk with servers that are primarily Unix machines, it might be acceptable, but I'm sceptical. Unfortunately I've just injured my hand, which means I'm not giving as many details as I usually would, because it's painful for me to type. If you need more details, I may be more forthcoming later.