When you make changes to your network equipment or topology, you have two choices. You can just let these changes happen as the organization grows and new people are added, new wings open in the building, new buildings grow on the campus, and so forth. Or, you can plan carefully and continually review those changes. This tip, excerpted from Managing IP Networks with Cisco Routers, by Scott M. Ballew, published by O'Reilly & Associates Inc., suggests the latter course.
Too often, computer support people have come to believe that "plan" is a four-letter word. They think it is something that real computer people don't need to do, or they have been convinced that it is wasted effort. However, by carefully thinking through a change before it gets executed, many pitfalls can be identified, and, if not avoided, their impact lessened. This planning and review process need not be exhaustive, but it should be thorough. Nothing should be assumed, and the more involved the change, the more extensive and detailed the planning should be.
For example, if an important network segment is to be moved between two routers on Wednesday morning, the configuration changes should be prepared and, if possible, staged on Tuesday evening. Likewise, any cables that may need to be moved should be identified and clearly marked, and all people involved should know their role before Wednesday morning arrives. This preparation can change your routing protocol, or replace a major piece of equipment, you would probably want to prepare your configurations, and probably run many tests for days or even weeks before the time comes to make the change.
Reviewing changes also doesn't have to be a burdensome task. It can be nothing more than just having one other pair of knowledgeable eyes looking over what you propose to do. Preferable, this review should happen with as little direct prompting from the person proposing the change as possible. Instead, give a brief overview of the intended goal, and then leave the reviewer alone. Because each of you will make different assumptions about what is going on, your reviewer is more likely to spot problems if he is not prejudiced by your views.
Finally, before you make any change, be sure you have a clear idea of why you are making the change. If you don't know why the change is happening, don't make it! This is especially true of software upgrades. IF you are not upgrading your software with a goal in mind, why take the chance. Your current software is working just fine.
