Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!bcm!dimacs.rutgers.edu!aramis.rutgers.edu!athos.rutgers.edu!hedrick From: hedrick@athos.rutgers.edu (Charles Hedrick) Newsgroups: comp.dcom.sys.cisco Subject: Re: Caution: We are having PROBLEMS with 8.2(4)!!!!!! Message-ID: Date: 21 Jun 91 05:13:10 GMT References: <1991Jun18.091614.816@arizona.edu> Organization: Rutgers Univ., New Brunswick, N.J. Lines: 50 To: leonard@arizona.edu >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.