- Planning a Logical Network Design
- Planning and Design Components
- The Physical Network
- Planning Resources
This chapter is from the book
This chapter is from the book
This chapter is from the book
Planning and Design Components
When it is time to create a plan, what should the product of this effort be? Depending on the scope of the project, the end result might be a simple short document with a step-by-step checklist for adding a few network devices to the network to segment traffic. As the scope grows larger, so do the receivables that should be prepared for upper management as part of the plan. Some of the things you might want to consider including are listed here:
- Documentation— What kind of documents will be required to implement the plan? This can be in the form of checklists for both simple and complex upgrades, sign-off sheets, informational documents provided to end users, and so on. Don't forget training documentation that will be needed in a major upgrade. Training documentation should be prepared for both administrators and the highly skilled end users (power users) of new technology. Of course, you should have a document that shows the physical and logical layout of the network that is being implemented or upgraded. This sort of document can be very useful when something goes wrong and you are trying to troubleshoot a problem. You might find, for example, that the physical network you've designed cannot handle the load that users and applications will place on the network at certain points.
- Overall project plan— Any large project must be implemented in an orderly manner to be sure that the goals set for the plan are met, or possibly adjusted if necessary. A mechanism for feedback should always be included because the best of planning can always overlook some important features or applications that the current network offers. Creating a project plan with a liberal timeline can be very helpful for keeping the project on track by setting milestones to be met. By making the schedule a liberal one, you automatically build in extra time to be used when things don't go quite as you expected they would. If everything works perfectly, you get gold stars from management for bringing a project in early! Experience has shown that any large network upgrade plan will not perfectly match the first plan you develop.
- Policies and procedures— As with any technology, you should plan to develop documents that detail policies and procedures to follow when the new network begins operating. Policies dictate how the network is to be used. For example, you might not allow employees to use email for personal use or the Web browser to view pages not related to your business. Procedures are detailed instructions on how to perform certain actions. With new technology, both policy and procedure should be considered important factors.
Document Everything
Documentation is everything. People have very short memories of things that appear to have only a limited lifetime, such as work projects. It is important that a good project contain several important documents, listed here, but not limited to these:
- An executive overview— You must have some overall plan to present to upper management that explains, without too many technical details, the reasons the upgrade (or new network) is needed, and what benefits the business will obtain from the upgrade. In this sort of document, less is more. Bulleted items make a better point than long, prose-filled paragraphs. Point out the need for the network or the upgrade, and be sure to list the benefits for each point you make. If a benefit can be measured in dollars, be sure to include that information. You can include here the feedback you've obtained from the user community to show management why a change is necessary.
- A technical project plan— This is a difficult document to create. After you've identified the parts of the network to upgrade, you need to create lists of steps detailing the replacement of old equipment with the new, with little disruption to the user community. If you are building a network from scratch, or planning a major upgrade in which most of the existing equipment will be replaced, this kind of document works best when done in sections. A three-ring binder can be used, and individual sections can be assigned to technologically proficient team members for the initial writing of, and any possible updates to, sections of this document. In a larger network, it is more likely that you will have separate teams of network personnel implementing the project plan. If this is your case, create an overall plan, similar to the executive overview, and then create individual plans for each team to use for implementing their goals.
- Detailed checklists— For each task that must be performed, a detailed checklist can help ensure that an important step is not left out. This is a simple process, but it's a lot easier to get it right the first time if you use a checklist. However, creating a perfect checklist means that you've anticipated each and every possible situation that can occur. In large networks this is not always an easy task, because many applications tend to be user-centric. Be prepared to modify these checklists. As with disaster recovery plans, you should be sure to pass these checklists by lower-level administrative personnel, and provide some mechanism for testing them. Use the feedback you get to adjust your checklists as necessary.
- Risk matrix— Identify potential risks early in the project, as well as mitigation steps that may help avoid these risks, and a description of the impact to the project that will result if the issue does occur. Impact can include items such as timeline slip, features or benefits that will need to be dropped, additional equipment or budget needed to overcome an obstacle, or even complete project failure.
Test, Test, and Then Test Some More
After you have developed a plan and the requisite documentation, don't assume that all of your assumptions and calculations are accurate. The only way to determine that the products or applications you will use in the upgraded network will function as expected is to perform extensive testing. Microsoft resource kits always point out that for larger networks you should create a testing laboratory and try to test different combinations of applications and operating-system configurations and determine whether the results match the expectations of your plan.
For example, directory services are an important issue for large networks. Creating the directory structure may seem at first to be a simple task. You might simply create objects that match up to your company's organizational chart. Yet, what kind of interaction needs to occur between different departments? How can you structure the directory to make the job of granting access to other directory objects an easy task? Just as structured programming techniques make it easier to manage changes in applications as they are modified over time, creating a directory structure for a network should be done in a similar manner. Another reason why a well-designed directory structure is important is that it is through the directory that you can delegate management responsibilities to different administrators, without having to grant an administrator carte blanche access to directory objects that do not fall within their responsibility.
It is a good idea to solicit representatives of your user community for testing scenarios. Remember that the users are the most important part of your network. You can spend all the money in the world to buy the latest technology, but it will give you little value in return unless the user can continue to work efficiently.
Creating Policies and Procedures for Network Usage
Policies, mentioned earlier, are statements about how something should or should not be used. Policy documents are important for several reasons. First, you can't very well discipline an employee for abusing a network resource if you haven't created a usage policy that prohibits the particular abuse. If you don't want your network users to spend their lunch hours shopping for bargains on eBay.com, you should spell this out in an acceptable usage policy.
Policies are important in the design phase of the network because they detail how some resources are to be used. Using the example from the preceding paragraph, if you select an Internet connection after calculating what you expect your bandwidth requirements to be, you might find your network underperforming as users begin to use the connection for nonbusiness needs. Another situation in which policies come into play—to the point of being a necessity—is when you use a firewall. In Chapter 45, you'll learn more about how important it is to first create a security policy and then implement that security policy using firewall technology. If you don't know what kind of network traffic you want to allow through the firewall, setting one up is going to be difficult. For example, most secure sites prohibit users from the Internet to use the standard telnet application to gain access to computers inside the local network from computers located elsewhere on the Internet. Yet you might have users who work from home.
|
|
In addition to Chapter 45, use all the other chapters in Part VIII, "System and Network Security," of this book to learn more about network security. You'll find chapters on basic security measures, both in the local LAN and in a wide area network (WAN), as well as chapters on encryption and virtual private networks (VPNs). |
){kind=icon}
You can still keep your no-incoming-telnet policy and provide your users with a remote access server that can authenticate dial-in users or by using VPN technology. By finding out what users need in advance, you can include the necessary technology up front in the network design and might not have to make exceptions to policies later.
Procedures help prevent mistakes from happening in the first place. They are proactive measures that assist technical and nontechnical people when it comes to performing functions on the network. For example, in your network design you might have a team trained to set up several hundred desktop computers and attach them to the network. Although plugging the network card into the wall socket is simple, configuring the desktop machine can be a little more difficult. You'll need to either configure the desktop machine with valid addressing configuration information or set it up to use Dynamic Host Configuration Protocol (DHCP). Even though you might be doing this on a lot of computers, it's very easy to make a mistake when performing repetitive tasks. By using a checklist for each computer, you can improve your odds of getting it right the first time. Don't wait until you've created the network and then start looking for fires to put out. Instead, create procedure documents for commonly performed tasks. This includes tasks involved in the initial setup of the network, as well as procedures for performing daily tasks after the network is up and running—backups, connecting network drives, and so on.
Providing Training for Technical Personnel
Technical users who will be responsible for helping manage the network should be trained in the procedures for which they will be responsible. Again, this means you should provide training for those who will help you set up the network as well as those who will manage it after it is functioning. Training classes can be conducted by in-house personnel already familiar with the technology, or by one of the many hundreds of consulting services that make their living doing just this sort of thing. When it comes to training, consider cross-training support personnel so that if one person is out for the day (or longer), you still have a technician who can assist with the problem. The alternative is to have more than one person trained for specific areas of responsibility, and thus pay more in overhead costs.
Remember that the technical staff who support the network are the persons your users must depend on when a problem occurs. Perhaps the most expensive thing that can happen in most networks is downtime. RAID technology and backups can be used to protect data, but if you have hundreds (or even thousands) of idle workers getting paid to sit around while someone is reading a technical manual trying to determine the cause of a network problem, you might want to get your resume in order. Up-front training is not inexpensive, but downtime can be far more expensive than training the technical staff in the first place.
You Can't Forget the Budget (or Can You?)
When planning a network or an upgrade to a network, it is always tempting to use the latest, greatest gizmos. Sometimes, however, you can accomplish the same thing using a much less expensive gizmo. For example, if you have a small home office, you don't need a $2,000–$3,000 router and a T1 line to connect to the Internet. A simple cable or DSL modem and the appropriate broadband service should suffice in most instances. Inexpensive cable/DSL routers can be used to allow several computers on a small network to use this single connection (although some providers discourage, or even disallow this—check the details on your contract!). There is some debate as to whether the NAT and other firewall technology built into cable/DSL routers can serve as an adequate firewall. There are other protective steps that SOHO networks can employ, such as combining a router with NAT technology with a more complex software-based firewall and frequently updated virus-protection programs.
Plan the budget liberally, but don't include items that really aren't necessary. When you present a list of items to upper management that shows them what the new network will do for the company, the benefits should always outweigh the costs you've come up with. Although this might not be such an issue in a growing company, it's better to manage your network project responsibly so that you will maintain a good rapport with management. When you find that something you have planned and implemented isn't working as you expected, and you need to make changes, management will probably be more responsive if you've been frugal with the initial expenses incurred in building the network.