Applying Network Design Theory

Perhaps the best way to understand the application of network design theory is to review the recommended steps for a network design project. By no means are these lists exhaustive; however, they do provide a good template for designers on a wide variety of projects.

The Network Design Methodology Model

The first list is the textbook CID model that was presented in Chapter 1. It is presented again in Figure 12.1.

FIGURE 12.1  The network design methodology

Though Cisco expects this flow for the exam, many experienced designers would take some issue with the order used and the omissions, including vendor evaluations, pricing, and user testing, for example. However, this flow does incorporate some very positive elements. For example, the use of a review and continuous process is frequently omitted from most projects—everyone completes the first project and moves to the second. Remember, there are four phases to a project or, at least, a well-run project:

•  Conception

•  Provision

•  Implementation

•  Review

It would be easier to remember the order of these steps if all four ended in ’tion, yet perhaps it’s easier to remember because the steps don’t exactly flow together. Another memory aid is to skip the implementation step and think CPR. Many projects require first aid soon after implementation because the review step was dismissed.

The CID model illustrated in Figure 12.1 accomplishes a number of things. The key points to remember are:

•  The sequence follows a logical flow from project conception to review.

•  The methodology incorporates the critical task of obtaining customer requirements and expectations.

•  The concept of standardization is incorporated. This occurs most visibly at the naming and addressing phase.

The Network Design Process

The following recommended network design process incorporates more detail than the model above, but it stops before the implementation and review phases. In fact, it is specifically targeted to the conception and provisioning steps, which frequently determine the success of the project.

1.  Identify any business constraints on the project or design.

•  Document the budget and resources available for this project and establish a time line. Gantt charts, which show the relationships between each task over time and per resource, are very helpful in this phase. All participants in the project should be able to identify the dependencies with other efforts and tasks.

•  Identify the staffing requirements, including hiring, training, and contracting. Vendor requirements should also be identified. This step is sometimes appropriate before the equipment is selected; a few thousand dollars spent on a class to see that the equipment is not appropriate for the company is cheap compared to the purchase price. If the company uses the equipment, the expenditure is not wasted.

2.  Identify the security requirements for the network.

•  Assess the security risks and determine what security will be needed and of what type. As presented in Chapter 11, this process should include physical and logical security against internal and external threats.

•  Determine outside access requirements for data. This may include Web transaction servers and database access; attention should be given to vendor support connectivity as well. Many vendors need remote control or remote node connectivity in order to provide support.

•  Identify any requirements for authenticating routes received from access routers or other routers. This task rarely evolves into a significant issue, but route spoofing and other attacks, such as DNS spoofing, should be considered.

•  Determine the authorization and authentication requirements for users, including those in corporate branch offices, mobile users, and telecommuters. VPN technologies and services, including TACACS+ and RADIUS, are important to consider in this phase.

•  Identify the requirements for host security, including the physical security of hosts and user accounts. Again, physical security is a foundation to all other protection mechanisms. Consideration should be given to user acceptance of the security model to make certain that they don’t proactively circumvent it.

3.  Identify manageability requirements.

•  Identify the requirements for fault management, accounting management, configuration management, performance management, and security management. It may also be appropriate to consider change management at this phase. This is an area where many companies falter. Placing a circuit in the network is relatively easy, but failure to consider the support of that circuit can harm even the best design.

4.  Extract application requirements.

•  Obtain and document the names and types of new applications and the protocols that will be used. Include port numbers where applicable. This phase typically requires repeated efforts, as many applications use administratively defined ports or internally defined ones that are unknown to the system administrators.

•  Document the projected number of users who will use the new applications and protocols. This is a key component of scalability and capacity planning.

•  Diagram the flow of information through the network for new applications. This should be compared to current data-flow diagrams. Again, this is a key component of capacity planning.

•  Identify the peak hours of usage of new applications. This information should be stored in a central location outside of the project so that other groups can anticipate future demands.

5.  Characterize new network traffic.

•  Characterize the traffic load. This includes many components from the application requirements; however, it needs to include dependencies on other servers and resources.

•  Characterize the new application’s traffic behaviors, including broadcast/multicast, supported frame size(s), windowing and flow control, and the error-recovery mechanisms available.

6.  Identify any performance requirements and define preliminary design goals. This may include service-level projections such as:

•  Application and network response time—two factors in the user experience.

•  Network and application availability. If there are high-availability needs, it is likely that redundancy and fault-tolerance efforts will require funding.

•  Threshold for network utilization. This may include historical projections and failure scenarios. For example, a network failure (single event) may not affect the application performance by more than a certain amount. Consider two load-balancing circuits and a service level that precludes user impact during a single circuit failure. The user should not see a reduction in response time or throughput when only one circuit is busy. A threshold of no more than 50 percent would be required in order to ensure that packets will be accommodated on the single circuit. Ideally, this number would be reduced to a comfortable level—perhaps 35 to 40 percent when both circuits are operational—that doesn’t saturate the circuit.

•  Data throughput, measured between nodes per unit of time, usually seconds. This accounts for bursts in the network. Most designers will not design for bursts, opting for a five-minute to one-hour average utilization instead. However, if the user saturates the link for five minutes and the link is idle for the remaining 55 minutes, this will lead to poor performance as observed by the user.

•  Network latency, which is a minor concern in most networks today. However, carriers should be held to a maximum service-acceptable latency—somewhere between 50 and 85 ms for a cross-country (US) circuit. The routing of the circuit can impact not only latency, but also reliability—it is usually better to have the straightest path as opposed to a circuitous one.

7.  Create a customer needs specification document (optional).

•  Record the customer’s requirements and constraints and the characteristics of the existing network. This type of document is critical to providing a clear review process—did the project meet the objectives?

	Some argue that this step is not optional and that it should appear earlier in the process. Experience should provide a guide in your individual environment.