Part I of this book is composed of this chapter. It describes the network design process and two network design models, and includes the following sections:
This chapter discusses design and the various methodologies for designing today’s networks.
Note
Appendix B, “Network Fundamentals,” is a refresher of topics that you should understand before reading this chapter—and the rest of the book. Appendix B includes the following topics:
You are encouraged to review any of the material in Appendix B that you are not familiar with before reading the rest of this chapter.
Before delving into the details of network design, consider what design is and, in particular, what you expect from a good design.
Dictionaries generally define design as planning how to create something, or the actual plans themselves. However, when you think of designing something, whether it is a product, an addition to a house, or a network, you likely contemplate a broader use of the word design.
For example, if you hire an architect to design an addition to your house, you expect her to produce detailed plans and engineering drawings that can be used to create the space that you want. What is the process that an architect uses to get to this final product, plans that can be used to create what you want and need? Crucial inputs are the dimensions, the state, and the use of the existing house, and your requirements for the addition (including your budget), as illustrated in Figure 1-1. The former are much easier to solidify than the latter. For the existing house, the architect must measure all the rooms and spaces, and take notes of the existing use and function—for example, the layout of the existing kitchen, where the family usually eats, and so forth.
Figure 1-1. When Designing an Addition to a House, an Architect Needs to Have Knowledge of the Existing Structure and the Requirements for the Addition—Along with Skills and Creativity.
Key Point
To determine the requirements for the addition, a good architect should ask probing questions. Determining the actual requirements, rather than your perceived solutions, is a key skill for a good architect.
For example, assume that you tell the architect that you want three skylights and a fireplace in the room. Rather than just including these items, a good architect should ask why you want them and what you see their function to be. You might want skylights to provide more light to the room and a fireplace to provide heat. The ability to determine the actual requirements (light and heat), rather than your perceived solutions (skylights and fireplace), is a critical skill for a good architect. The architect can then recommend different solutions to what you perceive the problems to be—lack of light and lack of heat. For example, a heated floor can provide warmth, while a wall of opaque glass blocks can provide light. (Of course, you might just want a fireplace and skylights, in which case, these would also be requirements.)
The architect then takes all the requirements together as inputs to the design. Using her creativity and training, the architect typically prepares several options, which are then presented to you. At this stage, the options are not fully developed, but will probably be at a conceptual level, and might include sketches and cost estimates. A meeting is normally held to review the options and to choose one option or a combination of them, to note changes and additions, and so forth. The architect then develops the final design, which must be approved by you before the engineering drawings are created, permits obtained, contractors selected, and so forth. The architect can also provide continuity and quality control for the project by reviewing the progress while the addition is being built.
Thus, as is true for any project, a good design requires good inputs—clear requirements are critical. The design process must, of course, allow requirements to change; however, spending time up-front clarifying requirements goes a long way toward reducing major problems later. For example, many government projects include a mandatory requirements document that must be reviewed and signed off before any design or implementation work can be started. Finalizing this requirements document can be a lengthy process—for example, one large project had a requirements definition phase that was years long (thankfully, it has now been implemented successfully).
Understanding the existing structure, if one exists, is also important because it can introduce constraints (for example, in the house-addition project, the window area allowed on a side wall might be restricted by a building code), but it can also provide opportunity (for example, you might be able to reuse some doors that will be removed from the existing house in the new addition).
Good design also requires creativity and skills. For a residential architect, these traits come from both training and experience.
A network design is no different. Understanding the requirements for the network, as well as knowing how the existing network is structured and used, is key to understanding how the new or updated network should function and which features should be included. Understanding how the features operate, what they do, what their constraints are, and what alternative approaches are available comes from both training and experience. Part II of this book, “Technologies: What You Need to Know and Why You Need to Know It,” introduces you to some of the fundamental networking technologies available today, while Part III, “Designing Your Network: How to Apply What You Know,” explores the use of these technologies in the context of a case study. This chapter introduces you to network design principles and design models.
Cisco has developed the Plan-Design-Implement-Operate-Optimize (PDIOO) network life cycle to describe the multiple phases through which a network passes. This life cycle is illustrated in Figure 1-2, and the phases are briefly described as follows:
Plan phase—. The detailed network requirements are identified, and the existing network is reviewed.
Design phase—. The network is designed according to the initial requirements and additional data gathered during analysis of the existing network. The design is refined with the client.
Implement phase—. The network is built according to the approved design.
Operate phase—. The network is operational and is being monitored. This phase is the ultimate test of the design.
Optimize phase—. During this phase, issues are detected and corrected, either before problems arise or, if no problems are found, after a failure has occurred. Redesign might be required if too many problems exist.
Retirement phase—. Although not part of the PDIOO acronym, this phase is necessary when part of the network is outdated or is no longer required.
![PDIOO Network Life Cycle Includes Many Design Aspects[1]](/library/view/campus-network-design/1587052229/graphics/01fig02.gif)
The PDIOO cycle describes all the phases of a network’s life. The task of designing a network is obviously an integral part of this life cycle and influences all phases. For example, the implemen-tation phase might involve a prototype, which can help validate the design.
Network design should include the following tasks, as illustrated in Figure 1-3:
Determine requirements
Analyze the existing network, if one exists
Prepare the preliminary design
Complete the final design development
Deploy the network
Monitor, and redesign if necessary
Maintain documentation (as a part of all the other tasks)
These tasks, and their relationship to the PDIOO phases, are examined in the following sections.
Determining the network requirements is a part of the PDIOO Plan phase. Many types of requirements must be considered, including those that are related to technical and business issues. Any factors that might restrict the design must also be identified. In the case where an existing network is in place, these constraints can be related to what is already there and how the new network must be phased in to allow continuous operation.
Technical requirements and restraints can include the following items:
Applications that are to run on the network
Internet connections required
Addressing restrictions, for example, the use of private Internet Protocol (IP) version 4 (IPv4) addresses
Support for IP version 6 (IPv6) addresses
Other protocols that are to run on the network (for example, routing protocols)
Cabling requirements
Redundancy requirements
Use of proprietary equipment and protocols
Existing equipment that must be supported
Network services required, including quality of service (QoS) and wireless
Network solutions required (for example, voice traffic, content networking, and storage networking)
Network management
Support for existing applications while new ones are being phased in
Bandwidth availability
Key Point
An intelligent network service supports network applications. For example, security and QoS are not ultimate goals of or applications on a network; rather, they are necessary services that enable other applications. Note that some of these services, such as security, are now integral parts of any well-designed network.
Intelligent network solutions are network-based applications. These network solutions require the support of the network services. Voice communication is an example of an intelligent network solution; it requires QoS for optimal operation.
Requirements and restrictions related to business issues can include the following:
Budget—. Capital (for new equipment) and operating (for ongoing expenses).
Schedule—. This could include the phasing out of older applications, hiring of new personnel, and so forth.
People—. Considerations include who will install and operate the network, what skills they have, whether they require training, whether any of these tasks will be outsourced, and so forth.
Legal—. Issues include any restrictions on the use and storage of data collected, whether the organization has contractual obligations or opportunities related to the network (for example, long-term maintenance or lease contracts), and so forth.
History—. Factors include examining the existing network’s structure and determining whether any person or group will block changes or additions.
Policies—. Consider whether current organizational policies might restrict the network design.
As discussed earlier in the house-addition analogy, extracting requirements is a difficult task.
Key Point
Requirements must be clear and deterministic (verifiable); in other words, at the end of the project, you should easily be able to determine whether a requirement has been met.
For example, a customer might say that the new network must help reduce overall costs. This goal must be translated into requirements that can be implemented and measured. For example, reducing costs could mean that a web-based ordering system replaces call-center ordering, or it could mean that unreliable equipment is replaced. Each of these options has its own initial and operating costs, so you must understand what the network owner means when he states his goals.
Each of the requirements should also be assessed for its importance, and a weighting factor should be assigned so that if conflicts arise (for example, an inadequate budget), the most important requirements can be met.
If this is a redesign of an existing network, the current network must be analyzed and understood. As noted earlier, an existing network is likely to restrict the network design in some manner; for example, the existing cabling might not be optimal but might have to be kept for cost reasons. Analyzing the existing network is typically done during the Optimize phase of the existing network; it could also be considered as part of the Plan phase for the new network.
You should analyze the network to determine both what is good and what should be changed. For example, the network might include virtual private network (VPN) connections so that employees can access corporate files through the Internet (VPN is discussed in Chapter 4, “Network Security Design”). If the organization is satisfied with this feature, this portion of the network might not have to be changed.
Key Point
While examining documentation about the existing network and discussing it with users, administration staff, and other stakeholders is important, you should also do an audit of the network. The audit can identify items such as the protocols that are running (both those that are known to be running and those that have not been reported), the devices installed and their configurations, the utilization of these devices, and the bandwidth on key WANs).
Many operating systems include commands that display information about device hardware and software. For example, the show version command in the Cisco Internet Operating System (IOS) displays information related to the version of the software and the amount of memory available. Additional tools, such as protocol analyzers, might be necessary to gather other information.
Preliminary design involves considering all the network requirements and constraints (including the budget), and determining viable alternative solutions. The network owner is then consulted, and together an optimal solution is chosen; this solution is later developed into the final design. Both the preliminary design and final design are done during the PDIOO Design phase.
Two models that can be used for network design are examined in the “Modular Network Design” section, later in this chapter. Whichever model is used, a top-down approach (rather than a bottom-up approach) is recommended.
Key Point
A top-down approach to network design means that requirements are considered first, with the applications and network solutions that will run on the network driving the design.
A bottom-up approach would first select devices, features, cabling, and so on, and then try to fit the applications onto this network. A bottom-up approach can lead to redesign if the applications are not accommodated properly. This approach can also result in increased costs by including features or devices that are not required and would have been excluded had the network requirements analysis been completed.
After the alternative solutions have been developed, the optimal solution must be chosen. A systematic approach works best—all the options should be listed along with how well they meet (or don’t meet) the design requirements and constraints. If no clear winner exists, the importance of the requirements (as determined in the requirements-gathering process) should be considered to select the optimal design.
Developing the final design involves producing detailed drawings, configuration specifications, costing, addressing plans, and any other information required for implementation.
Deployment of the network must start with a plan and a schedule. Deployment planning starts in the PDIOO Design phase and continues into the Implement phase.
The deployment plan must include details of what is to be done and how it is to be done. For example, if new cabling is required, the procedure to run the cable and the location where it is needed must be fully documented. Scheduling is important, not only to identify when things will be done but also to determine who will do them, and what impact the deployment will have on the existing network. For example, if current applications must still work while the new network is being implemented, the schedule must show any times during which the applications will be unavailable.
Contingency plans, that is, plans for what happens if a problem occurs during the implementation, should also be included. These contingency plans should address how the network will be returned to a known working state, if possible. Testing should be incorporated into the deployment plan to ensure that the functions are working as they are implemented.
Any training required for personnel should be planned during this time. For example, if you are deploying a Voice over IP (VoIP) solution, the network administrators might require some instruction on the technology before they can implement and maintain it.
Any contracts required should be negotiated during this time. Examples include outsourcing, Internet connectivity, maintenance, and so forth.
When the plans, schedules, contracts, and so on are in place, the network can be implemented. Any problems found in the design during this phase must be corrected and documented.
After the network is operating, baseline operational statistics should be gathered so that values for a working network are known. The network should then be monitored for anomalies and problems. If problems that require redesign occur, or if requirements change or are added, the appropriate design changes must be made and the entire design process should be repeated for that portion of the network. Monitoring and redesign take place in the PDIOO Operate and Optimize phases, and can lead back into the Plan and Design phases.
The design should be documented throughout the process. Documentation should include the following items:
All the agreed-to requirements and constraints
The state of the existing network, if any
Preliminary design options and a brief review of why the final design was chosen
Final design details
Results of any pilot or prototype testing
Deployment plans, schedules, and other implementation details
Monitoring requirements
Any other pertinent information
Documentation should be started in the PDIOO Design phase but might not be complete until well into the Implement phase. Updates to the design documentation can be made in the Operate and Optimize phases if redesign is required.
The following sections explore modular network design and then introduce two models that can be used for modular network design.
Key Point
A module is a component of a composite structure. Modular network design involves creating modules that can then be put together to meet the requirements of the entire network.
Modules are analogous to building blocks of different shapes and sizes; when creating a building, each block has different functions. Designing one of these blocks is a much easier task than designing the entire building. Each block might be used in multiple places, saving time and effort in the overall design and building process. The blocks have standard interfaces to each other so that they fit together easily. If the requirements for a block change, only that block needs to change—other blocks are not affected. Similarly, a specific block can be removed or added without affecting other blocks.
As when used for a building, a modular design for a network has many benefits, including the following:
It is easier to understand and design smaller, simpler modules rather than an entire network.
It is easier to troubleshoot smaller elements compared to the entire network.
The reuse of blocks saves design time and effort, as well as implementation time and effort.
The reuse of blocks allows the network to grow more easily, providing network scalability.
It is easier to change modules rather than the entire network, providing flexibility of design.
Note
The Open Systems Interconnection (OSI) model, described in Appendix B, is an example of a modular framework for the communication protocols used between computers.
The following sections introduce two models that can be used for network design: the hierarchical model and the Cisco Enterprise Composite Network Model. You will see that both of these models involve creating modules, and that hierarchical design can in fact be part of the modules of the Enterprise Composite Network Model.
The hierarchical network design model is illustrated in Figure 1-4.
Key Point
The three functions that comprise the hierarchical network design model are as follows:
Access layer—. Provides user and workgroup access to the resources of the network
Distribution layer—. Implements the organization’s policies, and provides connections between workgroups and between the workgroups and the core
Core layer—. Provides high-speed transport between distribution-layer devices and to core resources
These three layers can also be thought of as modules; each module has specific functions and can therefore be designed using the optimal devices and features to meet the specific requirements of the module.
Figure 1-5 illustrates a simple network and shows how it maps to the hierarchical model. (Later chapters in this book detail the functions of the devices shown in this figure.)
Do you always need to have separate devices for each layer? No. Consider how the Transmission Control Protocol/Internet Protocol (TCP/IP) suite is an implementation of the OSI model. The TCP/IP model combines some of the OSI layers; for example, the TCP/IP application layer represents the OSI model application, presentation, and session layers. Similarly, your implementation of the hierarchical model can combine some of the functions into one physical device, especially if you have a smaller network.
Some factors to consider when designing each of the hierarchical layers are described in the following sections.
The access layer is where users access the network. Users can be local or remote.
Local users typically access the network through connections to a hub or a switch. Recall that hubs operate at OSI Layer 1, and all devices connected to a hub are in the same collision (or bandwidth) domain. Switches operate at Layer 2, and each port on a switch is its own collision domain, meaning that multiple conversations between devices connected through the switch can be happening simultaneously. Using a LAN switch rather than a hub has a performance advantage: A LAN switch forwards unicast traffic only out of the port through which the traffic’s destination is considered reachable. However, a hub forwards all traffic out of all its ports. For this reason, most of today’s networks have LAN switches rather than hubs. (Switching, including Layer 3 switching, is discussed in Chapter 2, “Switching Design.”)
Remote users might access the network through the Internet, using VPN connections, for example. Connections to the Internet can be through dial-up, digital subscriber line (DSL), cable, and so forth. Other access possibilities include WANs such as Frame Relay, leased lines, and Integrated Services Digital Network (ISDN).
The access layer must also ensure that only users who are authorized to access the network are admitted.
The distribution layer interfaces between the core and access layers, and between access layer workgroups.
The distribution layer functions and characteristics include the following:
Implementing policies by filtering, and prioritizing and queuing traffic.
Routing between the access and core layers. If different routing protocols are implemented at these other two layers, the distribution layer is responsible for redistributing (sharing) among the routing protocols, and filtering if necessary (as discussed in Chapter 3, “IPv4 Routing Design”).
Performing route summarization (as also discussed in Chapter 3). When routes are summarized, routers have only summary routes in their routing tables, instead of unnecessary detailed routes. This results in smaller routing tables, which reduces the router memory required. Routing updates are also smaller and therefore use less bandwidth on the network. As discussed in Chapter 3, route summarization is only possible if the IP addressing scheme is designed properly.
Providing redundant connections, both to access devices and to core devices.
Aggregating multiple lower-speed access connections into higher-speed core connections and converting between different media types (for example, between Ethernet and Frame Relay connections), if necessary.
The core layer provides a high-speed backbone. Functions and attributes of the core layer include the following:
Providing high-speed, low-latency links and devices for quick transport of data across the backbone.
Providing a highly reliable and available backbone. This is accomplished by implementing redundancy in both devices and links so that no single points of failure exist.
Adapting to network changes quickly by implementing a quick-converging routing protocol. The routing protocol can also be configured to load-balance over redundant links so that the extra capacity can be used when no failures exist.
Filtering is not performed at this layer, because it would slow processing. Filtering is done at the distribution layer.
The hierarchical model is useful for smaller networks, but it does not scale well to larger, more complex networks. With only three layers, the model does not allow the modularity required to efficiently design networks with many devices and features. The Enterprise Composite Network Model, introduced in the following section, provides additional modularity and functions.
Cisco has developed a SAFE blueprint, the principle goal of which is to provide best practices information on designing and implementing secure networks. The SAFE architecture uses a modular approach, providing the advantages previously discussed. (The SAFE model is discussed further in Chapter 4.)
The Cisco Enterprise Composite Network Model is the name given to the architecture used by the SAFE blueprint. This model supports larger networks than those designed with only the hierarchical model and clarifies the functional boundaries within the network.
The Enterprise Composite Network Model first divides a network into three functional areas, as illustrated in Figure 1-6.
![Functional Areas of the Enterprise Composite Network Model[2]](/library/view/campus-network-design/1587052229/graphics/01fig06.gif)
Key Point
The three functional areas are as follows:
Enterprise Campus—. This area contains all the functions required for independent operation within one campus location; it does not provide remote connections. You can have multiple campuses.
Enterprise Edge—. This area contains all the functions required for communication between the Enterprise Campus and remote locations, including the Internet, remote employees, other campuses, partners, and so forth.
Service Provider Edge—. This functional area is not implemented by the organization; rather, it is included to represent WANs and Internet connections provided by service providers.
Each of these functional areas contains network modules, which in turn can include the hierarchical core, distribution, and access layer functionality.
Figure 1-7 displays the modules within each of these functional areas. The following sections provide details on each of these modules.
![Each Functional Area Contains Modules[3]](/library/view/campus-network-design/1587052229/graphics/01fig07.gif)
The modules within the Enterprise Campus functional area are as follows:
Campus Infrastructure module
Management module
Server module
Edge Distribution module
Note
These module names are consistent with those in the SAFE blueprint. However, slight variations exist between these names and those in the following Cisco Press books: CCDA Self-Study: Designing for Cisco Internetwork Solutions (DESGN) and CCDP Self-Study: Designing Cisco Network Architectures (ARCH).
The Campus Infrastructure module represents one or more buildings connected to a backbone. This module is comprised of three submodules: Building, Building Distribution, and Core. These submodules map directly onto the hierarchical model’s access, distribution, and core layers.
The combination of a Building and a Building Distribution submodule represents each building within a campus. Each of these buildings is connected to the Core, to provide connectivity between buildings and to the Server and Edge Distribution modules.
The Building submodule contains all the devices to allow users in the building to access the network. This includes end-user devices, such as IP phones and PCs, as well as devices to interconnect the end users to the services they require. This latter functionality is typically provided by Layer 2 switches, but it can also include Layer 3 switches if more advanced features are required. This submodule is responsible for ensuring that only users who are authorized to access the network are admitted. The Building submodule also performs functions such as marking the QoS level of the traffic (for example, to distinguish voice traffic from file transfer traffic so that it can be handled appropriately throughout the network).
The Building Distribution submodule provides access between workgroups and to the Core. This functionality is typically provided by Layer 3 switches or routers. Routing is implemented in this submodule; route filtering might also be required. Summarizing of routes should also be implemented here so that the routing overhead is minimal. This submodule controls access to services by implementing filters or access lists. Redundant switches and redundant links to both the access and backbone should also be implemented in this submodule.
The Core submodule typically uses Layer 3 switching to provide a high-speed connection between the campus buildings and the Server and Edge Distribution modules. Redundancy is implemented to ensure a highly available and reliable backbone.
The Management module houses monitoring, logging, security, and other management features within an enterprise.
A network-monitoring server monitors devices in the network and reports any events that occur (such as an interface error on a router). This can be combined with a system administration server to configure network devices.
Some of the management security features that can be implemented in this module are as follows:
An authentication, authorization, and accounting (AAA) server to provide security checks of users. Authentication determines who the user is and whether he is allowed on the network. Authorization determines what the user can do on the network. Accounting records the time of day and time spent, for example, so that the user can be billed for the network services used. The AAA server can also record a user’s location.
Intrusion detection system (IDS) and intrusion prevention system (IPS) management. IDSs scan network traffic for malicious activity, while IPSs can protect the network if an attack is detected. An IDS and IPS management server logs suspicious activities that are detected by IDS and IPS sensors deployed throughout the network.
System logging, for example, using a syslog server to log events and traps.
Network management traffic can traverse through an out-of-band or an in-band connection. Out-of-band management provides access to devices on a connection dedicated to management data (different from the connections on which network data flows), for example, through the console port of a Cisco router. In-band management provides access to devices through the same path as data traffic; for example, you can use Telnet to access a router over an IP network.
Note
Chapter 9, “Network Management Design,” describes the Management module in detail.
The centralized Server module contains internal campus servers. These servers can include e-mail, file, and print servers, or any other servers that are necessary for the network solutions (for example, a Cisco CallManager server if IP telephony is implemented in the network). Redundancy is typically implemented within this module and to the Core so that users always have access to the servers they need. Layer 3 switches are typically used in this module to provide both the high performance of Layer 2 switching and the Layer 3 routing and filtering capabilities.
The Edge Distribution module is the interface between the Enterprise Campus (through the Core submodule) and the Enterprise Edge functional areas.
This module typically uses Layer 3 switching to provide high-performance routing, similar to the Server module. Redundancy is again implemented in this module to ensure that the campus users always have access to the Enterprise Edge.
The Enterprise Edge functional area is the interface between the Enterprise Campus functional area (through the Edge Distribution module) and the Service Provider Edge functional area. It is comprised of the following four modules:
E-commerce module
Corporate Internet module
VPN/Remote Access module
WAN module
The E-commerce module includes the devices and services necessary for an organization to support e-commerce applications, such as online ordering. The devices in this module usually include web servers, application servers, and security devices such as firewalls and IDS appliances.
The Corporate Internet module provides Internet access for the users and passes VPN traffic from remote users to the VPN/Remote Access module. Typical servers in this module include e-mail, File Transfer Protocol (FTP), and Domain Name System (DNS) servers. Security systems, such as firewalls and IDSs/IPSs, are also present here to ensure that only legitimate Internet traffic is allowed into the enterprise.
The VPN/Remote Access module terminates VPN traffic and dial-in connections from external users. Typical devices in this module include dial-in access and VPN concentrators to terminate the remote user connections, and firewalls and IDS appliances to provide security.
The WAN module provides connectivity between remote sites and the main site over various WAN technologies. This module does not include the WAN connections; rather, it provides the interfaces to the WANs. The WAN connections themselves are supplied by the service providers, which are represented in the Service Provider Edge modules. Example WAN interfaces provided by this module are Frame Relay, Asynchronous Transfer Mode (ATM), cable, and leased lines.
The three modules within the Service Provider Edge functional area are as follows:
Internet Service Provider (ISP) module
Public Switched Telephone Network (PSTN) module
Frame Relay/ATM module
Recall that these modules are not implemented within the Enterprise itself but are provided by the service providers.
The ISP module represents connections to the Internet. Redundant connections to multiple ISPs can be made to ensure service availability. The actual connection type is dictated by the ISPs.
The PSTN module represents all dial-up connectivity, including analog phone, cellular phone, and ISDN connections.
The Frame Relay/ATM module represents all permanent connections to remote locations, including Frame Relay and ATM, but also leased lines and cable, DSL, and wireless connections.
In this chapter, you learned about design in general and specifically about network design principles. You also learned about modular network design and the hierarchical and Enterprise Composite Network models for designing networks.
As a summary of the network design process presented here, consider the following checklist:
Did you ask probing questions to really understand the requirements?
Have you determined the requirements and constraints related to technical issues? Are the requirements clear and deterministic (verifiable)?
Have you determined the requirements and constraints related to business issues, including the budget? Are the requirements clear and deterministic?
Have you prioritized, or assigned weights to, each of the requirements?
Do you understand the network solutions/applications that are called for, and which network services are required to support them?
Have you analyzed and audited the existing network, if one exists, to determine any restrictions on the new network as well as what portions of the existing network should be retained?
Did you create some preliminary design options, using a top-down approach, so that all the network requirements are considered?
Did you create a modular design?
Did you identify the hierarchical network design layers in your design, and did you consider the appropriate devices and links for each layer?
Did you use the Enterprise Composite Network Model in your design? Did you identify the relevant functional areas and modules of this model that will be used in your network, and did you consider the appropriate devices and links for each module?
Did you and the network owner agree on the optimal solution, based on your preliminary design options?
Did you implement a prototype or pilot network to verify all or a portion of the design?
Did you create a detailed deployment plan and schedule, including implementation, testing, training, and contracts?
Do you have a plan for what is to be monitored in the operating network and how errors are to be handled?
Have you thoroughly documented the details of the design and the design process?
Network design is an art as well as a science. Just as there are many different ways to design an addition to a house, there are a variety of ways to design a network. It is critical to keep going back to the agreed-to requirements and their importance to the network owner; this helps ensure that the final network will be a success.
The technologies used in the network are constantly—and in some cases quickly—evolving. Because it is impossible to be an expert on all the technologies, we encourage you to seek help during your design from experts in specific fields. A good up-front design reduces the likelihood of catastrophes during the implementation or operation phases of the network life cycle.
| 1. | Teare, CCDA Self-Study: Designing for Cisco Internetwork Solutions (DESGN), Indianapolis, Cisco Press, 2004, p. 45. |
| 2. | Adapted from “SAFE: A Security Blueprint for Enterprise Networks,” http://www.cisco.com/go/safe. |
| 3. | Ibid. |