Network Design

Part 2

1
 Characterizing the
Existing Internetwork
• Characterize the existing internetwork before
designing enhancements
• Helps to verify that a network design goals are
realistic
• Helps to locate where new equipment will go
• Helps to discover if the new network has
problems due to unresolved problems in the old
network
• Most network designers do not design networks
from scratch. Instead, they design enhancements
to existing networks.
2
 Characterizing the
Existing Internetwork
• Characterize the existing internetwork in
terms of:
– Its infrastructure
• Logical structure (modularity, hierarchy, topology)
• Physical structure
– Addressing and naming
– Wiring and media
– Architectural and environmental constraints
– Health

3
 Developing a Network Map
• Learning the location of major hosts,
interconnection devices, and network
segments is a good way to start developing an
understanding of traffic flow.
• Obtain a map (or set of maps) of the existing
network.
• Use a good network-diagramming tool e.g.
Microsoft Visio Professional

4
Characterizing Large Internetworks
• Developing a single network map might not be possible for large
internetworks.
• There are many approaches to solving this problem, including
simply developing many maps, one for each location.
• Another approach is to apply a top-down method. Start with a map
or set of maps that shows the high-level information:
– Geographical information, such as countries, states or provinces, cities,
and campuses
– WAN connections between countries, states, and cities
– WAN and LAN connections between buildings and between campuses
• For each campus network, you can develop more precise maps that
show the following more detailed information:
– Buildings and floors - The location of major servers - The location of
routers and switches - The location of firewalls, Network Address
Translation (NAT) devices, intrusion detection systems (IDS), and
intrusion prevention systems (IPS) - The location and reach of virtual
LANs (VLAN) …
5
 Characterize Addressing and
Naming
• When drawing detailed network maps, include
the names of major sites, routers, network
segments, and servers.
• Also document any standard strategies are used
for naming network elements (e.g. RTR for
router).
• Check if a standard naming system is used,
such as DNS, for IP networks, or NetBIOS
Windows Internet Naming Service (WINS) on
Windows networks
– document the location of the DNS and WINS
servers and relevant high-level configuration
information
6
 Characterize Addressing and
Naming
• Investigate the network layer addresses
• The addressing scheme (or lack of any scheme) can
influence the ability to adapt the network to new
design goals.
– Current IP subnet masking might limit the number of
nodes in a LAN or VLAN
• Route summarization is used
– Route summarization reduces routes in a routing table,
routing-table update traffic, and overall router
overhead.
– Route summarization also improves network stability
and availability, because problems in one part of a
network are less likely to affect the whole
internetwork.
7
Characterizing Wiring and Media
• Documenting the existing cabling design can
help to plan for enhancements and identify any
potential problems.
• If possible, document the types of cabling in
use as well as cable distances.
• Distance information is useful when selecting
data link layer technologies based on distance
restrictions.
• Distance information can help to select new
cabling. For example, to upgrade from copper
to fiber cabling, the distance between buildings
can be much longer.
8
Characterize the Wiring and Media
• Single-mode fiber
• Multi-mode fiber
• Shielded twisted pair (STP) copper
• Unshielded-twisted-pair (UTP) copper
• Coaxial cable
• Radio
• …

9
 Architectural Constraints
• Make sure the following are sufficient
– Air conditioning
– Heating
– Ventilation
– Power
– Protection from electromagnetic interference
– Space and work areas

10
 Checking the Health of the Existing
Internetwork
• Studying the performance of the existing
internetwork gives a baseline measurement from
which to measure new network performance.
• Armed with measurements of the present
internetwork, you can demonstrate to your customer
how much better the new internetwork performs
once your design is implemented.
• By capturing network traffic with a protocol
analyzer as part of your baseline analysis, you can
identify which protocols are actually running on the
network

11
Check the Health of the Existing
Internetwork
• Performance
• Availability
• Bandwidth utilization
• Accuracy
• Efficiency
• Response time
• Status of major routers, switches, and
firewalls
12
 Characterize Availability

mean time mean time Date and Cause of Fix for Last
between to repair Duration of Last Major Major
failure (MTTR) Last Major Downtime Downtime
(MTBF) Downtime

Enterprise
(as a whole)
Segment 1
Segment 2
Segment n

13
 Network Utilization in Minute
Intervals
16:40:00
16:43:00
16:46:00
16:49:00
16:52:00
Time

16:55:00
16:58:00
17:01:00
17:04:00
17:07:00
17:10:00
0 1 2 3 4 5 6 7
Utilization

14
 Network Utilization in Hour
Intervals

13:00:00

14:00:00
Time

15:00:00

16:00:00

17:00:00

0 0.5 1 1.5 2 2.5 3 3.5 4 4.5

Utilization

15
 Bandwidth Utilization by
Protocol
• Some protocols send excessive broadcast traffic, which can
seriously degrade performance, especially on switched networks
• Relative usage specifies how much bandwidth is used by the
protocol in comparison to the total bandwidth currently in use on
the segment.
• Absolute usage specifies how much bandwidth is used by the
protocol in comparison to the total capacity of the segment (for
example, in comparison to 100 Mbps on Fast Ethernet)

Relative Network Absolute Network Broadcast Multicast

Utilization Utilization Rate Rate
Protocol 1
Protocol 2
Protocol 3
Protocol n
16
 Analyzing Network Efficiency-
Characterize Packet Sizes
• Use a protocol analyzer to examine the current frame sizes
on the network.
• Many protocol analyzers let you output a chart, such as the
one below, that documents how many frames fall into
standard categories for frame sizes

17
 Analyzing Network Efficiency-
Characterize Packet Sizes
• Analyzing frame sizes can help to understand the health of a network, not just the efficiency.
• For example, an excessive number of Ethernet runt frames (less than 64 bytes) can indicate too
many collisions on a shared Ethernet segment.
• It is normal for collisions to increase with utilization that results from access contention.
• If collisions increase even when utilization does not increase or even when only a few nodes are
transmitting, there could be a more serious problem, such as a bad NIC or a duplex mismatch
problem.

18
 Analyzing Delay and Response
Time
• To verify that performance of a new network
design meets the requirements, response time
needs to be measured between significant
network devices before and after a new network
design is implemented.
• Response time can be measured many ways:
– Using a protocol analyzer
– A more common way to measure response time is to
send ping packets and measure the round-trip time
(RTT) to send a request and receive a response.
19
 Analyzing Delay and Response
Time
Node A Node B Node C Node D

Node A X

Node B X

Node C X

Node D X

20
 Check the Status of Major
Routers, Switches, and Firewalls
• Checking the behavior and health of an
internetworking device includes:
– determining how busy the device is (CPU
utilization),
– how many packets it has processed,
– how many packets it has dropped,
– and the status of buffers and queues.

21
 Check the Status of Major
Routers, Switches, and Firewalls
• show buffers: Displays information on buffer sizes, buffer creation and
deletion, buffer usage, and a count of successful and unsuccessful attempts to
get buffers when needed.
• show interfaces: Displays statistics for interfaces, including the input and
output rate of packets, a count of packets dropped from input and output
queues, the size and usage of queues, a count of packets ignored due to lack of
I/O buffer space on a card, CRC errors, collision counts, and how often
interfaces have restarted.
• show memory: Displays statistics about system memory, including total
bytes, used bytes, and free bytes.
• show processes: Displays CPU utilization for the last 5 seconds, 1 minute, and
5 minutes, and the percentage of CPU used by various processes, including
routing protocol processes, buffer management, and user-interface processes.
• show running-config: Displays the router’s configuration stored in memory
and currently in use.
• show startup-config: Displays the configuration the router will use upon the
next reboot.

22
 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 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.
23
 Network Health Checklist
• Broadcast traffic is less than 20 percent of all traffic on each
network segment.
• 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 overused (5-minute CPU utilization is under 75
percent).
• On average, routers are not dropping more than 1 percent of
packets.
• 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 ms.

24
 Characterizing Traffic Flow
• Characterizing traffic flow involves:
– identifying sources and destinations of network traffic
– and analyzing the direction and symmetry of data traveling between
sources and destinations.
• Direction specifies whether data travels in both directions or in just
one direction. Direction also specifies the path that a flow takes as
it travels from source to destination through an internetwork.
• Symmetry describes whether the flow tends to have higher
performance or QoS requirements in one direction than the other
direction.
• In some applications, the flow is bidirectional and symmetric. (Both
ends of the flow send traffic at about the same rate.)
• In other applications, the flow is bidirectional and asymmetric.
(Clients send small queries and servers send large streams of data.)
• In a broadcast application, the flow is unidirectional and asymmetric.

25
 Identifying Major Traffic Sources
and Stores
• To understand network traffic flow, identify
user communities and data stores for existing
and new applications.
• A user community is a set of workers who use
a particular application or set of applications.
• It is necessary to characterize user communities
by application and protocol usage rather than
by departmental boundary.

26
 User Communities

User Community Size of Location(s) of Application(s)

Name Community Community Used by
(Number of Community
Users)

27
 Identifying Major Traffic Sources
and Stores
• In addition to documenting user communities, characterizing
traffic flow also requires documentation of major data
stores.
• A data store (sometimes called a data sink) is an area in a
network where application layer data resides. A data store
can be a server, a server farm, a storage-area network
(SAN), or any device or component of an internetwork
where large quantities of data are stored.
Data Store Location Application(s) Used by User
Community(or
Communities)

28
 Documenting Traffic Flow on the
Existing Network
• Documenting traffic flow involves identifying
and characterizing individual traffic flows
between traffic sources and stores.
• Measuring traffic flow behavior can help
network designers do the following:
– Characterize the behavior of existing networks.
– Plan for network development and expansion.
– Quantify network performance.
– Verify the quality of network service.
– Ascribe network usage to users and applications.
29
 Documenting Traffic Flow on the
Existing Network
• An individual network traffic flow can be defined
as protocol and application information
transmitted between communicating entities
during a single session.
• A flow has attributes such as
– direction,
– symmetry,
– routing path and routing options,
– number of packets,
– number of bytes,
– and addresses for each end of the flow.
30
 Documenting Traffic Flow on the
Existing Network
• The simplest method for characterizing the size of
a flow is to measure the number of megabytes per
second (MBps) between communicating entities.
• To characterize the size of a flow, use a protocol
analyzer or network management system to record
load between important sources and destinations.
• Cisco NetFlow collects and measures data as it
enters router and switch interfaces, including
source and destination IP addresses, source and
destination TCP or UDP port numbers, packet and
byte counts, and so on.
31
 Documenting Traffic Flow on the
Existing Network
Destination 1 Destination 2 Destination 3 Destination n
MBps Path MBps Path MBps Path MBps Path

Source 1

Source 2
Source 3
Source n

32
 Library and Computing Center
Traffic Flow 30 Library Patrons (PCs) 10-Mbps Metro

Example 30 Macs and 60 PCs in

Computing Center
Ethernet to Internet

Server Farm
App 1 108 Kbps
App 2 20 Kbps App 2 60 Kbps
App 3 96 Kbps App 3 192 Kbps
App 4 24 Kbps App 4 48 Kbps
App 9 80 Kbps App 7 400 Kbps
Total 220 Kbps Total 808 Kbps

50 PCs 25 Macs
50 PCs

Administration Arts and

App 1 30 Kbps
Humanities
App 2 20 Kbps App 1 48 Kbps
App 3 60 Kbps App 2 32 Kbps
App 4 16 Kbps App 3 96 Kbps
Total 126 Kbps App 4 24 Kbps
App 5 300 Kbps Math and
App 6 200 Kbps
App 8 1200 Kbps Sciences
30 PCs Total 1900 Kbps 50 PCs

Business and
Social Sciences 33
 Types of Traffic Flow
• Terminal/host
– Terminal/host traffic is usually asymmetric. The terminal sends a few characters
and the host sends many characters. Telnet is an example of an application that
generates terminal/ host traffic.
• Client/server
– Client/server traffic is the best-known and most widely used flow type. Clients
send queries and requests to a server. The server responds with data or
permission for the client to send data. The flow is usually bidirectional and
asymmetric. HTTP is the most widely used client/server protocol. Clients use a
web browser application, such as Firefox, to talk to web servers.
• Peer-to-peer
– The flow is usually bidirectional and symmetric. Communicating entities
transmit approximately equal amounts of information. There is no hierarchy.
Each device is considered as important as each other device, and no device
stores substantially more data than any other device.
– Peer-to-peer applications for downloading music, videos, and software have
gained popularity. Each user publishes music or other material and allows other
users on the Internet to download the data. This is considered peer-to-peer
traffic because every user acts as both a distributor and consumer of data.

34
 Types of Traffic Flow
• Server/server
– With server/server network traffic, the flow is generally bidirectional.
The symmetry of the flow depends on the application. With most
server/server applications, the flow is symmetrical, but in some cases
there is a hierarchy of servers, with some servers sending and storing
more data than others.
– Servers talk to other servers to cache heavily used data, to mirror data
for load balancing and redundancy, to back up data, ...
• Distributed computing
– Distributed computing refers to applications that require multiple
computing nodes working together to complete a job.
– With distributed computing, data travels between a task manager and
computing nodes and between computing nodes.

35
 Network Applications
Traffic Characteristics

Name of Type of Protocol(s) User Data Stores Approximate QoS

Application Traffic Used by Communities (Servers, Bandwidth Requirements
Flow Application That Use the Hosts, and so Requirements
Application on)

36
 Characterizing Traffic Load
• Traffic load (sometimes called offered load) is the sum of all the data
all network nodes have ready to send at a particular time.
• A general goal for most network designs is that the network capacity
should be more than adequate to handle the traffic load.
• Because of the many factors involved in characterizing network
traffic, traffic load estimates are unlikely to be precise.
• The goal is simply to avoid a design that has any critical bottlenecks.
• To avoid bottlenecks, designer can research
– application-usage patterns,
– idle times between packets and sessions,
– frame sizes,
– and other traffic behavioral patterns for application and system
protocols.
• Another approach to avoiding bottlenecks is simply to throw large
amounts of bandwidth at the problem (also known as
overprovisioning).
37
 Estimating Traffic Load Caused
by Routing Protocols
• A router sending a large distance-vector
routing table every half minute can use a
significant percentage of WAN bandwidth.
• Because routing protocols limit the number of
routes per packet, on large networks, a router
sends multiple packets to send the entire table.
• Routing Information Protocol (RIP), for
example, sends a routing packet every 30
seconds.
38
 Estimating Traffic Load Caused
by Routing Protocols
• Newer routing protocols, such as Open Shortest Path First
(OSPF) and Enhanced Interior Gateway Routing Protocol
(EIGRP), use little bandwidth.
• In the case of OSPF, the main concern should be the amount
of bandwidth consumed by the database-synchronization
packets that routers send every 30 minutes.
• By subdividing an OSPF network into areas and using route
summarization, this traffic can be minimized.
• Other than the database synchronization traffic, the only
traffic OSPF sends after initialization is small Hello packets
every 10 seconds.
• EIGRP also sends Hello packets but more frequently than
OSPF (every 5 seconds). On the other hand, EIGRP doesn’t
send any periodic route updates or database-synchronization
packets. It sends route updates only when there are changes.
39
 Traffic Behavior
• A broadcast frame is a frame that goes to all network
stations on a LAN.
– At the data link layer, the destination address of a broadcast
frame is FF:FF:FF:FF:FF:FF (all 1s in binary).
• A multicast frame is a frame that goes to a subset of stations.
– First bit sent is a one in destination physical address
• Layer 2 internetworking devices, such as switches and
bridges, forward broadcast and multicast frames out all
ports.
• The forwarding of broadcast and multicast frames can be a
scalability problem for large flat (switched or bridged)
networks.
• A router does not forward broadcasts or multicasts. All
devices on one side of a router are considered part of a
single broadcast domain.
40
 Traffic Behavior
• In addition to including routers in a network
design to decrease broadcast forwarding, designer
can also limit the size of a broadcast domain by
implementing virtual LANs (VLAN).
• Too many broadcast frames can overwhelm end
stations, switches, and routers. It is important to
research the level of broadcast traffic in the
proposed design and limit the number of stations
in a single broadcast domain.
• If more than 20 percent of the network traffic is
broadcasts or multicasts, the network needs to be
segmented using routers or VLANs.
41
 Network Efficiency
• Characterizing network traffic behavior
requires gaining an understanding of the
efficiency of new network applications.
• Efficiency refers to whether applications and
protocols use bandwidth effectively.
• Efficiency is affected by
– frame size,
– the interaction of protocols used by an application,
– windowing and flow control,
– and error-recovery mechanisms.
42
 Frame Size
• Using a frame size that is the maximum
supported for the medium in use has a positive
impact on network performance for bulk
applications.
• For file-transfer applications, in particular,
designer should use the largest possible
maximum transmission unit (MTU).
• Depending on the protocol stacks that will be
used in the new network design, the MTU can
be configured for some applications.
43
 Frame Size
• In an IP environment, you should avoid increasing
the MTU to larger than the maximum supported for
the media traversed by the frames, to avoid
fragmentation and reassembly of frames.
• When devices such as end nodes or routers need to
fragment and reassemble frames, performance
degrades.
• Modern operating systems support MTU discovery.
• With MTU discovery, the software can
dynamically discover and use the largest frame size
that will traverse the network without requiring
fragmentation.
44
 Windowing and Flow Control
• To really understand network traffic, designer needs to
understand windowing and flow control.
• A TCP/IP device, for example, sends segments (packets) of
data in quick sequence, without waiting for an
acknowledgment, until its send window has been exhausted.
• A station’s send window is based on the recipient’s receive
window. The recipient states in every TCP packet how much
data it is ready to receive. This total can vary from a few
bytes up to 65,535 bytes. The recipient’s receive window is
based on how much memory the receiver has and how
quickly it can process received data.
• Designer can optimize network efficiency by increasing
memory and CPU power on end stations, which can result in
a larger receive window.

45
 Error-Recovery Mechanisms
• Poorly designed error-recovery mechanisms can waste bandwidth.
• For example, if a protocol retransmits data quickly without waiting a
long enough time to receive an acknowledgment, this can cause
performance degradation for the rest of the network due to the
bandwidth used.
• Acknowledgments at multiple layers can also waste bandwidth.
• Connectionless protocols usually do not implement error recovery.
• Error-recovery mechanisms for connection-oriented protocols vary.
TCP implements an adaptive retransmission algorithm, which means
that the rate of retransmissions slows when the network is congested,
which optimizes the use of bandwidth.
• Using a protocol analyzer, designer can determine whether the
protocols implement effective error recovery. In some cases designer
can configure retransmission and timeout timers or upgrade to a
better protocol implementation.

46
 Characterizing Quality of Service
Requirements
• Just knowing the load (bandwidth) requirement for an
application is not sufficient.
• Designer also needs to know if the requirement is
flexible or inflexible.
• Some applications continue to work (although slowly)
when bandwidth is not sufficient.
• Other applications, such as voice and video
applications, are rendered useless if a certain level of
bandwidth is not available.
• Without proper network-wide QoS configuration,
packet loss can occur because of congested links and
poor packet buffer and queue management on routers.
47
 ATM QoS Specifications
• The Asynchronous Transfer Mode (ATM) Forum
does an excellent job of categorizing the types of
service that a network can offer to support different
sorts of applications.
• ATM Forum terminology is still helpful because it
identifies the parameters that different sorts of
applications must specify to request a certain type
of network service.
• These parameters include delay and delay
variation, data-burst sizes, data loss, and peak,
sustainable, and minimum traffic rates.
48
 ATM QoS Specifications
• The ATM Forum defines six service categories:
– Constant bit rate (CBR)
– Real-time variable bit rate (rt-VBR)
– Non-real-time variable bit rate (nrt-VBR)
– Unspecified bit rate (UBR)
– Available bit rate (ABR)
– Guaranteed frame rate (GFR)

49
 ATM QoS Specifications
• Constant bit rate (CBR)
– CBR is used by applications that need the capability to request a static amount of bandwidth to
be continuously available during a connection lifetime.
– CBR service is intended to support real-time applications requiring tightly constrained delay
variation (for example, voice and video)
• Real-time variable bit rate (rt-VBR)
– intended for real-time applications that have bursty traffic characteristics.
• Non-real-time variable bit rate (nrt-VBR)
– intended for non-real-time applications that have bursty traffic characteristics.
• Unspecified bit rate (UBR)
– The UBR service category is intended for non-real-time applications, including traditional
computer communications applications such as file transfer and email.
• Available bit rate (ABR)
– A flow-control mechanism offers several types of feedback to control the source rate in response
to changing conditions.
– ABR service is not intended to support real-time applications.
• Guaranteed frame rate (GFR)
– GFR is designed for applications that require a minimum rate guarantee and can benefit from
dynamically accessing additional bandwidth available in the network

50
 IETF Integrated Services Working
Group QoS Specifications
• IETF Internet Engineering Task Force (IETF) consists
of numerous working groups responsible for developing
Internet and TCP/IP standards.
• The IETF Integrated Services working group describes
the Resource Reservation Protocol (RSVP)
• RSVP is a setup protocol used by a host to request
specific qualities of service from the network for
particular application flows.
• RSVP is also used by routers to deliver QoS requests to
other routers (or other types of nodes) along the paths of
a flow.
• RSVP requests generally result in resources being
reserved in each node along the path.
51
 IETF Integrated Services Working
Group QoS Specifications
• Two major types of service:
• Controlled-Load Service:
– It provides a client data flow with a QoS closely approximating
the QoS that same flow would receive on an unloaded network.
– It is intended for applications that are highly sensitive to
overloaded conditions, such as real-time applications.
– A network node that accepts a request for controlled-load service
must use admission control functions to ensure that adequate
resources are available to handle the requested level of traffic
• Guaranteed Service:
– It guarantees both bandwidth and delay characteristics.
– Guaranteed service is intended for applications that need a
guarantee that a packet will arrive no later than a certain time
after it was transmitted by its source.

52
 IETF Differentiated Services
Working Group QoS Specifications
• 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.
• The DSCP can have 1 of 64 possible values,
each of which outlines a per-hop behaviors
(PHB)

53