After establishing the organizational requirements and documenting the existing network, the designer is ready to design a network solution. This section first discusses the top-down approach to network design. Decision tables and structured design are described, and the section includes a brief discussion of the types of network design tools that might be used. The section concludes with a discussion about building a pilot or prototype, and the contents of a detailed design document.

The Top-Down Approach to Network Design

Designing a large or even medium-sized network can be a complex project. Procedures have been developed to facilitate the design process by dividing it into smaller, more manageable steps. Identifying the separate steps or tasks ensures a smooth process and reduces potential risks. A top-down design allows the designer to “see the big picture” before getting to the details. Topdown design clarifies the design goals and initiates the design from the perspective of the required applications. The top-down approach adapts the physical infrastructure to the needs of the applications. Network devices are chosen only after a thorough requirements analysis. Structured design practices should be integrated with the top-down approach, especially in very complex networks. In contrast to top-down design, the network design approach in which network devices and technologies are selected first is called bottom-up, or connect-the-dots. This approach often results in an inappropriate network for the required services and is primarily used when a very quick response to the design request is needed. With a bottom-up approach, the risk of having to redesign the network is high. NOTE These estimates do not include the time needed to prepare detailed network diagrams if the customer does not supply them.

Guidelines for producing a top-down design include the following:

■ Thoroughly analyze the customer’s requirements.

■ Initiate the design from the top of the OSI model. In other words, define the upper OSI layers (application, presentation, and session) first, and then define the lower OSI layers (transport, network, data link, and physical)—the infrastructure (routers, switches, and media) that is required.

■ Gather additional data about the network (protocol behavior, scalability requirements, additional requirements from the customer, and so forth) that might influence the logical and physical design. Adapt the design to the new data, as required.

Top-Down Approach Compared to Bottom-Up Approach

A top-down approach to design has many benefits compared to a bottom-up approach, including the following:

■ Incorporating the customer organization’s requirements

■ Providing the customer and the designer with the “big picture” of the desired network

■ Providing a design that is appropriate for both current requirements and future development The disadvantage of the top-down approach is that it is more time-consuming than the bottom-up approach; it necessitates a requirement analysis so that the design can be adapted to the identified needs. A benefit of the bottom-up approach—selecting the devices and technologies and then moving toward services and applications—is that it allows a quick response to a design request. This design approach facilitates designs based on the designer’s previous experience. The major disadvantage of the bottom-up approach is that it can result in an inappropriate design, leading to costly redesign.

Intermediate System–to–Intermediate System (IS-IS), Enhanced Interior Gateway Routing Protocol (EIGRP), and BGP. Five required parameters are listed, along with an indication of how well the routing protocols comply with these parameters. As indicated in the figure, the chosen protocol should include the following properties:

■ It should support a large network. All the protocols being considered meet this requirement.

■ It must be Enterprise-focused, rather than Internet service provider–focused. BGP was designed to support interconnecting networks of autonomous systems; it is not optimized for use in the enterprise. IS-IS is typically deployed in service provider environments, rather than in enterprises.

■ Support for variable-length subnet mask (VLSM) is required. All the protocols being considered support VLSM.

■ It must be supported on Cisco routers, which is the case for all the protocols being considered.

■ Network support staff should have a good knowledge of the chosen protocol to enable them to troubleshoot the network. In this case, the network support staff are knowledgeable about EIGRP, but not about OSPF, IS-IS, or BGP.

Structured Design

The output of the design should be a model of the complete system. The top-down approach is highly recommended. Rather than focusing on the network components, technologies, or protocols, instead focus on the business goals, technical objectives, and existing and future network applications and services. Structured design focuses on a systematic approach, dividing the design task into related, less complex components, as follows:

■ First, identify the applications needed to support the customer’s requirements.

■ Next, identify the applications’ logical connectivity requirements, with a focus on the necessary infrastructure services and network infrastructure.

■ Split the network functionally to develop the network infrastructure and hierarchy requirements.

■ Design each of the functional elements separately, yet in relation to other elements. For example, the network infrastructure and infrastructure services designs are tightly connected; they are both bound to the same logical, physical, and functional models. Use the top-down approach during all designs.

Figure Structured Design Example

In this example, network infrastructure design and infrastructure services design are tightly connected; both are bound to the same logical, physical, and functional models. These elements are subdivided logically. The network infrastructure design is subdivided into physical topology design, addressing design, routing design, and technology selection. The infrastructure services design is subdivided into QoS design, security design, and multicast design. All design phases use the top-down approach.

Network Design Tools

Several types of tools can be used to ease the task of designing a complex modern network, including the following:

■ Network modeling tools: Network modeling tools are helpful when a lot of input design information (such as customer requirements, network audit and analysis results, and so on) exists. Network modeling tools enable modeling of both simple and complex networks. The tools process the information provided and return a proposed configuration, which can be modified and reprocessed to add redundant links, support additional sites, and so forth.

■ Strategic analysis tools: Strategic analysis or what-if tools help designers and other people who are working on the design (engineers, technologists, and business and marketing professionals) to develop network and service plans, including detailed technical and business analysis. These tools attempt to calculate the effects of specific network components through simulated scenarios.

■ Decision tables: As discussed, decision tables are manual tools for choosing specific network characteristics from multiple options, based on required parameters.

■ Simulation and verification tools or services: These tools or services are used to verify the acquired design, thereby lessening the need for a pilot network implementation.

Figure illustrates how the initial requirements information is processed with network design tools to produce a network design

Figure: Using Network Design Tools

To verify a network design that was produced with the help of network modeling tools, strategic analysis tools, and decision tables, either use simulation and test tools or build a pilot or prototype network. The pilot or prototype network also creates a proof of concept that confirms the appropriateness of the design implementation plan.

Building a Prototype or Pilot Network

• A pilot network tests and verifies the design before the network is launched, or is a subset of the existing network in which the design is tested.

• A pilot network is normally used when the design is for a completely new network; pilots can also be used for designs that add to an existing network.

• A prototype network tests and verifies a redesign in an isolated network, before it is applied to the existing network. A prototype network is usually used to verify designs that must be implemented on an existing network infrastructure.

It is important that the pilot or prototype test the design, including the customer’s most important stated requirements. For example, if a key requirement is minimal response time for remote users, ensure that the prototype or pilot verifies that the maximum acceptable response time is not exceeded. A prototype or pilot implementation can have one of two results:

■ Success: This result is usually enough to prove the design concept.

■ Failure: This result is normally used to correct the design;

the prototype or pilot phase is then repeated. In the case of small deviations, the design can be corrected and tested in the prototype or pilot network immediately.

Documenting the Design

A design document lists the design requirements, documents the existing network and the network design, identifies the proof-of-concept strategy and results, and details the implementation plan. The final design document structure should be similar to the one in Figure 2-26, which includes the following:

■ Introduction: Every design document should include an introduction to present the main reasons leading to the network design or redesign.

■ Design requirements: Also a mandatory part of any design document, this section includes the organization’s requirements and design goals that must be fulfilled.

■ Existing network infrastructure: This section is required only for a network redesign. The subsections document the results of the existing network characterization steps.

■ Design: This section is an essential part of the design document and identifies the design and implementation details simply a new service introduction, for example), but they typically include the topology, addressing, and design. Implementation details, such as configuration templates and exact configurations of network devices, are included to ease the implementation process.

■ Proof of concept: This section describes the pilot or prototype network verification and test results.

■ Implementation plan: This section provides the implementation details that technical staff need to carry out as quickly and smoothly as possible, without requiring the presence of the designer.

■ Appendixes: The appendixes usually include lists and, optionally, configurations of existing network devices.

Figure: Sample Design Document