a2mp@PSUORADM.CC.PDX.EDU (Michael Perrone) (05/18/91)
We are now creating a campus wide network at psu with a central router. Lots of users would like to see multiple protocol routing, but our Director is concerned with maintenance and support overhead, as well as the possibility that the network might be less stable. I would like to hear from network administrators who route multiple protocols (we have a cisco router): How much extra support and administration does multiple protocol routing add? Does multiple protocol routing make either the net or router less stable? How much extra effort is needed to add just ipx bridging and appletalk (phase 1 or 2) routing? ------------------On the FLIP SIDE------------------------- Have any of you decided to limit routing to tcp/ip, and if so, why? If you have limited routing to tcp/ip, are you using atalkad (ip tunneling) to route appletalk? How much work is that? Thanks for responses. ----------------------------------------------------------- Michael Perrone PSU Computing Services a2mp@psuoradm.cc.pdx.edu (503) 725-3112 bitnet : a2mp@psuorvm.bitnet
hedrick@athos.rutgers.edu (Charles Hedrick) (05/19/91)
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.
wicinski@bill-n-ted.esd.sgi.com (Tim Wicinski) (05/19/91)
In <May.18.21.16.18.1991.13337@athos.rutgers.edu> hedrick@athos.rutgers.edu (Charles Hedrick) writes: >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 i have 8.2 release notes, and people here run 8.2 on routers heavily in the igrp world, and they say appletalk seems more broken now than it did in 8.1. i can't say, i have the release notes, but nothing else yet. tim
s31806a@kaira.hut.fi (Peter Lindblom) (05/20/91)
In article <1991May19.084837.14525@zola.esd.sgi.com> wicinski@bill-n-ted.esd.sgi.com (Tim Wicinski) writes: > >i have 8.2 release notes, and people here run 8.2 on routers heavily in >the igrp world, and they say appletalk seems more broken now than it did >in 8.1. i can't say, i have the release notes, but nothing else yet. > I have had a little experience with appletalk and cisco 8.2 (though a beta version), and it seems like appletalk really is more broken than in 8.1. Nevertheless there is atalk phase 2 support, but there is definitely some kind of problem. Of course this might be because of beta software... Peter Lindblom | home phone intl. + 358 0 468 2725 System Analyst | office intl. + 358 0 7098 3045 internet: s31806a@kaira.hut.fi, pl@sun.sam.tele.fi
hayes@Apple.COM (Jimmy Joe Jim Bob) (05/21/91)
In article <1991May19.084837.14525@zola.esd.sgi.com> Tim Wicinski writes: > Charles Hedrick writes: > >>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 > >i have 8.2 release notes, and people here run 8.2 on routers heavily in >the igrp world, and they say appletalk seems more broken now than it did >in 8.1. i can't say, i have the release notes, but nothing else yet. > /* Taking off my Apple hat here... */ 8.2(1 thru 3) broke Atalk for a few reasons. Cisco added Phase II support, completely redesigned the AppleTalk architecture and redesigned a fair chunk of it again after its initial release. (The redesigns primarily improved routing table management on huge (more than 500 networks) AppleTalk internets, which in turn improved interfaces not covered by hardware assisted "fast-packet-switching"...) The current shipping versions have some problems, but as Chuck pointed out, the next release (8.2(4)) will fix them completely and perform much better. We've been running the new code (as a test site) for some time now, and so far, we've seen the improvements enough to entrust the new code to our factory, our product developement buildings (over FDDI) and the System 7.0 software team. Our daily network metrics number in hundreds of gigabytes per day through the routers. Hope this helps. -- Jim Hayes, Network Management Weenie Engineering Network Services, Apple Computer Inc. Inet: hayes@apple.com UUCP: {amdcad|decwrl|ames}!apple!hayes
hedrick@athos.rutgers.edu (Charles Hedrick) (05/21/91)
>i have 8.2 release notes, and people here run 8.2 on routers heavily in >the igrp world, and they say appletalk seems more broken now than it did >in 8.1. i can't say, i have the release notes, but nothing else yet. My comment applied to a second maintenance release of cisco 8.2, which I believe is not quite out yet. I agree that Appletalk support in the 8.2 initial release and first maintenance release is less than ideal. I don't remember enough about 8.1 to be able to make that comparison, but 8.2 may well be worse than 8.1.
medin@cincsac.arc.nasa.gov (Milo S. Medin) (05/21/91)
>... >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. >... Chuck, it's clear that most campuses will have to bite the bullet and support Appletalk around their facilities at some point, if there a fair number of Mac's around. But this doesn't mean all the problems with excess dynamicism that Appletalk "classic" is known for. At Ames, we have a huge number of Mac's. I think we ranked in the top 10 in total number of Mac's on site in some Mac rag's survey of large mac sites. Almost all these mac's are wired together via the campus lan, but instead of using Appletalk classic, we run a modified KIP and "static" routing via atalkad instead of RTMP and ZIP and all that running around. The campus net backbone is right now basically a huge bridged system, nearly the worst case situation for Appletalk, and things work pretty well with 70+ Kboxes and a few Gatorboxes sprinkled around the facility. No, Phase II isn't supported, and while many mac's have ethernet's in them, they use the localtalk interfaces to run Mac stuff, and use MacTCP stuff on their ethernets. One day, when we have "internal node" support for Mac's, they'll be allowed to use Appletalk via their ethernets as well. Besides, most of the applications our scientists want/need high performance for are really IP based anyways, talking to the various "real" computers around the facility and the world. All this works by and large pretty nicely, and atalkad things are taken care of by an operations type (ie not a network weenie), and centralized management lets us know who attaches to the network so we can keep track of them and make sure things keep working. If network management is important to you, you have to be able to enforce some restrictions on what the network looks like and is built out of. I realize this goes against the grain of what most appletalk types want, but sometimes you just have to put your foot down, if you need to use the net for other things. I'm not saying what we do is perfect, but it supports a huge appletalk system with little engineering labor required, and avoids the need to deal with RTMP and such. Maybe one day things will work much better and we won't have to resort to doing this sort of thing, but for now, we have to do what we can. Note if you wanted to support a lot of different vendors, your support requirements go through the roof because getting the vendors to do the right things with KIP isn't easy, but both Shiva and Cayman seem to be trying real hard to make their code work well with KIP. Thanks, Milo PS usual disclaimers apply