NETWORK DESIGN METHODOLOGY
TOP-DOWN NETWORK DESIGN
1
Top-Down Network
Design, 3rd Edition
Priscilla Oppenheimer
Designing and
Supporting Computer
Networks (CCNA)
2
Four phases in the top-down network
design methodology




I: Identifying Your Customer's Needs and
Goals
II: Logical Network Design
III: Physical Network Design
IV: Testing, Optimizing, and Documenting
Your Network Design
3
PART 1
IDENTIFYING YOUR
CUSTOMER’S NEEDS
AND GOALS
 Analyzing Business Goals and Constraints
4
 Analyzing Technical Goals and Tradeoffs
 Characterizing the Existing Internetwork
 Characterizing Network Traffic
CHAPTER ONE
ANALYZING BUSINESS GOALS
AND CONSTRAINTS
Systematic, Top-down network
design methodology
 Analysing your customer’s
business objectives
 Analysing the business constrains;
budgets, timeframes, workplace
politics.

5
NETWORK DESIGN
 Good
network design must recognizes
customer’s requirements.
 Network design choices and tradeoffs must
be made when designing the logic network
before any physical devices are selected.
6
STRUCTURED NETWORK DESIGN
Four fundamental network design goals:
 Scalability
 Availability
 Security
 Manageability
7
STRUCTURED NETWORK DESIGN
 Core
Layer: connects Distribution Layer devices
 Distribution Layer: interconnects smaller LANs
 Access Layer: provides connections for hosts and
end devices
8
START FROM THE TOP
Layer 7
Application
Layer 6
Presentation
Layer 5
Session
Layer 4
Transport
Layer 3
Network
Layer 2
Data Link
Layer 1
Physical
9
10
SYSTEMS DEVELOPMENT LIFE CYCLES
(SDLC)
 Typical
systems are developed and
continue to exist over a period of time,
often called a systems development life
cycle (SDLC).
11
TOP-DOWN NETWORK DESIGN STEPS
systems
development life
cycle (SDLC).
Analyze
requirements
Monitor and
optimize
network
performance
Develop
logical
design
Develop
physical
design
Implement
and test
network
Test, optimize,
and document
design
12
THE PDIOO NETWORK LIFE CYCLE
Plan
Design
Implement
Operate
Optimize
Plan
Design
Retire
Optimize
Implement
Operate
13
NETWORK DESIGN STEPS
 Phase




1 – Analyze Requirements
Analyze business goals and constraints
Analyze technical goals and tradeoffs
Characterize the existing network
Characterize network traffic
14
NETWORK DESIGN STEPS
 Phase





2 – Logical Network Design
Design a network topology
Design models for addressing and naming
Select switching and routing protocols
Develop network security strategies
Develop network management strategies
15
NETWORK DESIGN STEPS
 Phase


3 – Physical Network Design
Select technologies and devices for campus
networks
Select technologies and devices for enterprise
networks
16
NETWORK DESIGN STEPS
 Phase
4 – Testing, Optimizing, and
Documenting the Network Design
Test the network design
 Optimize the network design
 Document the network design

17
BUSINESS GOALS
 Increase
revenue
 Reduce operating costs
 Improve communications
 Shorten product development cycle
 Expand into worldwide markets
 Build partnerships with other companies
 Offer better customer support or new
customer services
18
RECENT BUSINESS PRIORITIES
 Mobility
 Security
 Resiliency
(fault tolerance)
 Business continuity after a disaster
 Network projects must be prioritized based
on fiscal goals
 Networks must offer the low delay required
for real-time applications such as VoIP
19
BUSINESS CONSTRAINTS
 Budget
 Staffing
 Schedule
 Politics
and policies
20
COLLECT INFORMATION BEFORE THE
FIRST MEETING
 Before
meeting with the client, whether
internal or external, collect some basic
business-related information
 Such as
Products produced/Services supplied
 Financial viability
 Customers, suppliers, competitors
 Competitive advantage

21
MEET WITH THE CUSTOMER
 Try

to get
A concise statement of the goals of the
project
What problem are they trying to solve?
 How will new technology help them be more
successful in their business?
 What must happen for the project to
succeed?

22
MEET WITH THE CUSTOMER

Get a copy of the organization chart
This will show the general structure of the organization
 It will suggest users to account for
 It will suggest geographical locations to account for

23
MEET WITH THE CUSTOMER

Get a copy of the security policy
How does the policy affect the new design?
 How does the new design affect the policy?
 Is the policy so strict that you (the network designer)
won’t be able to do your job?


Start cataloging network assets that security
should protect
Hardware, software, applications, and data
 Less obvious, but still important, intellectual property,
trade secrets, and a company's reputation

24
THE SCOPE OF THE DESIGN PROJECT
 Small

Allow sales people to access network via a VPN
 Large

in scope?
An entire redesign of an enterprise network
 Use

in scope?
the OSI model to clarify the scope
New financial reporting application versus new routing
protocol versus new data link (wireless, for example)
 Does
the scope fit the budget, capabilities of staff
and consultants, schedule?
25
GATHER MORE DETAILED INFORMATION
 Applications


Now and after the project is completed
Include both productivity applications and
system management applications
 User
communities
 Data stores
 Protocols
 Current logical and physical architecture
 Current performance
26
SUMMARY
 Systematic
approach
 Focus first on business requirements and
constraints, and applications
 Gain an understanding of the customer’s
corporate structure
 Gain an understanding of the customer’s
business style
27
REVIEW QUESTIONS
 What
are the main phases of network design
per the top-down network design approach?
 What are the main phases of network design
per the PDIOO approach?
 Why is it important to understand your
customer’s business style?
 What are some typical business goals for
organizations today?
28
CHAPTER TWO
ANALYZING TECHNICAL GOALS
AND TRADEOFFS
29
Copyright 2010 Cisco Press & Priscilla Oppenheimer
TECHNICAL GOALS
 Scalability
 Availability
 Performance
 Security
 Manageability
 Usability
Your lab report should
reflect some of these goals
of your own designed
network.
 Adaptability
 Affordability
30
SCALABILITY
 Scalability
refers to the ability to grow
 Some technologies are more scalable

Flat network designs, for example, don’t scale
well
 Try




to learn
Number of sites to be added
What will be needed at each of these sites
How many users will be added
How many more servers will be added
31
32
33
AVAILABILITY
 Availability
can be expressed as a percent
uptime per year, month, week, day, or hour,
compared to the total time in that period

For example:
24/7 operation
 Network is up for 165 hours in the 168-hour week
 Availability is 98.21%

 Different
applications may require different
levels
 Some enterprises may want 99.999% or
“Five Nines” availability
34
AVAILABILITY
 Availability
can also be expressed as a
mean time between failure (MTBF) and
mean time to repair (MTTR)
 Availability = MTBF/(MTBF + MTTR)

For example:
 The network should not fail more than once
every 4,000 hours (166 days) and it should be
fixed within one hour
 4,000/4,001 = 99.98% availability
35
AVAILABILITY
DOWNTIME IN MINUTES
Per Hour
Per Day
Per Week
Per Year
99.999%
.0006
.01
.10
5
99.98%
.012
.29
2
105
99.95%
.03
.72
5
263
99.90%
.06
1.44
10
526
99.70%
.18
4.32
30
1577(26
H)
99.999% AVAILABILITY MAY
REQUIRE TRIPLE REDUNDANCY
ISP 1
ISP 2
ISP 3
Enterprise
 Can
the customer afford this?
37
SERVER FARMS
Many enterprise networks provide users with Internetaccessible services, such as email and e-commerce.
The availability and security of these services are
crucial to the success of a business.
Managing and securing numerous distributed servers at
various locations within a business network is difficult.
Recommended practice centralised servers in server
farms. Server farms are typically located in computer
rooms and data centres.
38
39
40
BENEFITS OF CREATING A SERVER FARM
1. Network traffic enters and leaves the server farm at a
defined point. This arrangement makes it easier to
secure, filter and prioritise traffic.
2. Redundant, high-capacity links can be installed to the
servers and between the server farm network and the
main LAN. This configuration is more cost-effective
than attempting to provide a similar level of connectivity
to servers distributed throughout the network.
3. Load balancing and failover can be provided between
servers and between networking devices.
4. The number of high-capacity switches and security
devices is reduced, helping to lower the cost of providing
41
services.
NETWORK PERFORMANCE
 Common
performance factors include
Bandwidth
 Throughput
 Bandwidth utilization
 Offered load
 Accuracy
 Efficiency
 Delay (latency) and delay variation
 Response time

42
BANDWIDTH VS. THROUGHPUT
 Bandwidth
and throughput are not the
same
 Bandwidth is the data carrying capacity of a
circuit, fixed.

Usually specified in bits per second-bps
 Throughput
is the quantity of error free
data transmitted per unit of time
Measured in bps, Bps, or packets per second (pps)
 Depend on offered load, access method and error rate


Throughput < Bandwidth
43
BANDWIDTH, THROUGHPUT, LOAD
100 % of Capacity
T
h
r
o
u
g
h
p
u
t
Actual
100 % of Capacity
Offered Load
44
OTHER FACTORS THAT AFFECT THROUGHPUT
The size of packets
 Inter-frame gaps between packets
 Packets-per-second ratings of devices that forward
packets
 Client speed (CPU, memory, and HD access speeds)
 Server speed (CPU, memory, and HD access speeds)
 Network design
 MAC Protocols (ALOHA 18.4%)
 Distance
 Errors
 Time of day, etc., etc., etc.

45
THROUGHPUT VS. GOODPUT
 Are
you referring to bytes per second,
regardless of whether the bytes are user
data bytes or packet header bytes

Or are you concerned with application-layer
throughput of user bytes, sometimes called
“goodput”

In that case, you have to consider that bandwidth is
being “wasted” by the headers in every packet
46
PERFORMANCE (CONTINUED)
 Efficiency


How much overhead is required to deliver an
amount of data?
How large can packets be?
Larger better for efficiency (and goodput)
 But too large means too much data is lost if a packet is
damaged
 How many packets can be sent in one bunch without an
acknowledgment?

47
EFFICIENCY
Small Frames (Less Efficient)
Large Frames (More Efficient)
48
DELAY FROM THE USER’S POINT OF
VIEW
 Response


Time
A function of the
application and the
equipment the
application is
running on, not just
the network
Most users expect to
see something on the
screen in 100 to 200
milliseconds
49
DELAY FROM THE ENGINEER’S POINT
OF VIEW
 Propagation

delay
A signal travels in a cable at about 2/3 the speed
of light in a vacuum (3×108 m/s)
 Transmission
delay (also known as
serialization delay)

Time to put digital data onto a transmission line

For example, it takes about 5 ms to output a 1,024 byte
packet on a 1.544 Mbps T1 line
 Packet-switching
 Queuing
delay
delay
50
Average Queue Depth
QUEUING DELAY AND BANDWIDTH UTILIZATION
15
12
9
6
3
0
0.5
0.6
0.7
0.8
0.9
Average Utilization


Number of packets in a queue increases exponentially
as utilization increases
Queue depth = utilization/(1- utilization)
1
EXAMPLE
A
packet switch has 5 users, each offering
packets at a rate of 10 packets per second
 The average length of the packets is 1,024 bits
 The packet switch needs to transmit this data
over a 56-Kbps WAN circuit



Load = 5 x 10 x 1,024 = 51,200 bps
Utilization = 51,200/56,000 = 91.4%
Average number of packets in queue =
(0.914)/(1-0.914) = 10.63 packets
52
SECURITY
 Focus
on requirements first
 Detailed security planning later (Chapter
8)
 Identify network assets

Including their value and the expected cost
associated with losing them due to a security
problem
 Analyze
security risks
53
MANAGEABILITY
 Fault
management
 Configuration management
 Accounting management
 Performance management
 Security management
54
USABILITY
 Usability:
the ease of use with which
network users can access the network and
services
 Networks should make users’ jobs easier
 Some design decisions will have a
negative affect on usability:

Strict security, for example
55
ADAPTABILITY
 Avoid
incorporating any design elements
that would make it hard to implement new
technologies in the future
 Change can come in the form of new
protocols, new business practices, new fiscal
goals, new legislation
 A flexible design can adapt to changing
traffic patterns and Quality of Service (QoS)
requirements
56
AFFORDABILITY
A
network should carry the maximum
amount of traffic possible for a given
financial cost
 Affordability is especially important in
campus network designs
 WANs are expected to cost more, but costs
can be reduced with the proper use of
technology

Quiet routing protocols, for example
57
MAKING TRADEOFFS (EXAMPLE)
 Scalability
 Availability
 Network
performance
 Security
 Manageability
 Usability
 Adaptability
 Affordability
Total (must add up to 100)
20
30
15
5
5
5
5
15
100
58
SUMMARY
 Continue
to use a systematic, top-down
approach
 Don’t select products until you understand
goals for scalability, availability, performance,
security, manageability, usability,
adaptability, and affordability
 Tradeoffs are almost always necessary
59
REVIEW QUESTIONS
 What
are some typical technical goals for
organizations today?
 How do bandwidth and throughput differ?
 How can one improve network efficiency?
 What tradeoffs may be necessary in order to
improve network efficiency?
60
CHAPTER THREE
CHARACTERIZING THE
EXISTING INTERNETWORK
61
Copyright 2010 Cisco Press & Priscilla Oppenheimer
WHAT’S THE STARTING POINT?
 According

to Abraham Lincoln:
“If we could first know where we are and whither
we are tending, we could better judge what to do
and how to do it.”
62
WHERE ARE WE?
 Characterize
the exiting internetwork in
terms of:

Its infrastructure
Logical structure (modularity, hierarchy, topology)
 Physical structure

Addressing and naming
 Wiring and media
 Architectural and environmental constraints
 Health

63
DIAGRAM A PHYSICAL NETWORK AND
DOCUMENT THE EXISTING NETWORK
Network documentation:
 Logical and physical diagrams
 Floor plans
 Complete lists for equipments and
applications
 Current network configuration files
GET A NETWORK MAP (PHYSICAL)
Medford
Fast Ethernet
50 users
Roseburg
Fast Ethernet
30 users
Frame Relay
CIR = 56 Kbps
DLCI = 5
Frame Relay
CIR = 56 Kbps
DLCI = 4
Grants Pass
HQ
Gigabit
Ethernet
Gigabit
Ethernet
Grants Pass
HQ
Fast Ethernet
75 users
FEP
(Front End
Processor)
IBM
Mainframe
T1
Web/FTP server
Eugene
Ethernet
20 users
T1
Internet
65
DIAGRAM A PHYSICAL NETWORK AND
DOCUMENT THE EXISTING NETWORK
 Identify
and document the strengths and
weaknesses of the existing network
 Focus on finding ways to overcome
weaknesses
67
CHARACTERIZE ADDRESSING
NAMING
AND
 IP
addressing for major devices, client
networks, server networks, and so on
 Any addressing oddities, such as
discontiguous subnets?
 Any strategies for addressing and naming?

For example, sites may be named using airport
codes
San Francisco = SFO, Oakland = OAK
 In LSBU, T-tower block; K-keyworth building; BBorough road building; L- london road building

68
DISCONTINUOUS SUBNETS – make
problems for some routing protocols
Area 0
Network
192.168.49.0
Router A
Area 1
Subnets 10.108.16.0 10.108.31.0
Router B
Area 2
Subnets 10.108.32.0 10.108.47.0
69
CHARACTERIZE THE WIRING AND MEDIA
 Single-mode
fiber
 Multi-mode fiber
 Shielded twisted pair (STP) copper
 Unshielded-twisted-pair (UTP) copper
 Coaxial cable
 Microwave
 Laser
 Radio
 Infra-red
70
ARCHITECTURAL CONSTRAINTS
 Make






sure the following are sufficient
Air conditioning
Heating
Ventilation
Power
Protection from electromagnetic interference
Doors that can lock
71
ARCHITECTURAL CONSTRAINTS
 Make
sure there’s space for:
Cabling conduits
 Patch panels
 Equipment racks
 Work areas for technicians installing and
troubleshooting equipment

72
73
CHECK THE HEALTH OF THE
EXISTING INTERNETWORK
 Performance
 Availability
 Bandwidth
utilization
 Accuracy
 Efficiency
 Response
time
 Status of major routers, switches, and
firewalls
74
CHARACTERIZE AVAILABILITY
MTBF
MTTR
Date and Duration
of Last Major
Downtime
Cause of Last
Major
Downtime
Fix for Last
Major
Downtime
Enterprise
Segment 1
Segment 2
Segment n
Mean time between failures (MTBF)
Mean time to recovery (MTTR)
75
NETWORK UTILIZATION IN MINUTE
INTERVALS
Network Utilization
16:40:00
16:43:00
16:46:00
16:49:00
Time
16:52:00
16:55:00
Series1
16:58:00
17:01:00
17:04:00
17:07:00
17:10:00
0
1
2
3
4
Utilization
5
6
7
76
NETWORK UTILIZATION IN HOUR
INTERVALS
Network Utilization
13:00:00
Time
14:00:00
15:00:00
Series1
16:00:00
17:00:00
0
0.5
1
1.5
2
2.5
3
3.5
4
4.5
Utilization
77
BANDWIDTH UTILIZATION BY
PROTOCOL
Relative
Network
Utilization
Absolute
Network
Utilization
Broadcast
Rate
Multicast
Rate
Protocol 1
Protocol 2
Protocol 3
Protocol n
78
CHARACTERIZE PACKET SIZES
79
CHARACTERIZE RESPONSE TIME
Node A
Node A
Node B
Node C
Node D
Node B
Node C
Node D
X
X
X
X
80
CHECK THE STATUS OF MAJOR ROUTERS,
SWITCHES, AND FIREWALLS
 show
buffers
 show environment
 show interfaces
 show memory
 show processes
 show running-config
 show version
Use Cisco
IOS show
command
81
TOOLS
 Protocol
analyzers
 Multi Router Traffic Grapher (MRTG)
 Remote monitoring (RMON) probes
 Cisco Discovery Protocol (CDP)
 Cisco IOS NetFlow technology
 CiscoWorks
82
SUMMARY
 Characterize
the exiting internetwork before
designing enhancements
 Helps you verify that a customer’s design
goals are realistic
 Helps you locate where new equipment will go
 Helps you cover yourself if the new network
has problems due to unresolved problems in
the old network
83
REVIEW QUESTIONS
 What
factors will help you decide if the
existing internetwork is in good enough shape
to support new enhancements?
 When considering protocol behavior, what is
the difference between relative network
utilization and absolute network utilization?
 Why should you characterize the logical
structure of an internetwork and not just the
physical structure?
 What architectural and environmental factors
should you consider for a new wireless
84
installation?
CHAPTER FOUR
CHARACTERIZING NETWORK
TRAFFIC
85
Copyright 2010 Cisco Press & Priscilla Oppenheimer
NETWORK TRAFFIC FACTORS
 Traffic
flow
 Location of traffic sources and data stores
 Traffic load
 Traffic behavior
 Quality of Service (QoS) requirements
86
USER COMMUNITIES, a set of worker who use
a particular application or set of applications.
User
Community
Name
Size of
Community
(Number of
Users)
Location(s) of
Community
Application(s)
Used by
Community
87
DATA STORES (SINKS), an area in a network
where application layer data resides. Server, or any
device where large quantities of data are stored.
Data Store
Location
Application(s) Used by User
Community(or
Communities)
88
TRAFFIC FLOW, involves identifying and
characterizing individual traffic flows between
traffic source and stores.
Destination 1
MB/sec
Destination 2
MB/sec
Destination 3
MB/sec
Destination
MB/sec
Source 1
Source 2
Source 3
Source n
89
TRAFFIC FLOW
EXAMPLE
App 2
App 3
App 4
App 9
Total
20
96
24
80
220
Library and Computing Center
30 Library Patrons (PCs)
30 Macs and 60 PCs in
Computing Center
Server Farm
Kbps
Kbps
Kbps
Kbps
Kbps
10-Mbps Metro
Ethernet to Internet
App 1
App 2
App 3
App 4
App 7
Total
108
60
192
48
400
808
25 Macs
50 PCs
50 PCs
Arts and
Humanities
Administration
App 1
App 2
App 3
App 4
Total
30 PCs
Business and
Social Sciences
Kbps
Kbps
Kbps
Kbps
Kbps
Kbps
30
20
60
16
126
Kbps
Kbps
Kbps
Kbps
Kbps
App 1
48 Kbps
App 2
32 Kbps
App 3
96 Kbps
App 4
24 Kbps
App 5 300 Kbps
App 6 200 Kbps
App 8 1200 Kbps
Total 1900 Kbps
Math and
Sciences
50 PCs
90
TYPES OF TRAFFIC FLOW
 Terminal/host
 Client/server
 Thin
client
 Peer-to-peer
 Server/server
 Distributed computing
91
TRAFFIC FLOW FOR VOICE OVER IP
 The
flow associated with
transmitting the audio voice is
separate from the flows
associated with call setup and
teardown.


The flow for transmitting the digital
voice is essentially peer-to-peer.
Call setup and teardown is a
client/server flow

A phone needs to talk to a server or phone
switch that understands phone numbers,
IP addresses, capabilities negotiation, and
so on.
92
IDENTIFYING APPLICATION IMPACTS
ON NETWORK DESIGN
File transfer and email applications:
 Unpredictable bandwidth usage
 Large packet size
 Centralization of file and mail servers in a
secure location
 Redundancy to ensure reliable service
IDENTIFYING APPLICATION IMPACTS
ON NETWORK DESIGN
HTTP and web traffic:
 Network media
 Redundancy
 Security
NETWORK APPLICATIONS
TRAFFIC CHARACTERISTICS
Name of
Type of
Application Traffic
Flow
Protocol(s)
Used by
Application
User
Communities
That Use the
Application
Data Stores
Approximate
(Servers, Hosts, Bandwidth
and so on)
Requirements
QoS
Requirements
95
TRAFFIC LOAD
 To
calculate whether capacity is sufficient,
you should know:



The number of stations
The average time that a station is idle between
sending frames
The time required to transmit a message once
medium access is gained
 That
level of detailed information can be
hard to gather, however
96
SIZE OF OBJECTS ON NETWORKS
 Terminal
screen: 4 Kbytes
 Simple e-mail: 10 Kbytes
 Simple web page: 50 Kbytes
 High-quality image: 50Mbytes
 Database backup: 1Gbytes or more
97
TRAFFIC BEHAVIOR
 Broadcasts

All ones data-link layer destination address

FF: FF: FF: FF: FF: FF
Doesn’t necessarily use huge amounts of bandwidth
 But does disturb every CPU in the broadcast domain

 Multicasts

First bit sent is a one

01:00:0C:CC:CC:CC (Cisco Discovery Protocol)
Should just disturb NICs that have registered to
receive it
 Requires multicast routing protocol on internetworks

98
NETWORK EFFICIENCY
 Frame
size
 Protocol interaction
 Windowing and flow control
 Error-recovery mechanisms
99
QOS REQUIREMENTS
 ATM






service specifications
Constant bit rate (CBR)
Realtime variable bit rate (rt-VBR)
Non-realtime variable bit rate (nrt-VBR)
Unspecified bit rate (UBR)
Available bit rate (ABR)
Guaranteed frame rate (GFR)
100
QOS REQUIREMENTS
PER
IETF
(Internet Engineering Task Force, develops and
promotes Internet standards, It is an open
standards organization, with no formal
membership or membership requirements.)
 IETF
integrated services working group
specifications

Controlled load service


Provides client data flow with a QoS closely
approximating the QoS that same flow would receive
on an unloaded network
Guaranteed service

Provides firm (mathematically provable) bounds on
end-to-end packet-queuing delays
101
QOS REQUIREMENTS
PER
IETF
 IETF
differentiated services working
group specifications


RFC 2475
IP packets can be marked with a differentiated
services codepoint (DSCP) to influence queuing
and packet-dropping decisions for IP
datagrams on an output interface of a router
102
HOW QUALITY OF SERVICE IS
IMPLEMENTED ON THE LAN/WAN
Where QoS can be implemented to affect
traffic flow:
 Layer 2 devices
 Layer 3 devices
DOCUMENT THE NETWORK
REQUIREMENTS OF SPECIFIC
CATEGORIES OF APPLICATIONS
 Estimate
the volume of application traffic
during the initial design phase.
 Document projected applications and
associated hardware in a network diagram.
SUMMARY
 Continue
to use a systematic, top-down
approach
 Don’t select products until you understand
network traffic in terms of:
Flow
 Load
 Behavior
 QoS requirements

105
REVIEW QUESTIONS
 List
and describe six different types of traffic
flows.
 What makes traffic flow in voice over IP
networks challenging to characterize and plan
for?
 Why should you be concerned about broadcast
traffic?
 How do ATM and IETF specifications for QoS
differ?
106
OF
PART 1
107