You are on page 1of 4

Top-Down Network Design Tools

Page 1 of 4

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
c d e f g c d e f g

I have researched the customer’s industry and competition. I understand the customer’s corporate structure.

c I have compiled a list of the customer’s business goals, starting with one overall business goal that d e f g explains the primary purpose of the network design project. c d e f g c d e f g c d e f g c d e f g c d e f g c d e f g

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.

c The customer has explained any policies regarding distributed authority for network design and d e f g implementation. c d e f g

I know the budget for this project.


users. c d e f g c d e f g I have discussed a staff-education plan with the customer. and servers for the d e f g next year and next two years. c d e f g c d e f g c d e f g c d e f g c d e f g c d e f g c d e f g c d e f g I have documented a goal for network availability in percent uptime and/or MTBF and MTTR. http://www. including the final due date and major milestones.html 17/10/2010 . Chapter Two: Analyzing Technical Goals and Tradeoffs Technical Goals Checklist c I have documented the customer’s plans for expanding the number of sites. and I believe d e f g it is practical. c I have identified any applications that have a more restrictive response-time requirement than the d e f g industry standard of less than 100 ms.Top-Down Network Design Tools Page 2 of 4 c I know the schedule for this project. I am aware of any office politics that might affect the network design. I have documented goals for network throughput. c d e f g The customer has told me about any plans to implement an extranet to communicate with partners or other companies.topdownbook. I have documented goals for packets per second (pps) throughput of internetworking devices. I have documented goals for accuracy and acceptable BERs. The customer has told me about any plans to migrate departmental servers to a centralized data I have discussed with the customer the tradeoffs associated with large frame sizes and serialization delay. c I have a good understanding of the technical expertise of my clients and any relevant internal or d e f g external staff. c d e f g I have discussed network security risks and requirements with the customer. c The customer has told me about any plans to integrate data stored on a legacy mainframe with the d e f g enterprise network. I have documented any goals for maximum average network utilization. I have discussed with the customer the importance of using large frame sizes to maximize efficiency.

Top-Down Network Design Tools Page 3 of 4 c I have gathered manageability requirements. Network security meets current customer goals. d e f g security. Network wiring between telecommunications closets and end stations is no more than 100 meters. Network wiring has been tested and certified. c No LAN or WAN segments are becoming saturated (70 percent average network utilization in a 10d e f g minute window). and other device configurations have been collected.) Up-to-date router. routers are not dropping more than 1 percent of packets. c Working with my customer. including both business d e f g and technical goals. frame sizes have been optimized to be as large as possible for the data-link layer in use. Critical goals are marked as such. and analyzed as part of the design study. I have updated the Network Applications chart to include the technical application goals shown in Table 2–2: Network Applications Technical Requirements.topdownbook. c d e f g c d e f g No routers are overutilized. c d e f g There are no collisions on Ethernet full-duplex links. archived. Network wiring is installed in a structured manner and is well labeled. c d e f g http://www.html 17/10/2010 . The list starts with one overall goal and includes the rest of the goals in priority order. (Five-minute CPU utilization is under 75 percent. I have developed a list of network design goals. configuration.) Wherever possible and appropriate. and accounting including goals for performance. a higher threshold can be used. Network addresses and names are assigned in a structured manner and are well documented. switch. Network availability meets current customer goals. c Broadcast traffic is less than 20 percent of all traffic on each network segment. c d e f g Chapter Three: Characterizing the Existing Internetwork Network Health Checklist c d e f g c d e f g c d e f g c d e f g c d e f g c d e f g c d e f g The network topology and physical infrastructure are well documented. (For networks that are d e f g intentionally oversubscribed to keep costs low.) c On average. fault. (Some networks are d e f g more sensitive to broadcast traffic and should use a 10 percent threshold.

c d e f g c d e f g I have estimated the bandwidth requirements for each application. peer-tod e f g peer. Copyright Priscilla Oppenheimer. and error-recovery mechanisms. c d e f g I have categorized the QoS requirements of each application. http://www. c I have discussed the challenges associated with implementing end-to-end QoS and the need for d e f g devices across the network to do their part in implementing QoS strategies. d e f g windowing and flow control. or distributed computing. c I have categorized the traffic flow for each application as being terminal/host. Back to the Top-Down Network Design Resources page. server/server. Chapter Four: Characterizing Network Traffic Network Traffic Checklist c d e f g I have identified major traffic sources and stores and documented traffic flow between them.Top-Down Network Design Tools Page 4 of 4 c The response time between clients and hosts is generally less than 100 milliseconds (1/10 of a d e f g second). Back to the Top-Down Network Design home page.html 17/10/2010 .com/checklists. client/server. c I have characterized network traffic in terms of broadcast/multicast rates.topdownbook. efficiency. I have estimated bandwidth requirements for routing protocols. frame sizes. Hosted by Open Door Networks.