ssw@ogre.cica.indiana.edu (Steve Wallace) (06/19/91)
An update on our problems with the 8.2(4) upgrade.
A little background of our network might be useful. IU
Bloomington has about 50 routers, 9 AGS+ and the rest AGS, served
by several ethernet backbones. We route IP, Appletalk Phase I,
DECnet, IPX, and bridge most everything else. Well, mostly, not
all of our routers are routing all these protocols. The software
release levels range from some pre 8.0 to the 8.2(3) running in
the AGS+. Most of our AGS routers are still running 8.1(19).
About 120 local subnets are supported by these routers.
These subnets contain all sorts of devices including Appletalk
routers (ala Apple's internet router, K boxes, Gator, etc.).
Each of the devices on the local subnet is under local
administration and we do have problems from time to time with
misconfigured devices.
The picture I'm trying to paint here is one of a very
complex network with backbone routers running various versions of
code and "end users" controlling devices like K boxes. The
saving grace for Network Operations is that we own the high
ground (i.e. the backbone and routers).
The "appletalk bug" we encountered shortly after upgrading
to 8.2(4) manifested itself by causing the routers to reload.
They didn't hang or have to be cold started. In our case, having
routers down for 60 seconds is a real problem (long story about
mission critical broken TCP implementations that can't lose
packets, omitted).
After Cisco was notified of our problem, they immediately
requested all the information related to the bug and started
working on it. By Monday morning (2.5 working days later), cisco
had found the problem and provided an explanation of the cause.
The cause of the problem, what made the bug surface, was
related to our odd network configuration. We had routers running
pre 8.2(3) code on the backbone and misconfigured apple internet
routers. Basically, we were running phase II and I routers on
the same internet with misconfigured routers (hopefully Cisco
will jump in here and post the details of 8.2(4) appletalk
caveats).
I think it's important to point out that even though IU does
NOT have a support agreement with Cisco, they responded quickly
to our problem. My previous posting may have shown some
frustration with Cisco, it shouldn't have and we're not. Cisco
is the most customer driven company that I've had the pleasure of
dealing with.
Steven
--
====================================================================
Steven Wallace | wallaces@ucs.indiana.edu (internet)
Manager Network Operations | wallaces@iubacs (bitnet)
Indiana University | (812) 855 - 0960 (voice)
====================================================================