ust adding a new one, but you can never rule out complications. 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 revision 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 which code release you should be running on your equipment. If you have a prob- lem after getting Cisco's OK, at least you can present your boss with an email message 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 re- booting 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 ecommerce website 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 operation be- gan. Total estimated downtime: 15 minutes. Change-control window (the time allotted for us to do the work): four hours. Actual downtime: seven hours. Appa- rently, 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 lightly. Human error If people are involved, problems are more likely. Human error, whether it's due to simple typos, fatigue, carelessness, or clumsiness, causes more failures than just about anything else. Once I sweated through three hours of a four-hour change control. The time t