ssw@ogre.cica.indiana.edu (Steve Wallace) (06/17/91)
During the first week 8.2(4) was available for our AGS+ routers, we experienced two extremely bad problems. The first was resulted in all our AGS+ routers running 8.2(4) (we had upgraded 6 routers to the new code) rebooting within the course of 2 minutes. We reported the problem to cisco, stack information included, and were told that cisco was treating this problem as "catastrophic severity with extreme urgency". Cisco had yet to advise us on this problem, other than to say it appears to be an appletalk bug. We've asked cisco if we should down grade to 8.2(3), but no answer as of yet. Over the weekend we experienced the second bug. An AGS+ router (one critical to our backbone and located at our phone switch which is difficult to access on weekends) locked up. It was spewing out error message on the console and had to be cold booted. We have down graded three of our AGS+ routers to 8.2(3) and we'll continue to down grade the remaining ones. -- ==================================================================== Steven Wallace | wallaces@ucs.indiana.edu (internet) Manager Network Operations | wallaces@iubacs (bitnet) Indiana University | (812) 855 - 0960 (voice) ====================================================================
leonard@arizona.edu (06/18/91)
Has anyone else suffered severe problems with the 8.2(4) software? We've got AGS's and HyBridges, and are running TCP/IP, DECnet, bridging, Appletalk and (retch) Novell. Is there reason to believe that we would suffer if we were to upgrade to 8.2(4)? Aaron Aaron Leonard (AL104), <Leonard@Arizona.EDU> University of Arizona Telecommunications, Tucson AZ 85721
robelr@ucs.indiana.edu (Allen Robel) (06/19/91)
In article <1991Jun18.091614.816@arizona.edu> leonard@arizona.edu writes: > Is there reason to believe that we would suffer if we > were to upgrade to 8.2(4)? cisco's best guess after working with us on this (and its a pretty good one) is that the problems that we experienced were the result of one of our sites setting up a Phase II router (Apple Internet router) with a cable-range > 1 when the rest of our network is running Phase I. This is not a legal configuration, and we've since asked that site to change their router configuration. 8.2(4) appears not to handle this situation gracefully and cisco is in the process of writing a fix. If you're running a network based entirely on Phase II, you shouldn't have any problems. Granted, this was a fairly serious error, but, mindful of the caveat above, I'd still recommend 8.2(4) for Phase II nets. cisco put a lot into improving their Apple code in this release (we were a beta site) and I think that they succeeded in turning out a much better product than they started with. I know that Apple also beta tested this release and the guy there who was overseeing Apple's testing said that this release was the "finest implementation of AppleTalk he'd seen"; though he probably meant to have added "excepting Apple's" :-) I just didn't want 8.2(4) to get a bad name based on something that only one site, to my knowledge, has experienced. The problem we experienced is real, but its very limited in scope. Allen Robel robelr@mythos.ucs.indiana.edu University Computing Services ROBELR@IUJADE.BITNET Network Research & Planning voice: (812)855-7171 Indiana University FAX: (812)855-8299
hedrick@athos.rutgers.edu (Charles Hedrick) (06/21/91)
>Has anyone else suffered severe problems with the 8.2(4) >software? We've got AGS's and HyBridges, and are running >TCP/IP, DECnet, bridging, Appletalk and (retch) Novell. >Is there reason to believe that we would suffer if we >were to upgrade to 8.2(4)? It's impossible to be 100% sure about such questions, because it's always possible that a specific site could have a critical problem that only shows up there, as Indiana did. But Rutgers has a large and diverse network (with 93 Cisco routers), and 8.2(4) is a big improvement for us. We use IP, DECnet, Appletalk and Novell. We have bridging in a couple of places, but not enough that I'd claim we are a good test. For us, 8.2(4) is the most reliable release since 7.1. In the last few years Cisco has started supporting a huge number of protocols and features. Frankly, their reliability has suffered compared to the good old days when it was just IP (though maybe not if you still use just IP). I believe 8.2(4) is the first release for a while that is what I would regard as production quality. I believe 8.2(5) will include fixes for most of the minor problems in 8.2(4), and will probably be better than any of the old classic releases. Note that 8.2(4) has lots of bugs, but they are liveable and most are documented as caveats. In software this complex, bugs are inevitable. It's hard to explain this to people, but I regard the long list of known bugs as a feature. It's much better that they kept down updates during the last month of beta testing, backed out of a couple of fixes that had unintended side effects, and documented the behavior, rather than filling the thing with last-minute fixes. 8.2(5) should reduce the list of caveats. This should *not* be read as a suggestion to wait for 8.2(5), unless you are still running 6.2(105) and you can only afford to update once a decade. The only problem I've had is Novell fast-switching. We have one box (out of 93), and I've heard rumors of a second, where Novell does not work correctly when fast-switching is on. This was during beta testing of 8.2(4), but as far as I can tell, nothing relevant has been fixed between when we reported the bug and the release of 8.2(4). Fortunately, there's an easy workaround: disable novell route caching on that interface. Presumably there's something odd about the configuration of that one box, since we're not seeing problems elsewhere. I have no reason to think that this problem is new: i.e. it's probably in 8.2(1) through 8.2(3) as well. 8.2(4) is dramatically better than previous versions of 8.2 for Appletalk (except in the case Indiana reported), and probably slightly better than 8.1. Appletalk in 8.2(1) through 8.2(3) is, ..errr..., mostly functional but less than ideal. Improvements in 8.2(4) are generally minor for the other protocols.