Top-Down Network Design

by Priscilla Oppenheimer

Network Design Checklists

Part I (Identifying Your Customer's Needs and Goals) of Top-Down Network Design presents some checklists that you can use while gathering information to help you develop a network design. You can fill out the following checklists as you gather design information. See the book for more detail on each checklist.

You can use the following checklists to determine if you have addressed your client’s objectives and concerns. If you can't gather every piece of data mentioned in the checklists, make sure you document what is missing in case it becomes critical, but don't stall the project to gather every last detail. The book teaches an ideal network design methodology that you should try to follow, but if real-world constraints, such as uncooperative network design customers, budget cuts, and time constraints, hamper your ability to follow the methodology precisely, just follow it as much as you can. In general, the methodology still works even if some data is missing after you do your analysis.

Chapter One: Analyzing Business Goals and Constraints

Business Goals Checklist

I have researched the customer’s industry and competition.

I understand the customer’s corporate structure.
I have compiled a list of the customer’s business goals, starting with one overall business goal that explains the primary purpose of the network design project.
The customer has identified any mission-critical operations.
I understand the customer’s criteria for success and the ramifications of failure.
I understand the scope of the network design project.
I have identified the customer’s network applications (using the Network Applications chart).
The customer has explained policies regarding approved vendors, protocols, or platforms.
The customer has explained any policies regarding open versus proprietary solutions.
The customer has explained any policies regarding distributed authority for network design and implementation.
I know the budget for this project.
I know the schedule for this project, including the final due date and major milestones, and I believe it is practical.
I have a good understanding of the technical expertise of my clients and any relevant internal or external staff.
I have discussed a staff-education plan with the customer.
I am aware of any office politics that might affect the network design.

 

Chapter Two: Analyzing Technical Goals and Tradeoffs

Technical Goals Checklist

I have documented the customer’s plans for expanding the number of sites, users, and servers for the next year and next two years.

The customer has told me about any plans to migrate departmental servers to a centralized data center.
The customer has told me about any plans to integrate data stored on a legacy mainframe with the enterprise network.
The customer has told me about any plans to implement an extranet to communicate with partners or other companies.
I have documented a goal for network availability in percent uptime and/or MTBF and MTTR.
I have documented any goals for maximum average network utilization.
I have documented goals for network throughput.
I have documented goals for packets per second (pps) throughput of internetworking devices.
I have documented goals for accuracy and acceptable BERs.
I have discussed with the customer the importance of using large frame sizes to maximize efficiency.
I have discussed with the customer the tradeoffs associated with large frame sizes and serialization delay.
I have identified any applications that have a more restrictive response-time requirement than the industry standard of less than 100 ms.
I have discussed network security risks and requirements with the customer.
I have gathered manageability requirements, including goals for performance, fault, configuration, security, and accounting management.
Working with my customer, I have developed a list of network design goals, including both business and technical goals. The list starts with one overall goal and includes the rest of the goals in priority order. Critical goals are marked as such.
I have updated the Network Applications chart to include the technical application goals shown in Table 2–2: Network Applications Technical Requirements.

 

Chapter Three: Characterizing the Existing Internetwork

Network Health Checklist

The network topology and physical infrastructure are well documented.

Network addresses and names are assigned in a structured manner and are well documented.
Network wiring is installed in a structured manner and is well labeled.
Network wiring has been tested and certified.
Network wiring between telecommunications closets and end stations is no more than 100 meters.
Network availability meets current customer goals.
Network security meets current customer goals.
No LAN or WAN segments are becoming saturated (70 percent average network utilization in a 10-minute window).
There are no collisions on Ethernet full-duplex links.
Broadcast traffic is less than 20 percent of all traffic on each network segment. (Some networks are more sensitive to broadcast traffic and should use a 10 percent threshold.)
Wherever possible and appropriate, frame sizes have been optimized to be as large as possible for the data-link layer in use.
No routers are overutilized. (Five-minute CPU utilization is under 75 percent.)
On average, routers are not dropping more than 1 percent of packets. (For networks that are intentionally oversubscribed to keep costs low, a higher threshold can be used.)
Up-to-date router, switch, and other device configurations have been collected, archived, and analyzed as part of the design study.
The response time between clients and hosts is generally less than 100 milliseconds (1/10 of a second).

 

Chapter Four: Characterizing Network Traffic

Network Traffic Checklist

I have identified major traffic sources and stores and documented traffic flow between them.

I have categorized the traffic flow for each application as being terminal/host, client/server, peer-to-peer, server/server, or distributed computing.
I have estimated the bandwidth requirements for each application.
I have estimated bandwidth requirements for routing protocols.
I have characterized network traffic in terms of broadcast/multicast rates, efficiency, frame sizes, windowing and flow control, and error-recovery mechanisms.
I have categorized the QoS requirements of each application.
I have discussed the challenges associated with implementing end-to-end QoS and the need for devices across the network to do their part in implementing QoS strategies.

 

Copyright Priscilla Oppenheimer.