Plan and review changes

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

Requires Free Membership to View

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.

This was first published in April 2002

There are Comments. Add yours.

TIP: Want to include a code block in your comment? Use <pre> or <code> tags around the desired text. Ex: <code>insert code</code>

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
Sort by: OldestNewest

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

Disclaimer: Our Tips Exchange is a forum for you to share technical advice and expertise with your peers and to learn from other enterprise IT professionals. TechTarget provides the infrastructure to facilitate this sharing of information. However, we cannot guarantee the accuracy or validity of the material submitted. You agree that your use of the Ask The Expert services and your reliance on any questions, answers, information or other materials received through this Web site is at your own risk.