Chapter 3

Characterizing the Existing Internetwork

An important step in top down network design is to examine a customer’s existing network to
better judge how to meet expectations of network scalability, performance, and availability.
Examining the network includes learning about the topology and physical structure and assessing
the network performance.

Characterizing the network infrastructure

The following are important aspects to perform in characterizing the network infrastructure

 Develop a set of network maps

 Learning the location of major internetworking devices and network segments
 Documenting the names and addresses of major devices and segments
 Identifying any standard methods for addressing and naming
 Documenting the types and lengths of physical cabling
 Investigating architectural and environmental constraints

Developing a network map

A map or set of maps can be created in characterizing the existing network by learning the
location of major hosts, interconnection devices, and network segments.

Characterizing large Internetworks

Developing a single network map might not be possible for large internetworks. There are many
approaches to solving this problem, including developing many maps, one for each location.
Another approach is to apply a top down method. Start with a map of sets of maps that shows the
following high level information.

 Geographical information such as countries, states or provinces, cities and campuses

 WAN connections between countries, state and cities
 WAN and LAN connections between building and between campuses

For each campus network you can develop more precise maps that show the following more
detailed information

 Building and floors, and possibly rooms or cubicles

 The location of major servers or server farms
 The location of routers and switches
 The location of firewall, Network Address Translation(NAT) devices, Intrusion
Detection System (IDS), and Intrusion Prevention System (IPS)
 The location of mainframe
 The location of major network management stations
 The location and reach of virtual LAN (VLAN)

1
  Some indication of where workstations reside, although not necessarily the explicit
location of each workstations

Another method of characterizing large, complex networks is to use the top down approach that
is influenced by the OSI reference model

 Develop a logical map that shows applications and services used by the network user
 Develop a map that shows network services and also develop a map that depicts layer 3
topology of the internetwork
 Develop a map or a sets of maps that shows detailed information about data link layer
links and devices is often extremely helpful

Characterizing the logical architecture

The logical topology illustrates the architecture of the network, which can be hierarchical, or flat,
structured or unstructured, layered or not, and other possibilities. The logical topology also
describes methods for connecting devices in geometric shape (for example a star, ring, bus, hub
and spoke or mesh). The logical topology can affect your ability to upgrade a network. For
example, a flat topology doesn’t scale as well as hierarchical topology.

Developing a modular block diagram

In addition to developing a set of detailed maps, it is often helpful to draw a simplified block
diagram of the network or parts of the network. The diagram can depict the major functions of
the network in a modular fashion. The following figure shows a block, modularized network
topology map that is based on the Cisco Enterprise Composite Network Model.

2
Characterizing network addressing and naming

Characterizing the logical infrastructure of a network involves documenting any strategies your
customer has for network addressing and naming. When drawing detailed network maps, include
the names of major sites, routers, network segments, and servers. You should also investigate the
network layer addresses your customer use. Your customer’s addressing scheme can influence
your ability to adapt the network to new design goals.

Understanding your customer’s addressing scheme might help you to know

 Your customer might use unregistered IP addresses that will need to be changed or
translated before connecting to the internet
 Your customer might have a goal of using route summarization
 Your customer’s existing addressing scheme might affect the routing protocols you can
select

Characterizing wiring and media

While exploring the cabling design assess how well equipment and cables are labeled in the
current network.

Your network diagram should document

 The connection between buildings

 It should include information on the number of pairs of wires and the type of wiring( or
wireless technology) in use
 Indicate how far building are from one another

Probably the wiring (or wireless technology) between buildings is one of the following

 Single-mode fiber
 Multi-mode fiber
 Shielded twisted-pair (STP) copper
 Unshielded twisted-pair (UTP) copper
 Coaxial cable
 Microwave
 Laser
 Radio
 Infrared

Checking architectural and environmental constraints

When investigating cabling, pay attention to such environmental issues as the possibility of that
cabling will run near creeks that could flood, rail road tracks or highways where traffic could
jostle cables or construction or manufacturing areas where heavy equipment or digging could
break cables. Within buildings, pay attention to architectural issues that could affect the
feasibility of implementing your network design.

3
Checking site for a wireless installation

A common goal for modern campus network designs is to install a wireless LAN (WLAN) based
on IEEE 802.11 standards. An important aspect of inspecting the architectural and environmental
constraints of a site is determining the feasibility of using wireless transmission. The term
wireless site survey is often used to describe the process of analyzing a site to see if it will be
appropriate for wireless transmission.

A site survey starts with a draft WLAN design. Using a floor plan or blueprint for the site, the
designer decides on the initial placement of the wireless access points. An access point is a
station that transmits and receives data for users of the WLAN. It usually serves also as the point
of interconnection between the WLAN and the wired Ethernet network. A network designer can
decide where to place access points for initial testing based on some knowledge of where the
users will be located, characteristics of the access points’ antennas, and the location of major
obstructions.

The initial placement of an access point is based on an estimate of the signal loss that will occur
between the access point and the users of the access point. The starting point for an estimate
depends on how much loss in power a signal would experience in the vacuum of space, without
any obstructions or other interference. This is called the free space path loss and is specified in
decibels (dB). The estimate is tuned with an understanding that the actual expected signal loss
depends on the medium through which the signal will travel, which is undoubtedly not a
vacuum. An RF signal traveling through objects of various sorts can be affected by many
different problems, includes reflection, absorption, refraction, and diffraction.

Checking the health of the existing Internetwork

Studying the performance of the existing internetwork gives you a baseline measurement from
which to measure new network performance. Armed with measurement of the present
internetwork, you can demonstrate to your customer how much better the new internetwork
performs once your design is implemented.

Developing a baseline of network performance

Developing an accurate baseline of a network’s performance is not an easy task. One challenging
aspect is selecting a time to do the analysis. It is important that you allocate a lot of time
(multiple days) if you want the baseline to be accurate. If measurements are made over too short
a timeframe, temporary errors appear more significant than they are.

Analyzing Network Availability: To document availability characteristics of the existing

network, gather any statistics that the customer has on the mean time between failure (MTBF)
and mean time to repair (MTTR) for the internetwork as a whole and major network segments.

Analyzing Network Utilization: Network utilization is a measurement of the amount of

bandwidth that is in use during a specific time interval. Utilization is commonly specified as a
percentage of capacity. If a network-monitoring tool says that network utilization on a Fast

4
Ethernet segment is 70 percent, for example, this means that 70 percent of the 100-Mbps
capacity is in use, averaged over a specified timeframe or window.

Measuring Bandwidth Utilization by Protocol: Developing a baseline of network performance

should also include measuring utilization from broadcast traffic versus unicast traffic, and by
each major protocol. To measure bandwidth utilization by protocol, place a protocol analyzer or
remote monitoring (RMON) probe on each major network segment and fill out a chart such as
the one shown in the following Table. If the analyzer supports relative and absolute percentages,
specify the bandwidth used by protocols as relative and absolute. 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).

Analyzing Network Accuracy

With packet-switched networks, it makes more sense to measure frame (packet) errors because a
whole frame is considered bad if a single bit is changed or dropped. In packet switched networks,
a sending station calculates a CRC based on the bits in a frame. The sending station places the
value of the CRC in the frame. A receiving station determines if a bit has been changed or
dropped by calculating the CRC again and comparing the result to the CRC in the frame. A
frame with a bad CRC is dropped and must be retransmitted by the sender. Usually an upper-
layer protocol has the job of retransmitting frames that do not get acknowledged.

Analyzing delay and response time

To verify that performance of a new network design meets a customer’s requirements, you need
to measure response time between significant network devices before and after a new network
design is implemented. Response time can be measured many ways. Using a protocol analyzer,
you can look at the amount of time between frames and get a rough estimate of response time at
the data link layer, transport layer, and application layer.

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. While measuring RTT, you can also
measure an RTT variance. Variance measurements are important for applications that cannot
tolerate much jitter (for example, voice and video applications). You can also document any loss
of packets.
5
Checking the Status of Major Routers, Switches, and Firewalls
The final step in characterizing the existing internetwork is to check the behavior of the
internetworking devices in the internetwork. This includes routers and switches that connect
layers of a hierarchical topology, and devices that will have the most significant roles in your
new network design. It’s not necessary to check every LAN switch, just the major switches,
routers, 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. Your method for assessing the health of an
internetworking device depends on the vendor and architecture of the device.
 show buffers
 show cdp neighbors detail
 show environment
 show interfaces
 show memory
 show processes
 show running-config
 show startup-config
 show version

Network Health Checklist

You can use the following Network Health checklist to assist you in verifying the health of an
existing internetwork. The Network Health checklist is generic in nature and documents a best-
case scenario. The thresholds might not apply to all networks.
 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 overused (5-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 ms (1/10th of a
second).

6
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. 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.

Identifying Major Traffic Sources and Stores

To understand network traffic flow, you should first 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. A user community can be a corporate department or set of
departments. In many environments, however, application usage crosses departmental
boundaries. As more corporations use matrix management and form virtual teams to complete ad
hoc projects, it becomes increasingly necessary to characterize user communities by application
and protocol usage rather than by departmental boundary. To document user communities, ask
your customer to help you fill out the User Communities chart shown in the following table.

In addition to documenting user communities, characterizing traffic flow also requires that you
document 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), a mainframe, a tape backup unit, a digital video library, or any device or
component of an internetwork where large quantities of data are stored. To document major data
stores use the following table

Documenting traffic flow on the existing network

Documenting traffic flow involves identifying and characterizing individual traffic flows
between traffic sources and stores. Measuring the traffic flow behavior can also help network
designers do the following
 Characterize the behavior of existing networks.
7
  Plan for network development and expansion.
 Quantify network performance.
 Verify the quality of network service.
 Ascribe network usage to users and applications.
An individual network traffic flow can be defined as protocol and application information
transmitted between communicating entities during a single session. 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. You
can also use Cisco NetFlow, which 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. You can use the following table to document
information about the direction and volume of traffic flows.

Characterizing Types of Traffic Flow for New Network Applications

A network flow can be characterized by its direction and symmetry. 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.
A good technique for characterizing network traffic flow is to classify applications as supporting
one of a few well-known flow types:
 Terminal/host traffic flow
 Client/server traffic flow
 Peer-to-peer traffic flow
 Server/server traffic flow
 Distributed computing traffic flow

Documenting Traffic Flow for New and Existing Network Applications

To document traffic flow for new (and existing) network applications, characterize the flow type
for each application and list the user communities and data stores that are associated with
applications.

8
Characterizing Traffic Load
To select appropriate topologies and technologies to meet a customer’s goals, it is important to
characterize traffic load with traffic flow. Characterizing traffic load can help you design
networks with sufficient capacity for local usage and internetwork flows. 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, you can research application-usage patterns, idle times between packets and
sessions, frame sizes, and other traffic behavioral patterns for application and system protocols.
For customers with numerous applications, this level of analysis might not be practical, however.
For these customers, you could limit the analysis to the top five or ten applications.

Another approach to avoiding bottlenecks is simply to throw large amounts of bandwidth at the
problem (also known as over provisioning). A strict interpretation of systems analysis principles
wouldn’t approve of such an approach, but bandwidth is cheap these days. LAN bandwidth is
extremely cheap. There’s no excuse for not using Fast Ethernet (or better) on all new
workstations and switches, and most organizations can also afford to use Gigabit Ethernet on
switch-to-switch and switch-to-server links. WAN bandwidth is still expensive in some parts of
the world, including rural areas of the United States. But in many parts of the United States and
the rest of the world, bandwidth has been over provisioned and isn’t over utilized. If you know
that bandwidth will not be a constraint in your network designs, you can skip the next few
sections and jump to “Characterizing Traffic Behavior.”

Documenting Application-Usage Patterns

The first step in documenting application-usage patterns is to identify user communities, the
number of users in the communities, and the applications the users employ.

In addition to identifying the total number of users for each application, you should also
document the following information:
 The frequency of application sessions (number of sessions per day, week, month, or
whatever time period is appropriate)
 The length of an average application session
 The number of simultaneous users of an application
Characterizing Quality of Service Requirements
Analyzing network traffic requirements isn’t quite as simple as identifying flows, measuring the
load for flows, and characterizing traffic behavior such as broadcast and error recovery behavior.
You need to also characterize the QoS requirements for applications.

9
IETF Integrated Services Working Group QoS Specifications
RSVP implements QoS for a particular data flow using mechanisms collectively called traffic
control. These mechanisms include the following:
 A packet classifier that determines the QoS class (and perhaps the route) for each packet
 An admission control function that determines whether the node has sufficient available
resources to supply the requested QoS
 A packet scheduler that determines when particular packets are forwarded to meet QoS
requirements of a flow

Network Traffic Checklist

You can use the following Network Traffic checklist to determine if you have completed all the
steps for characterizing network traffic:
 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 the 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.

10