Network Analysis, Design and Implementation

1
Network Analysis, Design and Implementation

• CS 55 Computer Networks
• Topic 12, Part B2
• Analyzing the Network

2
Overview

• Analysis is the second phase of the network
  design process, as the Network Design Process
  Diagram illustrates

3
Overview (contd)

• Estimating and measuring are both important parts
  of a network analysis. User estimates provide a
  broad general picture of the network, and clues
  for more detailed investigation. Baseline
  measurements provide a clear, detailed view of
  the most important aspects.

4
Overview (contd)

• Balance is the key to using estimates and
  measurements. An analysis that relies too heavily
  on estimates will be unreliable an analysis that
  relies too heavily on measurements may miss
  broader patterns. In this way, a good network
  analysis is a lot like a medical examination. A
  good doctor first asks the patient to describe
  the problem. Then, based on that information, the
  doctor performs specific tests.

5
Overview (contd)

• The main deliverable of the Analysis phase is a
  Traffic Specification document that describes the
  performance of the existing network. While the
  Requirements Specification describes the
  "destination" the new network design should
  reach, the Traffic Specification describes the
  "starting point." Both of these documents help
  determine the Logical and Physical Design of the
  network.

6
Overview (contd)

• A Traffic Specification typically includes the
  following elements that describe the current
  network
• Logical network diagram
• Inventory of internetworking devices and servers
• Estimates of local segment and backbone traffic
• Baseline measurements

7
Network Performance Concepts

• In the Analysis phase, we take precise
  measurements of network performance and load.
  However, before we can start measuring, we must
  have some idea of what to look for. This lesson
  introduces and explains the major concepts and
  terms used to understand network performance.

8
Network Performance Concepts (contd)

• The overriding concept of network analysis is the
  idea of a "bottleneck" a point, or combination
  of points, that restricts or reduces the flow of
  data. This lesson describes the factors that can
  cause a network component to become a bottleneck,
  and shows you what to look for when hunting for
  bottlenecks.

9
Network Performance Concepts (contd)

• Any part of a network may become a bottleneck.

10
Response Time, Delay, and Latency

• Response time, delay, and latency are
  interrelated terms. Each attribute has an impact
  on the performance of a network, and each is
  based on time. Instead of simply defining each
  term, it is helpful to also illustrate each
  concept with some examples.

11
Response Time, Delay, and Latency (contd)

• Response time is the total time it takes to
  receive a response after a request for a service
  has been initiated. It is often used in reference
  to interactive terminals requesting information
  from a host computer. For example, response time
  is the time that passes between the moment a user
  presses the ENTER key and the moment a full
  screen of data is returned to that terminal. It
  is the time necessary for the user's request to
  travel through the network to a host, and for the
  host's response to travel back.

12
Response Time in a Master/Slave Configurations

• The Response Time Components (Traditional IBM
  Network) Diagram illustrates typical response
  time components in a traditional IBM network. As
  you can see in the diagram, response time is the
  sum of the time necessary for data to pass
  through each component of a network. Each device,
  communication link, and process adds its own
  delay to the overall response time.

13
Response Time in a Master/Slave Configurations
(contd)

• Some of the most common factors in response time
  are described in the diagram

Response Time Components (Traditional IBM Network)
14
Polling Delay

• Polling is a method used to control communication
  between a master and slave node in an unbalanced
  data communication configuration. If a slave
  device (dumb terminal) has data to send, it must
  wait until it is polled by the master device
  (upstream controller or host) before it can send
  data.

15
Link Delay

• Link delays describe the speed at which data can
  be transferred across a communications link. The
  higher the link speed, the faster data can
  travel, and the lower the delay. Common link
  speeds in this traditional IBM network
  configuration are 9.6 or 19.2 Kbps.

16
Component Latency

• Latency is the amount of time it takes a network
  device, such as a bridge or router, to analyze
  and retransmit a received packet. Devices that
  make simple forwarding decisions, such as
  switches or bridges, have lower latency than
  devices that perform complex processing, such as
  routers or gateways.

17
CPU Delay

• Central processing unit (CPU) delay describes the
  time it takes the server CPU to process a request
  from the network. In general, the busier the CPU
  is, the longer it will take to process the
  request.

18
Response Time In A Client/Server Configuration

• In a client/server network, response time is the
  amount of time it takes for a server to respond
  to a request from a client workstation. As you
  can see in the Client/Server Response Time
  Diagram, there are several factors that impact
  response time in this configuration, as presented
  in the next slide.

19
Response Time In A Client/Server Configuration
(contd)
20
NIC Delay

• Different types of NICs introduce various delays.
  After a client application requests network
  access, there is a delay while the client NIC
  processes the request and transmits the data over
  the physical medium.

21
Physical Media Delay

• Response time also depends on the transmission
  speed of the particular LAN architecture. It will
  take longer for data to traverse a 4-Mbps Token
  Ring network than a 100-Mbps FDDI network. It
  will also take longer to transfer a file using
  small frame sizes versus larger frame sizes
  because of the amount of overhead (header and
  trailer) required for each frame.

22
Server Delay

• Depending on the processor speed of the server
  and the average number of requests the server has
  to process, server response time may vary widely.
  Other factors in server delay are queue delays
  and disk access delays.

23
Public Network Delay

• When request/response traffic travels over a
  public WAN, response times can vary drastically.
  For example, wide response time variations can
  occur when using the Internet, even to the point
  of losing connections because intermediate links
  "time out" and no longer stay in session. Network
  delays of this type are very hard to predict, and
  often vary according to the time of day (as
  overall Internet traffic increases or decreases).

24
Public Network Delay (contd)

• The Public Network Delay Diagram Illustrates this
  concept.

25
Analyzing Response Time

• When analyzing response time, evaluate all
  network components to see how much delay or
  latency each one contributes. Long response times
  can be caused by one poorly performing component
  that is acting as a bottleneck in the network.
  Poor component performance, in turn, often occurs
  when a component is overutilized. Therefore, the
  next major traffic analysis concept to consider
  is utilization.

26
CPU Utilization

• CPU utilization describes how busy a processor is
  as it processes requests and responses to and
  from a network. The processing capacity of a CPU,
  measured in thousands of cycles per second, is
  constant. If the incoming work requires a greater
  number of cycles than the CPU has available, some
  of the work must wait.

27
CPU Utilization (contd)

• A networking component, such as a router, uses a
  certain number of CPU cycles to process each
  packet. If the number of packets consistently
  exceeds the router's CPU capacity, in other
  words, if the router's CPU utilization approaches
  100 percent, the router is a network bottleneck.

28
CPU Utilization (contd)

• In the Network Bottleneck Diagram shown in the
  next slide, the router is being analyzed. Note
  the performance curve that shows the relationship
  between router CPU utilization and network
  performance. The curve clearly shows that as
  router CPU utilization increases past a certain
  point, the overall performance of the network
  degrades because the router is unable to process
  the incoming flow of packets in a timely fashion.

29
Network Bottleneck
30
Network Bottleneck (contd)

• The diagram shows that the router's effective
  maximum utilization is less than 100 percent.
  This is because the device must perform other
  work besides processing frames and packets. For
  example, routers exchange information to maintain
  their routing tables, and many devices maintain
  network management information and respond to
  network management commands.

31
Network Bottleneck (contd)

• As devices become more complex and operate higher
  in the protocol stack, they must spend more of
  their CPU cycles on these "overhead" tasks. For
  example, a switch (operating at Layer 2) devotes
  fewer CPU cycles forwarding traffic than a
  protocol converter. This is due to the fact that
  a protocol converter operates at more layers than
  a switch and more CPU cycles are required to
  perform basic functions.

32
Link Utilization

• Link utilization is the percentage of the link's
  total bandwidth that is used effectively. For
  example, a T1 line has 24 channels, with a
  maximum bandwidth of 64 Kbps per channel (64 Kbps
  X 24 1.536 Mbps, not including the overhead for
  signaling). If we only effectively utilize six
  channels of the 24 T1 channels available, the T1
  line's utilization is 384 Kbps, or 25 percent of
  maximum bandwidth.

33
Capacity

• Capacity typically describes the maximum
  data-carrying capability of a communications
  channel or link. For example, the capacity of a
  T1 channel is 64 Kbps. This does not mean the
  channel will always contain 64 Kbps of data it
  is capable of carrying 64 Kbps of data, but no
  more. Capacity and bandwidth are often used
  interchangeably.

34
Bandwidth

• Bandwidth is the difference between the highest
  and lowest frequencies that can be transmitted
  across a transmission line or through a network.
  It is measured in hertz (Hz) for analog networks
  and bits per second (bps) for digital networks.

35
Some common bandwidths for digital networks
36
Some common bandwidths for digital networks
(contd)
37
Application and Bandwidth

• Different types of applications require different
  bandwidths for effective usage. Some typical
  applications are
• PC communications 14.4 to 56 Kbps
• Digital audio 1 to 2 Mbps
• Compressed video 2 to 10 Mbps
• Document imaging 10 to 100 Mbps
• Full-motion video 1 to 2 Gbps

38
Bandwidth and Utilization

• A link becomes a network bottleneck when its
  utilization approaches 100 percent, when traffic
  volume approaches its capacity. This principle is
  clearly demonstrated twice each weekday on the
  highways of any fair-sized city.

39
Throughput

• Throughput describes the overall capacity of a
  network to perform useful work. While bandwidth
  measurements focus on the raw number of bits a
  network can carry, throughput measurements
  express the actual or effective data rates of a
  network.

40
Throughput (contd)

• Throughput is most often used to describe the
  overall performance of a network, as illustrated
  on the Throughput Example Diagram in the next
  slide. One measure of effective throughput is
  throughput rate in information bits (TRIB),
  typically measured in packets per second (PPS),
  characters per second (CPS), transactions per
  second (TPS), or transactions per hour (TPH).

41
Throughput Example
42
Throughput Example (contd)

• Of these, TPS and TPH are the most widely used
  measures of throughput. For example, the same
  throughput measurement can be expressed as 2 TPS
  or 7,200 TPH (2 TPS 600 seconds/hour). PPS is
  also widely used to express router throughput.

43
Throughput Analysis

• Knowing the TPH is not enough to get a good
  handle on overall performance you must also know
  the average size and the TPH relative to the time
  of day (TOD). The Throughput Analysis Diagram in
  the next slide shows different measurements of
  throughput for a given network, and the
  relationship between packet size and throughput.

44
Throughput Analysis (contd)
45
Throughput Analysis (contd)

• Throughput is affected by all of the delay,
  latency, and utilization factors we discussed
  above. In addition to those, protocol efficiency
  influences throughput because some protocols
  transmit information more efficiently than
  others. Therefore, effective throughput and
  response time are directly related, and the terms
  are often used interchangeably. The higher the
  effective throughput, the better the response
  time.

46
Estimating Traffic Volumes and Patterns

• Estimates of traffic volume and directional
  patterns give us insight into the general
  performance characteristics of a network. This
  broad understanding will guide the more exact
  traffic measurements to come later in this phase.
  These estimates, plus the later measurements,
  will provide important input to the Logical
  Design phase.

47
Estimating Traffic Volumes and Patterns (contd)

• Traffic estimates and traffic measurements are
  both essential parts of a traffic analysis.

48
Traffic Direction

• Although it is important to know the traffic
  volume at key points in a network, it can be just
  as important to understand the directions in
  which the traffic flows. That's because the
  direction of traffic can strongly determine the
  amount of traffic on various network segments.

49
Traffic Direction (contd)

• Directional traffic patterns are based on three
  methods of communication between endpoints
• Peer-to-peer
• Client-to-server
• Server-to-client
• Each network node communicates in one or more of
  these modes, depending on network resources,
  node, and application capabilities.

50
Peer-to-Peer Traffic

• Peer-to-peer traffic is traffic typically seen
  between similar nodes (clients). The
  communicating nodes have similar application and
  communications capabilities, and each node is
  just as likely as any other to communicate with
  another node in the network. A common example of
  peer-to-peer communications is file sharing
  between workstations. There is no obvious source
  or destination traffic pattern, peer-to-peer
  traffic does not tend to create directional flow
  patterns.

51
Peer-to-Peer Traffic (contd)
52
Client-to-Server and Server-to-Client Traffic

• Client-to-server traffic, as the name implies,
  describes communication between any end nodes
  (clients) and a shared resource (server). A
  client may be any type of node that needs access
  to a common resource, such as a central database.
  Servers vary in size and functionality, and can
  be anything from a PC-based server, to a midrange
  computer, to a mainframe.

53
Client-to-Server and Server-to-Client Traffic
(contd)
54
Client-to-Server and Server-to-Client Traffic
(contd)

• Unlike the random patterns of peer-to-peer
  traffic, client-to-server traffic is directional.
  Depending on the type of application being used
  by each client, most traffic will flow between
  clients and the server, and not between clients.

55
Client-to-Server and Server-to-Client Traffic
(contd)

• In some cases, client-to-server traffic can
  primarily flow in one direction. For example,
  when a server is used to house data files, such
  as in a data warehousing or file storage
  application, more information typically flows to
  the server than from the server. We call this
  pattern a client-to-server distribution.

56
Directional Characteristics of Traffic
57
Client-to-Server and Server-to-Client Traffic
(contd)

• In contrast, when a database application stores
  data on a server, traffic typically flows from
  the server to the client. Client requests that
  flow to the server are normally small compared to
  the server's response to those requests. This
  pattern is called a server-to-client
  distribution. World Wide Web (Web) servers create
  this traffic flow pattern, because a client's
  typical request for Web pages is small compared
  to the Web page data the server returns.

58
Client-to-Server and Server-to-Client Traffic
(contd)

• This imbalance in client-to-server traffic means
  that a network bottleneck may only occur when
  traffic flows in one direction. For example, some
  Internet firewall designs allow outgoing Web page
  requests to travel on one network segment, while
  incoming Web page responses take a different path
  (usually through a device, such as a router, that
  runs special security software). In this case,
  bottlenecks usually occur on the inbound path, as
  large Web page transmissions traverse the
  firewall.

59
Traffic Boundaries

• A network designer must also be aware of how
  traffic is dispersed across an organization. It
  is helpful to determine the logical and physical
  boundaries that create collision domains,
  broadcast domains, and network segments.

60
Collision Domains and Broadcast Domains

• One of the most important reasons to segment a
  LAN is to increase the effective network
  bandwidth by containing traffic within workgroup
  segments. Several different internetworking
  devices can segment a LAN however, they do so in
  different ways. Some devices create separate
  collision domains, while others create separate
  broadcast domains.

61
Collision Domains and Broadcast Domains (contd)

• A LAN connected by repeaters or hubs is a single
  collision domain, because all stations compete
  for access to the same shared medium. This
  collision domain is also a single broadcast
  domain, because hubs and repeaters transmit
  broadcast traffic to all nodes in the network.
  The Unsegmented Network Diagram shown in the next
  slide illustrates how a network consisting of
  traditional hubs consists of one collision domain
  and one broadcast domain.

62
Unsegmented Network
63
Collision Domains and Broadcast Domains (contd)

• A switch or bridge can segment a single large LAN
  collision domain into several smaller collision
  domains. This can result in enhanced network
  performance, because Layer 2 segmentation reduces
  the number of stations competing for media
  access.

64
Collision Domains and Broadcast Domains (contd)

• The Switch Segmented Network Diagram in the next
  slide illustrates how a switch segments one large
  collision domain into smaller collision domains.
  Each collision domain represents a separate 10
  Mbps bandwidth. Before installing the switch, all
  stations in the single large LAN collision domain
  share 10 Mbps of bandwidth. Installation of the
  switch dramatically increases performance by
  allocating 10 Mbps to each workgroup, and the
  total effective aggregate network bandwidth is
  increased.

65
Switch Segmented Network
66
Collision Domains and Broadcast Domains (contd)

• However, the individual collision domains created
  by the switch are still members of the same
  broadcast domain, because a switch transmits
  broadcast traffic out all ports. This means that
  broadcast traffic originating in one collision
  domain is still forwarded to all other collision
  domains.

67
Collision Domains and Broadcast Domains (contd)

• To create separate broadcast domains, it is
  necessary to segment the network at Layer 3. A
  router effectively contains both regular network
  traffic and broadcast traffic within each network
  segment, and only directs intersegment traffic
  between network segments. This approach improves
  the effective throughput of the entire network.

68
Physical Boundaries

• In the examples presented on the VLAN Boundary
  (Logical) Diagram, collision domains and
  broadcast domains were created by using different
  internetworking devices as physical boundaries to
  contain certain types of network traffic. Another
  example of a physical boundary is a backbone
  connection that defines a workgroup. The Physical
  Boundary Diagram illustrates how a network with
  common WAN links may be segmented for traffic
  analysis purposes.

69
Physical Boundaries (contd)
70
Logical Boundaries

• Physical boundaries are a common method of
  segmenting a network however, special software
  and hardware can also be used to create logical
  network boundaries. For example, logical
  boundaries can be created by a virtual LAN
  (VLAN). The VLAN Boundary Diagram illustrates how
  a VLAN logical boundary creates separate
  workgroups from nodes that are physically
  connected.

71
Logical Boundaries (contd)
72
Logical Boundaries (contd)

• In this example, traffic between nodes in Virtual
  Workgroup 1 is contained within that workgroup.
  Likewise, traffic between the nodes of Virtual
  Workgroup 2 does not flow into workgroup 2.
  Traffic flowing within virtual workgroups can be
  both client-to-server and peer-to-peer.

73
Traffic Boundaries

• Although VLANs offer many possibilities to a
  network designer, they are currently proprietary
  solutions that are more complex to implement.
  Therefore, it is still much easier to use
  physical boundaries to segment a network. The
  802.1Q standard addresses the proprietary nature
  of implementing VLANs allowing a mix of vendor
  products to deploy VLAN solutions.

74
Traffic Distribution 80/20 Rule

• An important consideration in traffic analysis is
  the volume of data that flows within and across
  network boundaries. This is why the Requirements
  Gathering process asked individual users where
  they access information and where they usually
  send it.

75
Traffic Distribution 80/20 Rule (contd)

• The 80/20 rule is a general rule of thumb for
  traditional network segmentation. It states that
  80 percent of a segment's traffic should be local
  to that segment, with only 20 percent addressed
  to other segments. This is shown on the 80/20
  Rule Diagram in the next slide.

76
80/20 Rule
77
Traffic Distribution 80/20 Rule (contd)

• In this diagram, the client under study sends and
  receives 80 percent of its information on the
  local segment. This traffic can be
  client-to-server traffic with a local server,
  peer-to-peer communication with other members of
  the department, or other sources on that segment.
  Approximately 20 percent of the client's traffic
  flows to or from remote resources, such as a Web
  server located in another city.

78
Traffic Distribution 80/20 Rule (contd)

• The 80/20 rule is a practical approach to
  optimizing the use of network backbones and
  expensive WAN connections. For example, the 80/20
  rule can guide the use of a T1 (1.544 Mbps) link
  to accommodate remote traffic from an Ethernet
  LAN (10 Mbps).

79
Exceptions to the 80/20 Rule

• In many networks today, the 80/20 rule no longer
  applies. For example, a research department at a
  research and development (RD) firm might use
  remote databases of information and perform
  extensive Internet research daily. In this case,
  most of its traffic would be addressed to remote
  resources. In extreme cases, only 20 percent of
  traffic might be local, and 80 percent remote
  (20/80). The 20/80 Distribution Diagram in the
  next slide illustrates this concept.

80
20/80 Distribution
81
Estimating Traffic Volume

• A traffic analysis begins with an estimate of
  traffic volume on the local segments, as well as
  traffic running across the network backbone. To
  estimate these volumes, we take the following
  steps
• 1. Divide the network into understandable
  segments.
• 2. Estimate application traffic on each segment.
• 3. Estimate traffic distribution on local and
  remote segments.
• 4. Repeat the process for each segment, then
  combine segment estimates for WAN and backbone
  traffic analysis.

82
Divide Network into Understandable Segments

• We begin by estimating the traffic volumes and
  patterns for each part of the network, then
  analyzing the way traffic flows between those
  parts. Therefore, our first job is to divide the
  network, on paper, into logical pieces we can
  analyze. This is normally done at a workgroup or
  departmental level, because people in the same
  workgroup or department often use the same
  applications and have the same basic
  requirements. The main objective of this step is
  to work with a small enough group of users to
  make each set of measurements more manageable.

83
Divide Network into Understandable Segments
(contd)

• By separately analyzing each part of the network,
  we treat the portion of the network under study
  as a "white box" and the other parts of the
  network as a "black box." This is illustrated in
  the White Box Approach (Before and After) Diagram
  in the next slide.

84
White Box Approach
85
Estimate Application Traffic on Each Segment

• During the Requirements Gathering process, we
  noted each person's estimated usage of various
  applications. We now summarize this information
  for a particular segment of the network.

86
Estimate Traffic Distribution on Local and Remote
Segments

• The users of each application are typically
  spread out through the organization, so we must
  also estimate overall traffic distributions for
  each application. For example, if we were to look
  at a typical network layout, we might find a
  configuration as shown on the Three Application
  Example Diagram in the next slide. This
  information is also summarized from requirements
  specifications, specifically the application and
  network requirements.

87
Three Application Example
88
Three Application Example (contd)

• Traffic distribution typically follows a
  different general pattern for each department or
  workgroup. In some instances, traffic patterns
  may vary throughout the day. What we look for in
  the traffic Analysis phase are general patterns
  that can guide the Logical and Physical Design of
  a network.

89
Combine Segment Estimates for WAN and Backbone
Traffic Analysis

• After we have compiled estimates for each
  application and segment, we can combine these
  estimated traffic flows to analyze WAN and
  backbone capacities. In the Backbone Flows
  Diagram, we can see the primary traffic flows
  across the metropolitan area network (MAN)
  backbone, revealed by the traffic estimates for
  each segment. The Traffic Table summarizes the
  actual numbers for this example.

90
Backbone Flows
91
Backbone Flows (contd)

• The last column lists the estimated total network
  capacity required for each application. To arrive
  at each application's total network capacity (in
  Mbps), we first divide the hourly number of
  simultaneous sessions by 3,600 to get the number
  of simultaneous sessions per second, then
  multiply that figure by the average transaction
  size.

92
Backbone Flows (contd)

• For the e-mail application, this is
• (540,000 3,600 seconds) x 3 kilobytes (KB)
  450 kilobytes per second (KBps)
• We then multiply that product by eight (to
  convert bytes to bits)
• 450 KBps x 8 3,600 Kbps
• Finally, we divide this result by 1,000 to get
  the estimated capacity in Mbps
• 3,600 KBps 1,000 3.6 Mbps

93
Backbone Flows (contd)

• Because this is only a rough estimate, it is not
  necessary to divide by 1,024 to precisely convert
  kilobits (Kb) to megabits (Mb). Also, in the
  calculations for the CAD Server and File Server
  capacities, we can skip the final division by
  1,000 because the Average Transaction Size is
  given in megabytes (MB).
• Now we have estimates for the total network
  capacity for each application, and we know the
  percentage of traffic that crosses the MAN
  backbone. Therefore, we can estimate the amount
  of segment capacity and MAN backbone capacity
  needed for each application.

94
E-Mail Server

• E-mail traffic is distributed evenly across all
  three segments, so we multiply the total capacity
  by 0.33 to get the capacity for each segment
• Traffic on Segment 1, 2, or 3 3.6 Mbps 0.33
  1.2 Mbps
• E-mail traffic on Segment 3 does not cross the
  backbone because the e-mail server is on Segment
  3. Therefore, only 2/3 of the e-mail traffic
  crosses the backbone
• E-mail backbone traffic 3.6 Mbps x 0.66 2.4
  Mbps

95
CAD Server

• Traffic generated from the CAD servers only
  occurs on Segments 2 and 3. Therefore, each of
  those segments carries roughly one-half the total
  traffic
• Traffic on Segment 2 or 3 5.78 Mbps x 0.5 2.9
  Mbps
• Because the CAD server is on Segment 2, only
  Segment 3's traffic crosses the backbone
• CAD server backbone traffic 5.8 Mbps x 0.5
  2.9 Mbps

96
File Server

• Segments 1 and 2 each carry 25 percent of the
  file server traffic, while Segment 3 carries 50
  percent
• Traffic on Segment 1 or 2 560 Kbps x0.25 140
  Kbps
• Traffic on Segment 3 560 Kbps x 0.5 280 Kbps
• Because the file server is on Segment 1, only
  traffic from Segments 2 and 3 crosses the
  backbone
• File server backbone traffic 280 Kbps 140
  Kbps 420 Kbps(0.4 Mbps)

97
Total Backbone Traffic

• To estimate total backbone traffic, we add all of
  the backbone estimates above (where necessary,
  dividing Kbps by 1,000 to get Mbps)
• Total backbone traffic 2.4 Mbps 2.9 Mbps
  0.4 Mbps 280 Kbps 5.7 Mbps

98
Output Traffic Estimate

• When you complete your traffic estimates,
  summarize them in a document that will become
  part of your eventual Traffic Specification.
  Also, use this new information to enhance your
  current logical network diagram. Note the
  boundaries of your broadcast domains, collision
  domains, and subnetworks. If the traffic estimate
  has revealed any directional traffic patterns,
  note those patterns on the diagram as well.

99
Taking Baseline Measurements of LAN Traffic

• Baselining (also called "benchmarking") documents
  the performance of a network by measuring its
  capacity and standard operating efficiency. These
  measurements can identify long-term trends in
  network operations and their impact on network
  performance. Baselining can be used with traffic
  estimation or as an alternative to estimates.

100
Taking Baseline Measurements of LAN Traffic
(contd)

• Taking baseline measurements requires special
  monitoring equipment and applications. Because
  both of these are expensive, many small companies
  skip this step and rely on estimates alone.
  However, whenever possible, it is best to use
  both estimating and baselining.

101
Tools for Testing Activity

• If you have an existing LAN, you can probably get
  detailed reports from the network operating
  system (NOS) vendor as to the theoretical
  capacity of the NOS. Many NOSs run these reports
  as Value Added Processes (VAPs) or, as in the
  case with Novell's NetWare, NetWare Loadable
  Modules (NLMs).

102
Tools for Testing Activity (contd)

• Another traffic measuring tool is a LAN analyzer
  such as Network Associates' Sniffer,
  Hewlett-Packard's LAN Advisor, or Novell's
  LANalyzer. Sniffer, Advisor, and LANalyzer can
  record traffic over a given period of time.

103
Tools for Testing Activity (contd)

• You can also purchase LAN software emulation
  packages that monitor networks from a PC. These
  packages provide tools for
• Network mapping
• Physical network management
• Network design
• Network planning and simulation

104
Design and Modeling Tools

• Design tools model the behavior of a LAN under a
  given load. They provide an accurate picture of a
  LAN's performance, given a certain number of
  users, applications, and telecommunications
  links. Some tools include application profiles
  that estimate traffic generated by specific
  applications.

105
Design and Modeling Tools (contd)

• They may also have user libraries that contain
  performance profiles for various pieces of
  equipment, such as bridges and routers. These
  profiles can be plugged into the model without
  doing a lot of research, and can provide a
  reasonable estimate of the device's throughput
  and latency. Many networking products also have
  built-in capabilities to determine CPU
  utilization against network traffic.

106
Design and Modeling Tools (contd)

• Purchasing or renting separate design tools is
  expensive. However, if you need an engineered
  network with high reliability, the cost of
  failure far outweighs that of the tool.

107
Simulation and Testing Tools

• LAN traffic simulation packages (as well as
  Network Associates' Sniffer and Hewlett-Packard's
  LAN Advisor) generate actual LAN test traffic. By
  varying the size and frequency of the traffic,
  the effect on the LAN is measured. Progressive
  degradation of LAN performance can be gauged as a
  function of client activity using just a few PCs.

108
Simulation and Testing Tools (contd)

• Activity of each LAN device (server, bridges,
  routers, etc.) can be monitored to determine the
  delay within each component. One client can
  simulate many workstations.

109
Baselining a Network

• A network baseline is a "snapshot" of activity
  and performance that can provide proactive
  insight about the performance of a network. It is
  a measurement that can be taken periodically over
  time, or while interesting network activity is
  observed, such as high bandwidth utilization. A
  separate baseline should be run on each
  individual subnet, WAN link, and the network
  backbone, forming a collection of baselines for
  the entire network.

110
Baselining a Network (contd)

• A baseline should not be taken at any specified
  regular interval. A baseline taken at the same
  specified interval or time of day has the
  potential of lending the same results over time.
  It is better to baseline each subnet of a network
  at random times throughout the normal business
  day.

111
Sniffer Functions

• Sniffer is a popular tool for measuring LAN
  activity. It is available in various forms, from
  a freestanding hardware unit to a software-only
  tool that can be installed on a PC (laptop, other
  portable, or client/server platform). A device
  that runs Sniffer software (dedicated hardware or
  PC) must include a NIC that is compatible with
  the network to be analyzed.

112
Measuring Shared Resource Utilization

• Shared resources are network elements, such as
  servers and printers, that are shared by multiple
  users. It is often necessary to measure the
  utilization of such components when analyzing a
  problem or estimating the usage of an individual
  component. Normally, a problem arises between
  multiple clients and a specific server, the
  network is suspected first.

113
Measuring Shared Resource Utilization (contd)

• However, the server could also be a network
  bottleneck. If the designer does not understand
  the interrelationships between clients, network,
  and server, this can lead to an incorrect
  solution.

114
Measuring Shared Resource Utilization (contd)

• Typically, only the components that contribute
  the most delay are used in response time
  calculations. However, any of the following
  items, on the sending station, receiving station,
  or both, can cause network performance problems
• Application
• CPU/clock speed
• Input/output (I/O) bus type and data rate

115
Measuring Shared Resource Utilization (contd)

• Operating system (OS) type
• Number of tasks running (CPU utilization)
• Amount of memory
• NIC delay
• LAN link delay
• WAN link delay
• Protocol stack
• Internetworking device latency

116
Measurement Tools

• Each OS offers different ways to measure the
  utilization of shared resources. Command-line
  tools such as the System Activity Report (SAR)
  are often used on a UNIX system to measure CPU
  utilization. On a platform such as Windows NT
  Server, several graphical user interface
  (GUI)-based tools can display the performance of
  the server and the attached network
• Performance Monitor
• Task Manager
• Network Monitor

117
Applying the Tools

• How and when you apply these tools depends on the
  issues specific to your network. However, when
  several users are experiencing problems with the
  same resource, it is a good idea to monitor the
  shared resource's CPU utilization to determine
  whether the shared resource has run out of
  computing capacity. Also, consider any
  peripherals such as the hard drive being accessed
  on the shared resource, to see whether the
  bottleneck is there.

118
Output Baseline Report

• The result of your baseline measurement should be
  a baseline report that includes graphs and
  tables, over time, of each network segment's
  operating parameters. This report should also
  include a summary of anomalies and trends,
  utilization of key resources, and suggestions for
  threshold alarm configuration and monitoring.
• If your baseline measurements have revealed any
  important facts, such as overutilized links or
  devices, add those notes to your logical network
  map.

119
Developing A Traffic Specification Document

• The Requirements Specification served as the
  output of the Requirements Gathering phase, and
  the input of the Analysis phase. Similarly, the
  Traffic Specification is the main deliverable of
  the Analysis phase. Together, the Traffic
  Specification and Requirements Specification
  provide the two essential inputs into the Logical
  Design phase. The Requirements Specification
  describes what the new network should do in the
  future, and the Traffic Specification describes
  what the current network is doing now.

120
Developing A Traffic Specification Document
(contd)

• The Traffic Specification documents network
  traffic volumes (estimated or measured), as well
  as any traffic patterns or performance statistics
  that might indicate bottlenecks. The goal of this
  document is to accurately summarize what you have
  learned during your analysis of the existing
  network, and make design recommendations based on
  that knowledge and the Requirements
  Specification.

121
Developing A Traffic Specification Document
(contd)

• The Traffic Specification provides the evidence
  to support later design choices, such as new
  equipment or segmentation strategies. It is the
  second design document that management will
  formally approve, thus, like the Requirements
  Specification, it must be both accurate and to
  the point. Most important, it must describe
  technical issues in terms that nontechnical
  managers can understand and evaluate.

122
Preparing the Data

• Like the Requirements Gathering phase, the
  Analysis phase also creates a large mass of raw
  data user traffic estimates, traffic
  measurements, resource utilization statistics,
  and more. Thus, like the Requirements
  Specification, the Traffic Specification must
  summarize all this data in a form that reveals
  patterns to both the design team and management.

123
Preparing the Data (contd)

• You can process traffic estimates and
  measurements using the same spreadsheet
  applications used to summarize your requirements
  data. Better yet, good network analysis tools can
  conveniently summarize data in tables and graphs.

124
Preparing the Data (contd)

• A good Traffic Specification also includes
  network diagrams. You can use almost any drawing
  software to produce these, but a technical
  drawing application such as Visio can be a real
  time-saver. Later on, your Physical Design
  documents will require diagrams drawn to scale.
  You will save time in the long run if you start
  your early drawings in an application that offers
  good measurement and scaling features.

125
Preparing the Data (contd)

• Preserve all of your analysis data, just as you
  saved the raw requirements. Managers are often
  more inclined to trust a summary when they read
  the line, "All source data may be reviewed at
  your request."

126
Components of a Traffic Specification

• A Traffic Specification documents the current
  state of the network its configuration,
  internetworking devices, traffic levels, and
  utilization of shared resources. It may include
  some or all of the following major elements
• Executive Overview
• Overview of the Analysis Phase
• Summary of Analysis Data
• Recommended Design Objectives
• Approval Section

127
Executive Overview

• Weeks may have passed since management has
  considered this project, so remind them of the
  key parts of the process by including
• A short description of the project (one or two
  sentences)
• A list of the phases of the design process
• The project status, including completed phases
  and the phase in progress

128
Overview of the Analysis Phase

• Briefly describe the work done in this phase. and
  describe how and when you gathered information.
  Most important, explain what has been estimated
  and what has been measured.
• Also remember that this document will be used by
  both you and your management. Use terms and
  descriptions that a nonspecialist can understand.

129
Summary of Analysis Data

• Like the data summary in the Requirements
  Specification, the summary of your analysis data
  is the heart of the Traffic Specification. In
  this section, you must present an accurate
  functional picture of the current network, by
  revealing data patterns that indicate problems
  (or lack of them).
• To accomplish this, your Traffic Specification
  should include
• A logical network diagram
• Traffic estimates (current and future)
• Baseline measurements
• CPU utilization statistics

130
Logical Network Diagram

• A map is essential for understanding network
  traffic data. This map should show the location
  of the main components of the network, such as
  servers, wide area connections, and major
  internetworking devices. Wherever possible,
  indicate the boundaries of workgroups, wide area
  connections, or secured resources such as Web
  servers or firewalls.

131
Logical Network Diagram (contd)

• To support a Traffic Specification, a network map
  must be accurate however, it does not need to be
  100 percent complete. In fact, certain patterns
  will be easier to see if you include less detail.
  For example, if the most important traffic
  patterns occur between workgroups, it is not
  necessary to show each desktop within those
  workgroups. Simply show each workgroup as a
  "black box" entity, and illustrate the
  relationships between them. Likewise, if the same
  problem is occurring within several workgroups,
  illustrate the problem by mapping one
  representative workgroup.

132
Traffic Estimates

• Traffic estimates can help you see the overall
  directions and volumes of traffic flow. A traffic
  estimate should serve as a broad sketch of
  network function, and point out any areas of
  concern, such as heavily used links or devices.

133
Traffic Estimates (contd)

• You can present estimated traffic data in tables,
  or as notes on your network map that show volume
  and direction. It is usually best to use both
  methods. It can also be very effective to use
  network maps or graphs to illustrate the
  difference between current and future traffic
  patterns.

134
Baseline Measurements and CPU Utilization
Statistics

• While traffic estimates provide a broad view,
  baseline measurements and CPU utilization
  statistics focus on particular areas of interest
  revealed by the traffic estimates. For example,
  if the traffic estimate shows heavy traffic on a
  particular segment, you should provide
  measurement data for that segment.

135
Baseline Measurements and CPU Utilization
Statistics (contd)

• When presenting measurement data to management,
  do everything you can to filter out noise that
  can obscure important patterns. For example, in
  tables of data, highlight the most important
  items and add comments that explain what the data
  means. In graphs, note maximum or minimum values,
  or add notes about events that might have
  influenced the data, such as a daily traffic
  spike caused by a morning flood of e-mail
  checking. Avoid using technical jargon, or define
  special terms in plain language.

136
Baseline Measurements and CPU Utilization
Statistics (contd)

• Whenever possible, add important measurements to
  your network map. For example, indicate the
  position of overutilized devices or under-used
  links.

137
Recommended Design Objectives

• Your Traffic Specification should conclude with a
  set of objectives for the network design. These
  goals should describe problems that must be
  corrected, or new capabilities that must be
  added, for the new network to fulfill the
  requirements of the business. For example,
  recommendations can include things such as,
  "Create tighter security between the Web server
  and internal network," or "Accommodate 100 new
  users with no increase in response time."

138
Recommended Design Objectives (contd)

• Make sure you can justify each one of your
  recommendations, based on the Requirements
  Specification, Traffic Specification, or both.
  Each of your recommendations must either solve a
  problem, or satisfy a business need.
• In other words, your design objectives describe
  what the new network design should accomplish and
  why this is necessary. However, they should not
  describe how your design will do this. The
  Logical Design will explain that.

139
Approval Section

• As before, explain that the Traffic Specification
  must be signed and approved by the manager (or
  group of key players) before the Logical Design
  phase of the project can begin. By approving the
  specification, management accepts that the
  Traffic Specification is true, and agrees that
  the Logical Design should achieve the objectives
  listed there.
• Provide a place for each manager's signature and
  date, as well as the signature of the head of the
  network design team.

140
Revising the Specification

• Because a Traffic Specification is based on
  objective facts (or good-faith estimates), it is
  unlikely management will argue with the data.
  However, some design objectives may need to be
  changed before all key players can support them.
• Just as with the Requirements Specification, do
  not alter your data or findings to accommodate
  new design objectives. If necessary, add a note
  that explains why a particular objective was
  added.

141
Case Study Network Implementation Without
Analysis

• Thus far, we have worked our way through only the
  first two phases of the network design process
  Requirements Gathering and Analysis. This is a
  great deal of work, is it really necessary?
• When a network problem arises, we want to fix it
  quickly. We want to stop those annoying user
  complaints. We want to show fast results to
  management, without going through a detailed
  analysis of the network and its components.
  Unfortunately, that attitude means we often jump
  to conclusions. This case study illustrates what
  can happen without a complete network analysis.

142
The Problem

• A company that sells and distributes coffee and
  coffee products was experiencing severe network
  performance problems. The company had two desktop
  support technicians, but relied on an outside
  agency to support its network. After the desktop
  technicians had exhausted all possibilities, they
  called in the network consulting agency to help
  solve the problem. The Coffee Company Network
  Diagram in the next slide shows the network
  configuration of the organization.

143
Coffee Company Network
144
Coffee Company Network

• One hundred users, in six workgroups (four are
  shown), accessed corporate servers and other
  workgroups through a backbone switch. This switch
  connected the workgroup clients to applications
  on the corporate servers, and to the Internet.
  These applications are used exclusively by most
  clients in the network. Access to a remote site
  is also provided through the backbone switch.

145
The Proposed Solution

• The Information Services (IS) staff of this
  organization felt the network needed an upgrade,
  and the consulting agency readily agreed. The
  consultants proposed three different solutions
  for resolving the performance problem, listed
  below in order of lowest to highest cost. The
  consulting organization recommended the third
  option because it provided the highest bandwidth
  with the most opportunity for growth.
• Option 1--Replace the six workgroup hubs with six
  10-Mbps Ethernet switches.
• Option 2--Same as Option 1, but also upgrade the
  backbone switch to provide Gigabit Ethernet
  connectivity to the server
• Option 3--Replace the six workgroup hubs with six
  100-Mbps Ethernet switches. Replace the backbone
  switch with a 100-Mbps Ethernet Switch. Provide
  Gigabit Ethernet access to the corporate servers.
  This option is shown on the Upgrade Option 3
  Diagram in the next slide.

146
Upgrade Option 3
147
Upgrade Option 3 (contd)

• Upgrade Option 3 included the following
  components and costs
• Each option was discussed, and the company chose
  the third option. The network upgrade occurred
  over a weekend six technicians worked Saturday
  and Sunday to implement the solution. The design
  team and two technicians were onsite Monday when
  everyone returned to work, to assist with any
  connectivity issues that might

148
The Results

• Much to the dismay of the consultants, the
  network's performance was worse! Response times
  doubled and, in some cases, tripled. Many users
  could not even access applications because of
  timeout problems. How could this have happened?

149
The Results (contd)

• After more thorough analysis, the consultants
  discovered that the CPU utilization of each of
  the three servers was 100 percent. Each server
  was a 486/66-megahertz (MHz) machine with only 32
  MB of random access memory (RAM). Each one met
  the minimum requirements of its NOS, but simply
  did not have the processing power to serve so
  many users. Before the upgrade, performance had
  been slow because the servers could not keep up
  with client requests. When the network speed was
  increased, it only made the problem worse.

150
The Results (contd)

• Now the company was faced with additional
  expenses to upgrade its servers. This one change
  might have been enough to solve the original
  problem. However, with the network in even worse
  shape than before, an upgrade that should have
  been routine became an emergency.
• This story illustrates the danger of designing
  and implementing a solution, any solution, before
  going through the Analysis process. A small
  amount of patience and discipline can help ensure
  that network changes are as simple, economical,
  and effective as possible.