or vendors do a good job of version control and beta testing, there are plenty of bugs listed on any vendor's site to prove my point. What about upgrading something like memory? Easy enough, right? It might be as simple as swapping out a DRAM SIMM or even just adding a new one, but you can never rule out complications. Chapter 38: Avoiding Frustration The Dangers of Upgrading Here are some reasons to be wary about upgrading: Introduction of new bugs Upgrading might resolve the bug that's causing you grief, but the new code revi- sion might have another bug you didn't know about. The best way to prevent this is through due diligence. Cisco can help you cross-reference bug lists and determine what code release you should be running on your equipment. If you have a problem after getting Cisco's OK, at least you can present your boss with an email from Cisco recommending the change. Beats saying, "Wow, I should have checked into that!" Hardware problems Upgrading a network device is not necessarily hard work, but it does involve rebooting the device in most cases. Rebooting is (hopefully) something that does not happen often, and there's always room for error and unforeseen disasters. I once observed a simple upgrade of memory for a major e-commerce web site that went horribly wrong. A new SIMM was swapped with an old SIMM in a 6506 chassis switch. The change-control request was approved, and the opera- tion began. Total estimated downtime: 15 minutes. Change-control window (the time allotted for us to do the work): four hours. Actual downtime: seven hours. Apparently, a small chunk of dust landed in the memory socket when we pulled out the old SIMM. When the new SIMM was installed, the dust bunny got mashed into the socket, preventing the SIMM from contacting all the pins. Reseating the chip didn't resolve the problem. Backing out the change didn't solve the problem either because the old chip used the same socket. The moral: any hardware change should be considered a major change, and should not be undertaken light